Re: Should I* opinions be afforded a special status? (Re: [saag] Declining the ifare bof for Chicago)

[Joel M. Halpern]

I think this actually highlights where I am concerned.

At 01:43 AM 6/18/2007, Lakshminath Dondeti wrote:
In most cases, I am simply seeking more transparency and determinism 
in our operation.


I agree that transparency is a good think.  (There are a few cases 
where that must be sacrificed, but very few, and there needs to be 
good reason.  I applaud the IESG having more detailed minutes, more 
example, as an improvement I thought was not practical, but works.)


On the other hand, determinism is what I get from a government 
bureaucracy.  Determinism means that the person is required to follow 
the rules, even whether their judgement says that this is a different 
case, and needs to be handled differently.  BoF formation and working 
group chartering are examples of places where I want intelligent 
judgement exercised.  As such, the result will not be 
"deterministic."  There should be no set of hoops you can jump 
through that guarantee a BoF, or a working group.


In fact, as has been observed in other (procedural) contexts, we 
usually do better when we can have fewer rules (quasi-absolute 
determinism) and better guidelines which give good understanding of 
the intent, and leave the leadership room to figure out how the 
intent is best achieved.


Yes, we should have a clear understanding of what the normal case is, 
and what one would expect to be the parameters for success or 
failure.  And yes, if the leadership decides not form a working group 
after a BoF or two, we should expect an understandable explanation. 
(BoF sponsorship is harder, but still refusal ought to be explained.)


Yours,
Joel M. Halpern




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

Re: Last Call: draft-ietf-lemonade-rfc2192bis (IMAP URL Scheme) to Proposed Standard

[Joel M. Halpern]

Clarification below.

At 06:16 AM 6/18/2007, Dave Cridland wrote:

On Mon Jun 18 08:30:00 2007, Simon Josefsson wrote:

>   If you do believe the ABNF needs special licensing in
> this case, I am sorry to say that your remedy is not sufficient.
This
> document imports ABNF from other documents (from RFC 3986,
> to take one important example).  Those documents do not have
> anything like what you suggest.
I disagree, I think they do have what Simon's suggesting. But then, 
I think RFC2192bis does, as well.



Given existing wording, it is somewhere between an extremely good 
idea and necessary to indicate that the ABNF and the code (and yes, I 
agree with Simon that it needs to apply to both) can be extracted and 
modified as necessary by anyone.  And while we are trying to solve 
this for the future, that unfortunately can not help current documents.


My only caveat is that the wording suggested by Simon does much more, 
and it is not necessary to go that far to meet the requirements.  An 
indication that says that those specific parts can be extracted, 
modified, and used for any and all derivative works would 
suffice.  (I am not a lawyer and I am not going to try to write license terms.)


Yours,
Joel




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

Re: Last Call: draft-ietf-lemonade-rfc2192bis (IMAP URL Scheme) to Proposed Standard

[Joel M. Halpern]

Since the FAQ specifically says that code extracts can be modified, 
and since RFC 3978 specifically gives us the right to modify code for 
any purpose (explicitly not limited to the standards process) it 
seems that we are already covered on this, and no extra or special 
license is required.

(Sent to the list since I publicly said I thought we needed something extra.)

Yours,
Joel

At 06:54 PM 6/18/2007, Ted Hardie wrote:


>
>7. Am I allowed to publish modified extracts from RFCs?
>It is acceptable under the current IETF rules (RFC 3978)
>to modify extracted code if necessary.
>
...

(As noted, 3978 is where the IETF gets these rights from Contributors).

If ABNF is code, in other words, we are covered.

So, I believe we all also agree a human can read the RFC and code an
implementation after having done so without a copyright violation.
If the ABNF is specification, in other words, we are covered provided
the process to turn it into code is in wetware.

...
regards,
Ted



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

Re: Restatement of my proposal from last night's plenary

[Joel M. Halpern]

I must disagree.
If a working group is chartered, starts down a path, and then later the 
IESG or IAB determine that the working group has overlooked a serious 
architectural problem, then the IAB or IESG needs to raise the issue when 
they find it.  Declaring that "it is too late" in response to a real 
problem seem to be the wrong response.

Yours,
Joel M. Halpern

At 07:19 AM 11/21/2002 -0800, Charlie Perkins wrote:

Hello folks,

I realzed that my proposal probably wasn't clearly enough stated,
so here goes again.

It is my belief that the IESG has formulated some architectural
principles and applied them at inappropriate times in the process
of standardizing a working group protocol specification.  Right now,
there is nothing preventing such a thing from happening even after
working group Last Call, and nothing that assures that one AD's
architecture principal is shared by the rest of the IESG or the IAB.
This leads to what could be perceived as arbitrary restriction based
on somebody's pet peeve -- whether or not the perception is true.

I think that such architectural principles (e.g., suitability of
vendor-specific extensions, but there are a number of others)
should be formulated by the IAB.

I think the IESG should try to understand early in the process
whether a working group is violating an architectural principle, and
when some candidate proposal seems to be in violation, that the
IESG should get the IAB's opinion in writing.  That opinion should
be subjected to normal IETF process and published as a standards
track document which can be cited as a normative reference.

Again, as I stated last night, nothing is black and white, and I do
not claim that we need IAB statements on every aspect of protocol
design.  But there have been some major upsets lately, and that is
even less appropriate.  There has to be a happier medium.

Regards,
Charlie P.

RE: accusations of cluelessness

[Joel M. Halpern]

Nobody made us kings.  In fact, we are not kings.
On the other hand, we are not a publication house.  Someone having an idea 
and writing it up does not require us to publish it as an IETF 
standard.  Even if it is a good idea.
If someone wants to have the IETF work on something and produce a standard 
for a problem, then one dimension of that is agreeing to accept IETF review 
and modification of the idea and solution.

We can not stop someone from doing their own thing.  For example, if you 
want to use a new header call X-CHRISTIAN-TYPE and define content type 
values as you please, as long as you do not request IETF agreement that it 
is a good idea we can not stop you.  In that regard, the market can still 
choose.

It is true that the market attaches value to the IETF standardization.  To 
that degree, the market has made us judges and asked us to judge.

Yours,
Joel M. Halpern
At 10:58 PM 10/11/2003 -0700, Christian Huitema wrote:
Well, who made us kings? It is one thing to work and publish designs
that hopefully will be good. It is quite another to judge someone else's
design and brand it bad. It is far better to let the market be judge.

Re: The IETF Mission

[Joel M. Halpern]

I do not think "appeals" belongs in our mission and vision statement.  They 
are a mechanism to achieve openness and accountability, not the purpose of 
the organzation.

Yours,
Joel M. Halpern
At 01:47 PM 2/5/2004 -0500, Dean Anderson wrote:
How about this:

 To provide a fair and open process whereby any party that
 believes it has been treated unfairly has the opportunity to appeal.
On Wed, 4 Feb 2004, james woodyatt wrote:

> On 04 Feb 2004, at 12:49, Dean Anderson wrote:
> >
> > To provide a fair and open process whereby any party that
> > believes
> > it has been treated unfairly has the right to appeal.
>
> I'd prefer this:
>
>   To use a fair and open process, even in the resolution of disputes,
>   in which any person with a claim of unfair treatment has an avenue
>   for appeal.
>
> I don't much like the idea of artificial legal entities, i.e. political
> parties, having "rights".  It's a minor nit, I know— call me a radical
> hippie, if you must.
>
>
>

Re: Scenario O Re: Upcoming: further thoughts on where from here

[Joel M. Halpern]

I think that this (scenario 0) is the right approach to follow.  It appears 
to me to be the lowest risk path consistent with the needs that have been 
identified.

Two minor comments:
1) The references to "the IASF bank account" should probably be relaxed to 
"IASF fund accounts" or "IASF accounts".  As written, it presumes that 
there is exactly one bank account, and that separation of funds is by bank 
control.  While the later is probably a good idea, I don't think this BCP 
is the place to call that out.  And the exact number of bank accounts used 
by IASF (0, 1, 5, or ...) is not a concern for this BCP.

2) The schedule calls for seating the IAOC on January 15, and hiring the 
IAD by the end of January.  Given that the search committee can not be 
appointed until the board is seated, it seems that item is either an 
impossible schedule or assumes facts not in evidence.

Yours,
Joel M. Halpern
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

RE: Scenario O Re: Upcoming: further thoughts on where from here

[Joel M. Halpern]

Yes, in minor comment 1 I meant the IASA bank account(s) or fund 
account(s), not the IASF accounts.  (I believe that the scenario C document 
avoid this particular pitfall, since it did not need to talk about 
segregation of funds.)

Sorry to mix names.
Yours,
Joel
At 05:12 PM 9/23/2004 +0200, Wijnen, Bert (Bert) wrote:
Joel... just to be clear...
I suspect that in the below you meant
IASA (IETF Administrative Support Activity)
which is defined in Scenario O
and not
IASF (IETF Administartive Support Foundation)
which is defined in Scenario C
Bert
> -Original Message-
> From: Joel M. Halpern [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 23, 2004 16:35
> To: [EMAIL PROTECTED]
> Subject: Re: Scenario O Re: Upcoming: further thoughts on where from
> here
>
>
> I think that this (scenario 0) is the right approach to
> follow.  It appears
> to me to be the lowest risk path consistent with the needs
> that have been
> identified.
>
>
> Two minor comments:
> 1) The references to "the IASF bank account" should probably be relaxed to
> "IASF fund accounts" or "IASF accounts".  As written, it presumes that
> there is exactly one bank account, and that separation of funds is by bank
> control.  While the later is probably a good idea, I don't think this BCP
> is the place to call that out.  And the exact number of bank accounts used
> by IASF (0, 1, 5, or ...) is not a concern for this BCP.
>
> 2) The schedule calls for seating the IAOC on January 15, and hiring the
> IAD by the end of January.  Given that the search committee can not be
> appointed until the board is seated, it seems that item is either an
> impossible schedule or assumes facts not in evidence.
>
> Yours,
> Joel M. Halpern

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

RE: Scenario C or Scenario O ? - I say let us go for C !

[Joel M. Halpern]

Actually, as far as I can tell the accountability is about the same in both 
cases, and in neither case as "direct" as one would philosophically like 
(but probably as direct as one can get in practice.)  Similarly, the 
"change control" appears to be equally in the IETF hands.

Yours,
Joel
At 10:31 PM 9/23/2004 +0200, Wijnen, Bert (Bert) wrote:
- if done properly, this allows for a very straight forward
  governance mechanism that is *directly* accountable to
  the IETF and where change control is clearly vested in that
  same community.  Again, the corporate solution is the
  lightweight and straightforward solution.

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Shuffle those deck chairs!

[Joel M. Halpern]

I think this is seriously miscontrueing the situation.
Different groups participate in the success of the internet in different ways.
I have no objection to Debian, Apache, Nortel, or Cisco fighting patents 
which they believe hurt the internet.
That fight is not the job the IETF has demonstrated skill at, or interest in.
It is not an end-run of the IETF for another organization to do something 
the IETF is not interested in doing.
It is not a threat to the internet or the IETF for other organizations to 
help seek the best interest of the internet.  In fact it is necessary.

And I personally would be very unhappy if the IETF were dragged into the 
philosophical and legal argument as to whether patents qua patents (whether 
restricted to software or all inventsion) are a good idea, a bad idea, a 
good idea gone bad, or some other view.  The IETF is not the forum for 
promoting or advancing such views.

Yours,
Joel M. Halpern
At 10:59 AM 10/21/2004 -0400, Eric S. Raymond wrote:
Brian E Carpenter <[EMAIL PROTECTED]>:
> I don't think we can require the IESG to negotiate anything. There are
> all kinds of legal issues there. To my knowledge, both WGs and the IESG
> do think carefully about this, but often conclude that the default IETF
> conditions (RAND) are realistic and acceptable.
If IETF continues to believe this, groups like Apache and Debian will continue
to have to end-run IETF by doing the job of defending the Internet commons
that IETF is abdicating, and IETF's authority will evaporate.
It is not 1982 or even 1992 any more.  Conditions have changed dramatically.
I would hate to see IETF dwindle into irrelevance, but that is exactly
where statements like this are pointing.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: AdminRest: Finances and Accounting

[Joel M. Halpern]

From my read, there are several different aspects.
The description of the sources of funds and the directing of "deposits" is 
probably over-constrained.  I would hope that there is not a requirement 
specified by these documents for an actual IASA bank account.  I doubt that 
the document needs to mandate quarterly transfers.

At the same time, the IASA / IAD are intended to have reasonable discretion 
(with ISOC review and approval on a budgetary level) of how money is spent 
to support activities.  If the funds are not earmarked at the ISOC level 
for IETF / IASA use, then it gets complicated to create the desired flexiblity.

My guess is that we are indeed giving up the ability for ISOC to 
transparently cover "bumps" in exchange for greater control and visibility 
to the actual state of the funds.  I would expect after a bit that this 
would actually help ISOC, as it would make explicit if the IASA / IAD are 
not doing a good job planning.

Yours,
Joel M. Halpern
Not on of the document maintainers
but someone trying to understand what it will turn out to mean.
At 07:55 PM 11/17/2004, Fred Baker wrote:
A question for those maintaining the document…
There is a fair bit of change in section five, regarding IASA funding. In 
a nutshell, it now says:

 - IETF has three revenue streams:
* IETF meeting fees
* Donations of various kinds designated to the IETF
* ISOC funding derived from other sources
 - the first two get deposited in the IASA checkbook
 - the third gets deposited in quarterly lump payments
 - there is an intent to have built up enough money for the IASA to run for
   six months without receiving a dime, over a period of three years.
All that sounds good on the surface, but it differs rather markedly from 
current ISOC accounting practice, and it seems to over-constrain the 
problem and its solution. Someone who knows more about accounting than I 
do will mention the difference between a cash accounting scheme and an 
accrual accounting scheme, the latter being more usual in corporate accounting.

IETF does indeed have these present revenue sources. CNRI/Foretec 
currently collects IETF meeting fees and uses them pursuant to IETF 
meetings, databases, and teleconferences. ISOC accepts donations 
designated to IETF-related activities. ISOC also uses funds from other 
revenue sources (other donors) to further IETF purposes.

ISOC places donations "to the IETF" in accounts so designated. When the 
money is spent ­ usually on the RFC Editor, which is our largest single 
IETF-related expense - the revenue is recognized, and the books show both 
the revenue and the expense.

The effect of section 5, if I am reading it correctly, is to present ISOC 
with an always-on expense ­ ISOC immediately transfers any such money to 
IASA. The money is therefore immediately recognized as both revenue and an 
expense in the ISOC ledger and as a net deposit in the IASA checkbook.

ISOC current practice with regard to other IETF (and ISOC) expenses is to 
pay them as bills are presented. Bills are not presented on nice neat 
quarterly boundaries; the insurance bill is paid annually, IAB telechats 
are paid out of the monthly phone bill, meeting expenses and other 
payments from the IETF Chair's Discretionary Budget are paid episodically, 
and so on. The current issues in the RFC Editor's office (into which I 
will not delve in detail; due to an accounting error, they have suddenly 
needed an infusion of cash) result in ISOC paying an unplanned and 
unbudgeted lump sum payment. In short, like any other ISOC bill, 
IETF-related expenses are paid as valid bills are received, sometimes by 
surprise.

A significant part of IETF expenses will be in deposits for future 
meetings. Generally, the most expensive way to plan and pay for an 
excursion in a hotel or conference center is "at the last minute". As a 
result, most organizations that plan conferences have deposits on hotels 
and such at least a year out. A quick look at 
http://www.icann.org/meetings/, for example, shows meetings paid for 
through next summer, and on in development in December 2005. When the 
document talks about a six-month reserve, I therefore have to ask: which 
six months of the year? Does this cover one planned meeting fee, or two? 
On an accrual basis, that's not much of an issue, but on a cash basis, it 
is a big one.

The effect of section 5, if I am reading it correctly, is to transfer 
these budgetary bumps and grinds to the IASA rather than allowing the ISOC 
to help out, making "oops, we're low on cash" something that has to be 
discussed as opposed to ISOC simply backstopping things as we have 
heretofore agreed. By treating them on a cash basis rather than an accrual 
basis, this section seems maximize the pain they cause.

I wonder whether the IETF would consider talking with ISOC's accounting 
office to normalize these issue

Re: AdminRest: IASA BCP: Executive Director

[Joel M. Halpern]

There is an obvious question that at least for me drives the answer to 
whther the IAD is the IETF Executive Director.

As currently practiced / defined, is the IETF Executive Director a full 
time job?

If it is a full time job, then clearly it should not be combined with the 
IAD.  THis implies that we will need budgeting to contract / hire this 
person in addition to the IAD.

On the other hand, if this is not a full time job, it seems to make more 
sense to combine it with the IAD because there is a very large overlap in 
required knowledge.  For example, If the IESG decides in their meeting to 
ask that the infrastructure group do something, the Exectuive director will 
know that immediately, and have the context of the discussion.  If the IAD 
is a separate person, he will need a clear description of what needs to be 
done, and need to make sure the work is tracked properly in managing the 
contract with the infastructure provider.

Yours,
Joel M. Halpern
At 10:27 AM 11/26/2004, Wijnen, Bert (Bert) wrote:
In draft-ietf-iasa-bcp-00.txt it states at the end of sect 3.1:
   Unless explicitly delegated with the consent of the IAOC, the IAD
   will also fill the role of the IETF Executive Director, as described
   in various IETF process BCPs.
We currently have (in our working version of the IASA BCP):
  Editors' note: The preceding paragraph has generated some
  comments, given that the role of the IETF Executive director is
  mentioned in a number of documents, some of which are fairly old
  and dusty.  The editors actively solicit feedback on whether this
  paragraph is ok as it stands.
We had some discussion in the IESG about this (because the IETF
Executive Director also interacts with the IESG basically on a
daily basis). I believe that in the IESG our current thinking is that
better text would be:
   The IETF Administrative Director (IAD) is not the same function
   as the IETF Executive Director.  The IESG shall select an IETF
   Executive Director (as defined in xxx, we need to fill out xxx).
Does the IETF community can agree with that?
Bert
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: AdminRest: IASA BCP: Executive Director

[Joel M. Halpern]

This is a quite understandable goal.  But I am not sure that as stated it 
can be met.
Let us assume that some of the activities that the IAD is responsible for 
contracting includes the Executive Director function.  (I have difficulty 
seeing it as a separate contract on its own.)
It is the IAD's job to award that contract.
One would hope that the IESG had review over the person who they had to 
work with that closely.  But such review is VERY different from getting to 
choose the person.

Just my reading of the documents,
Joel M. Halpern
At 04:40 PM 11/26/2004, Sam Hartman wrote:

>>>>> "Carl" == Carl Malamud <[EMAIL PROTECTED]> writes:
Carl> It seems to me that one of the goals of the whole AdminRest
Carl> exercise has been to move overall management responsibility
Carl> for IETF admin. and support activities (IASA) from
Carl> contractors to a "program manager", which is what this BCP
Carl> is all about.  As such, it seems that where documents refer
Carl> to "IETF Executive Director" that should become (via a
Carl> paragraph in this BCP) a pointer to the IAD or other
Carl> appropriate position as further pointed to by the IAD.
I think the IESG's concern here is that they, rather than the IAOC
would like to designate who the executive director is.
The executive director is very involved in making the IESG and process
functions run smoothly.
It seems like significant friction would be created if the executive
director was not someone the IESG was comfortable with.

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Adminrest: section 3.5b (appealability)

[Joel M. Halpern]

On what kinds of grounds should such things be appealable?
For WG decisions, there can be appeals based on technical grounds or 
procedural grounds.
The ISOC however may only here pure procedural appeals.

I would hate to see someone "appeal" an IAD decision because they happened 
to disagree with it.  That would make the job impossible.
There probably are some things that should be subject to appeal.  I don't 
know what they would be.  If we can not list them, I don't think we dare 
create an appeal process.
The IADs job is administration.  We need to hire an IAD and let him do his 
job with sufficient oversight / review (that's what the IAOC is for.)

Note that if the IAD decisions are sufficiently transparent, then if the 
community really dislikes the decisions, then the community leadership will 
look into better directing or if necessary replacing the IAD.

I have even more trouble seeing how someone would end up appealing an IAOC 
"decision" since their primary job is oversight.  I presume that they will 
have decisions to make over and above oversight.  But "appealing" most of 
those would produce very strange results.

Note that there are many things in our process that can not be 
appealed.  The IESG decides how many areas to have.  It decides what areas 
different working groups belong in.  It needs to make those decisions 
(usually merely by living with the status quo) in order to function.

Transparency of decisions does require appealability.  Most government 
transparency does not lead to appeals.  There are specific legal grounds 
for "adjusting" government decisions.  Not "anything can be appealed".

At 08:48 AM 12/2/2004, [EMAIL PROTECTED] wrote:
I tend to feel that both the decisions of the IAD and of the IAOC should 
be appealable.

My thinking tends toward thinking that anyone should be able to appeal the 
decision, or any practice including the accounting practices, of the 
IAD.  I believe we are defining high standards of transparency, as I think 
we should, but transparency without recourse can be problematic.

I think anyone, or perhaps any group of people, should be able to appeal 
IAD actions to the IAOC.

the chain of appeal could be either:
a. the normal iaoc-iesg-iab-isoc bot
b. iaoc - a joint iab/iesg appeals committee (that excluded iaoc members) 
set up to hear the appeal - isoc bot
c. an abbreviated chain iaoc-isoc bot

As for the IAOC, I believe their actions should be appealable as well and 
should use the same chain as an IAD appeal.

a.
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: iasa-bcp-01 - Internet standard governance description

[Joel M. Halpern]

I must be missing something.  It seems to me that this BCP is for defining 
the administrative function and how that administrative function will 
interact with its parents (IETF and ISOC).

It does not seem to me that there is any reason to have, in this document, 
an attempted definition of the Internet.  Even the "definition" of the IETF 
in the document is primarily for context rather than as an effort to 
actually "define" the IETF.

Yours,
Joel M. Halpern
At 07:26 AM 12/8/2004, JFC (Jefsey) Morfin wrote:
If we want to get WSIS support and subsequent R&D public fundings as RFC 
3869 calls for, we need a short and clear description, in the draft, of 
what is discussed today. A statement that everyone can understand, quote 
and consider as acceptable whatever the changes the Internet Governance 
may meet. I came with the following draft and tested it around (please do 
not consider the language but the ideas) :

"The internet is the adherence to the humanity common property made of the 
Internet documents published by the RFC Editor, of the common parameters 
made available on-line by the IANA and of the data and sources necessary 
to their management. Documents are authored by the IETF under the 
architectural guidance of the IAB and the long terms consideration of the 
IRTF, along an online and face to face process conducted by the IESG. The 
common administrative support [of these to be legally defined entities] is 
transparently carried by the IASA, a clerical funtion entrusted into ISOC. 
The online management of the IANA has been delegated to ICANN."

I note that this is a statement every Governement should accept. The 
reference to ICANN at the end of the text permits to link that paragraph 
with a second paragraph which would present the Intenet intergovernance as 
it will be recommended by the coming Tunis submit. Hammering this would 
probably be the best reponse to the currently developped idea of an 
industry/governement/users sponsored and maintained "Internet/NGN 
Reference Book and Sources" which would probably lead to several versions 
and to a balkanization of the Internet. We should remember that 99% of the 
decision makers influencing the Internet deployment totally ignore what is 
the Internet standard process. They are the target of such a reference 
statement.

This statement however needs a legal definition of the IETF. The only 
definition included in the draft is "The IETF is a consensus-based group, 
and authority to act on behalf of the community requires a high degree of 
consensus and the continued consent of the community". I would suggest to 
use an "open consortium of the voluntaries participating into the Internet 
standard process". This seems a fair description of the reality and gives 
a common sense framework, clearly defining how and why the "IETF" may 
receive monies and get them managed. I also understand that managing a 
"trust" is a well defined function which protects the rights and the 
property of the truster whatever happens while permitting the trustee to 
do what Margaret describes. In any case, everyone of non American legal 
culture will understand it the way you want the things to work - what will 
permit help donations decision.

The whole statement would then read :
"The internet is the adherence to the humanity common property made of the 
Internet documents published by the RFC Editor, of the common parameters 
made available on-line by the IANA and of the data and sources necessary 
to their management. Documents are authored by the IETF under the 
architectural guidance of the IAB and the long terms consideration of the 
IRTF, along an online and face to face process conducted by the IESG. The 
common administrative support of the open consortium of the voluntaires 
participating into this process is transparently carried by the IASA, a 
clerical funtion entrusted into ISOC. The online management of the IANA 
has been delegated to ICANN."

jfc

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Draft version of the IAD job announcement from the IASA TT

[Joel M. Halpern]

I have no objection to having a professional look over the job 
description.  That is probably a good idea.

A full professional search is in my opinion not warranted or useful.  I 
have worked with a number of executive search firms on senior level 
searches.  They are very useful if what you want is already in their 
portfolio.  The further it is from their norm, the less return you get on 
the very high investment.

Note: this is a general comment.  There are individuals in the search 
profession who are very good and add value worth their cost.  But they are 
few and far between.

Yours,
Joel M. Halpern
At 05:23 PM 12/19/2004, Scott Bradner wrote:
jck sed:
> Personally, I think I'd be happier with a
> professionally-conducted search, but YMMD (and probably does).
I agree (fwiw)
I suggested directly to the IASA TT but did not get a positive respose so
I'll suggest here - I'd sure like to have a professional in the field
of looking for people of this type at least take a look at the
job description (which struck me, maybe not as strongly as it did jck,
not up to professional grade).
Scott
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

RE: Issue: #748: Section 5.4 - Quarterly deposits inappropriate

[Joel M. Halpern]

I think that there is a different side of this.
Suppose that a budget was worked out (as below), with a plan for a certain 
expected coverage from ISOC general funds, meeting fees, and directed 
donations.
Lets presume the budget includes the plan for building the reserves.
If meeting fees run high, presumably the IAOC and ISOC will negotiate about 
how much of that goes into extra IETF reserves, how much goes for 
previously unbudgeted but desired IETF activities, and how much goes to 
reduce ISOC general fund contribution.

What I wonder about is the case where earmarked donations run higher than 
budgeted.  If ISOC is allowed to reduce its support from general funds for 
the IETF based on that increased earmarked donation, then it tends to 
undermine the value of the earmarked donation.

It seems to me that two conclusions follow from this:
1) The budget ought to be built around some assumption (based on 
experience) of earmarked donation.
2) But extra earmarked donation should go to either IETF reserves or other 
IETF specific activities that were not in the budget.

Yours,
Joel
At 08:51 AM 12/22/2004, Margaret Wasserman wrote:
Hi Bert,
At 11:13 PM +0100 12/21/04, Wijnen, Bert (Bert) wrote:
May be I need to explain my (personal) thinking.
This is good, because your personal thinking does not match my personal 
thinking and perhaps that is why we have been having trouble coming to 
wording that seems right to both of us.

In my view, just as an example, if we have this budget:
Revenues:expenses  $5M
- meeting fees   $ 2M
- earmarked donations:   $ 2M
- ISOC budget$ 1M
and at the end of the year it turnes out that we adhered to th $5M spending
and that the meeting fees and earmarked donations are say $ 5M, then I
would hope we can set aside $1 M for reserve funds for possible future
shortfalls and/or disasters.
I'd hope that ISOC would still be willing to allocate $ 1M for IETF
(at least untill we have our defined reserve fund established).
With the same budget numbers, I would, personally, think about it like this:
ISOC has agreed to cover a $5M budget.  The IASA is only anticipating $2M 
in meeting revenue.  This means that ISOC needs to raise funds (in one 
form or another) to cover $3M worth of expenses.

If meeting fees and/or designated donations do cover the full $5M, the 
budget is covered.  If these revenue sources do not cover the full $5M, 
ISOC will need to cover the remaining expenses from non-IASA-specific funds.

I think that you are making a mistake when you consider the "earmarked 
donations" and the "ISOC budget" to be two separate revenue streams.  ISOC 
will have fund raising programs, and _all_ of the donations that ISOC 
collects from those programs are ISOC revenue.  Some of that revenue may 
be earmarked to specific projects (IASA is only one of many projects that 
people may choose to fund) and/or collected via project-specific fund 
raising efforts, but all of this revenue and all related expenses are 
included in the ISOC budget.

I don't know whether or not IETF meeting fees will be included in the ISOC 
budget.  That will depend on whether we view meeting fees and expenses as 
IASA budget items, or whether the meetings are run in such a way that only 
the surplus from the meetings shows up on the ISOC/IASA books.

In fact I would rather see a budget:
revenues: expenses
- meeting fees   $ 2M allocate to reserve fund $.5M
- earmarked donations:   $ 2M normal expenses $4.5M
- ISOC budget$ 1M
And then if meeting fees turn out to generate an extra 1M without extra
cost, then put the extra 1M in the reserve fund so we get to our defined
"reserve" faster.
You still seem to be thinking that there is a goal to create a separate 
IASA reserve fund.  I don't think that makes sense.  The overall ISOC 
organization will be more flexible, and more resilient with a single, 
larger reserve that can cover the full operation (including IASA) than it 
will be if we hold separate "ISOC" and "IASA" reserves.

If the meeting fees and designated donations exceed the IASA budget on an 
ongoing basis, we will build-up some IASA-specific funds that could be 
used as a first line reserve, but I don't think that should be our goal, 
so I don't understand why we would want a budget that tried to achieve that.

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

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

Re: IASA BCP Conflict of Interest Clause?

[Joel M. Halpern]

This is a good question.
We probably ought to say something.
This may be too strong  (but I am not sure.)
At a minimum, I would expect an IAOC member with such a conflict of 
interest to recuse themselves from any discussion of the situation.

But, as written, this has odd implications.  For example, it seems to 
prohibit an employee of such an organization from becoming IETF Chair or 
IAB Chair.  Given that we are expecting to contract for IT services, and 
other information support services that might be provided by organizations 
that actually participate in the IETF, this would seem unfortunate.  It 
could also prevent competent bidders from bidding sometimes.

Another thing that bothers me is that it heads us down the path of 
requiring financial disclosures from our appointees, which I would really 
rather avoid.

And what if one of the members is a consultant.  He can probably quietly 
recuse himself from discussions that relate to a confidential client.  But 
resigning, or blocking the client from bidding?

Yours,
Joel
At 09:07 AM 12/22/2004, Margaret Wasserman wrote:
One question arose when we were writing the original BCP that I haven't 
seen discussed on the list...

Do we need a conflict of interest clause in the BCP?  Something like:
The IAD and IAOC may not accept bids from nor establish contracts with 
members of the IAOC, their family members, their employers or companies in 
which they have a significant financial interest.  If such a conflict of 
interest arises, it should be quickly resolved through contract 
termination or the resignation of the IAOC member involved.

Margaret


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

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

Re: Issue: #748: Section 5.4 - Quarterly deposits inappropriate

[Joel M. Halpern]

The concern (and I think it is minor but not insignificant) is not with 
incompatibility.
It is that as currently written, in the case of more IETF earmarked 
donation than expected, it is equally consistent with the text that either
1) ISOC maintains their level of general contribution to IETF activities
or
2) ISOC reduces their level of general contribution to IETF activities, 
because the money is coming from elsewhere.

We clearly want 1.
Governments lover to do 2.  That is the game they play with "lottery money 
is only usable for schools" and similar nonsense.

Yours,
Joel
At 10:25 AM 12/22/2004, Brian E Carpenter wrote:
Joel,
Joel M. Halpern wrote:
I think that there is a different side of this.
Suppose that a budget was worked out (as below), with a plan for a 
certain expected coverage from ISOC general funds, meeting fees, and 
directed donations.
Lets presume the budget includes the plan for building the reserves.
If meeting fees run high, presumably the IAOC and ISOC will negotiate 
about how much of that goes into extra IETF reserves, how much goes for 
previously unbudgeted but desired IETF activities, and how much goes to 
reduce ISOC general fund contribution.
What I wonder about is the case where earmarked donations run higher than 
budgeted.  If ISOC is allowed to reduce its support from general funds 
for the IETF based on that increased earmarked donation, then it tends to 
undermine the value of the earmarked donation.
It seems to me that two conclusions follow from this:
1) The budget ought to be built around some assumption (based on 
experience) of earmarked donation.
2) But extra earmarked donation should go to either IETF reserves or 
other IETF specific activities that were not in the budget.
I'm not clear that anything in the -02 text with the minor proposed
changes to get rid of "quarterly" is incompatible with this.
   Brian
Yours,
Joel
At 08:51 AM 12/22/2004, Margaret Wasserman wrote:
Hi Bert,
At 11:13 PM +0100 12/21/04, Wijnen, Bert (Bert) wrote:
May be I need to explain my (personal) thinking.

This is good, because your personal thinking does not match my personal 
thinking and perhaps that is why we have been having trouble coming to 
wording that seems right to both of us.

In my view, just as an example, if we have this budget:
Revenues:expenses  $5M
- meeting fees   $ 2M
- earmarked donations:   $ 2M
- ISOC budget$ 1M
and at the end of the year it turnes out that we adhered to th $5M spending
and that the meeting fees and earmarked donations are say $ 5M, then I
would hope we can set aside $1 M for reserve funds for possible future
shortfalls and/or disasters.
I'd hope that ISOC would still be willing to allocate $ 1M for IETF
(at least untill we have our defined reserve fund established).

With the same budget numbers, I would, personally, think about it like this:
ISOC has agreed to cover a $5M budget.  The IASA is only anticipating 
$2M in meeting revenue.  This means that ISOC needs to raise funds (in 
one form or another) to cover $3M worth of expenses.

If meeting fees and/or designated donations do cover the full $5M, the 
budget is covered.  If these revenue sources do not cover the full $5M, 
ISOC will need to cover the remaining expenses from non-IASA-specific funds.

I think that you are making a mistake when you consider the "earmarked 
donations" and the "ISOC budget" to be two separate revenue streams.
ISOC will have fund raising programs, and _all_ of the donations that 
ISOC collects from those programs are ISOC revenue.  Some of that 
revenue may be earmarked to specific projects (IASA is only one of many 
projects that people may choose to fund) and/or collected via 
project-specific fund raising efforts, but all of this revenue and all 
related expenses are included in the ISOC budget.

I don't know whether or not IETF meeting fees will be included in the 
ISOC budget.  That will depend on whether we view meeting fees and 
expenses as IASA budget items, or whether the meetings are run in such a 
way that only the surplus from the meetings shows up on the ISOC/IASA books.

In fact I would rather see a budget:
revenues: expenses
- meeting fees   $ 2M allocate to reserve fund $.5M
- earmarked donations:   $ 2M normal expenses $4.5M
- ISOC budget$ 1M
And then if meeting fees turn out to generate an extra 1M without extra
cost, then put the extra 1M in the reserve fund so we get to our defined
"reserve" faster.

You still seem to be thinking that there is a goal to create a separate 
IASA reserve fund.  I don't think that makes sense.  The overall ISOC 
organization will be more flexible, and more resilient with a single, 
larger reserve that can cover the full operation (including IASA) than 
it will be if we hold separate "ISOC" and "IASA" reserves.

If

Re: Consensus? #733 Outsourcing principle

[Joel M. Halpern]

I like this resolution.  I think the "review against a zero base 
assumption" captures the essential goal, and the minimum staff was a weak 
restatement.

Yours,
Joel
At 07:44 AM 1/12/2005, Harald Tveit Alvestrand wrote:

--On onsdag, januar 12, 2005 07:29:27 -0500 Scott W Brim  
wrote:

On 1/12/2005 04:51, Harald Tveit Alvestrand allegedly wrote:
In principle, IETF administrative functions should be
outsourced. Decisions to perform specific functions
"in-house" should be explicitly justified by the IAOC
and restricted to the minimum staff required, with these
decisions and staffing reviewed by the IAOC on a regular
basis and against a "zero base" assumption.
"Minimum staff required" is a little difficult.  One can do anything with
existing staff if quality and timeliness don't matter.  The IAOC has to
determine those parameters as part of deciding staffing levels.  I
suggest "minimum staff required to perform the functions satisfactorily
as determined by the IAOC", or something along those lines.
I thought that was implied by "required".. if we don't like 
"required", I think we should drop the subsentence, leaving us with:

In principle, IETF administrative functions should be
outsourced. Decisions to perform specific functions
"in-house" should be explicitly justified by the IAOC,
with these
decisions and staffing reviewed by the IAOC on a regular
basis and against a "zero base" assumption.
Less is more

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

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

Re: business deals and BCP for IAOC / IAD

[Joel M. Halpern]

Maybe I am naive, but the discussion I have seen on the list is not 
actually about something the IETF can or should "approve".  Reportedly, 
ForeTec, CNRI, and Neustar are in negotiations.  The IETF has no say in 
such negotiations.

Reportedly, what has been asked is "will the IETF react badly to Neustar 
engage in this transaction?"  My reaction to the question is:
1) It shows good sense that Neustar is asking
2) As has been noted (and probably was understood when the question was 
asked) no one is in a position to answer this definitively, nor to bind the 
community to an answer.
3) Based on what was posted, it seems unlikely to upset the applecart.

Now, there are lots of "interesting" issues in such a deal, including 
issues about who owns what intellectual property now, who will own it 
aftwards, who will own what going forward, etc.  However, that is mostly a 
matter of Neustar and CNRI having discussions, with property disclosures 
about risks and proper skepticism as is suited to any business deal.  It 
does not involve the IETF, IESG, IAB, IAOC, interim IACO, IAD, ISOC, or any 
other part of I* making assertions or conclusions.

It also, at least according to what I saw on this list, dos not involve the 
IAOC making any kind of binding committment to work with Neustar now or in 
the future.

Pragmatically, if such a deal does take place, then we will be working with 
Neustar whether we want to or not.  The fact that they appear to be 
sensitive to concerns is nice, but irrelevant.

I appreciate the interim IAOC letting us know that hey have been informed 
of such discusions, and asked certain questions.  There is no indication 
that they have over-reached themselves in responding.  There is no 
indication that anything in the BCP needs to be reconsidered or changed 
based on this.

So can we worry about the things we need to focus on for getting the BCP 
done?  Can we find some meeting point on the open issues (particularly 
review / appeal) so we can get this done?  [Oh heck.  I have written this 
much, I might as well state my opinion on this issue.]  There are clearly 
risks with either a process that invites second guessing and business 
interference, or with a process that hides everything from the 
community.  At a guess, whatever we write for this will be slightly 
wrong.  If it turns out to be seriously wrong, we will fix it.  I 
personally tend towards language that restricts the appeals / reviews 
because I would rather see a lityle too much accomplished without enough 
notice / oversight rather than see things blocked if one or the other error 
case comes to pass.  We have to pick our risks.

Yours,
Joel
At 10:13 AM 1/26/2005, John C Klensin wrote:
discussion of business deal elided.

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

Re: Version -06 of the IASA BCP - is this a workable version?

[Joel M. Halpern]

Mr. Morfin,
   The IETF works by rough consensus.  The fact that you want specific 
text added while there has not been significant support (in fact to my eye 
there has been no support) does not indicate the absence of rough 
consensus.  I agree with the opinions expressed that the text you want does 
not belong in this document at all.

   With regard to Harald's original question, I believe this document is 
"good enough".  We can refine it from now till doomsday.

Yours,
Joel M. Halpern
At 06:06 PM 2/2/2005, JFC (Jefsey) Morfin wrote:
If the question is only that, answer is "no".
Reason why, is the draft says that there is no open issue. It also 
says:"The IETF is a consensus-based group, and authority to act on 
behalf   of the community requires a high degree of consensus and the 
continued consent of the community.  After a careful process of 
deliberation, a broad-based community consensus emerged to house the IETF 
Administrative Support Activity (IASA) within the Internet Society.This 
document reflects that consensus."

Yet the request that the following text is added in Part 4 has been 
objected by you and discussed with others, on the list and off list. The 
carefull  process of deliberation is not completed, and has not lead to a 
consensus.

This text is: "International: ISOC shall work with its national Chapters, 
the IAD and IAOC to document how the IETF meetings and the Internet 
standard process could benefit from the local presence, market knowledge 
and languages familiarity of these Chapters."

jfc

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

Re: FW: Why?

[Joel M. Halpern]

This discussion seems to take as a premise the view that if we define 
applications only on IPv6, even though they could be defined on IPv4, that 
this will give people a reason to use IPv6.
It also seems to take as a premise that if we don't define ways to work 
around NATs, people won't use the applications with NATs.

The fact is that external evidence indicates that both premises are false.
For a long time we tried ignoring NATs.  As a result, people crafted many 
strange and non-interoperable ways to work with NATs.
I know of several initiatives that tried to define their protocols for 
IPv6.  Some even thought they had good reasons.  Before the work was even 
done, I saw customers requesting vendors to supporting the initiative using 
IPv4 directly.

Trying to pretend something won't work with IPv6 is not a substantive value 
add for IPv6.

Not needing NAT is a minor value add for IPv6.  But we have already seen 
several major corporations publicly indicate that they intend to use NAT 
with IPv6, even though they can get enough public address space.

As far as I can tell, following through on the kind of approach discussed 
here would simply make our products les useful, and reduce actual 
interoperability in the field.

Yours,
Joel M. Halpern
At 05:36 AM 3/11/2005, shogunx wrote:
On Thu, 10 Mar 2005, Erik Nordmark wrote:
> Tony Hain wrote:
>
> >>Why are we wasting effort in every WG and research area on NAT traversal
> >>crap???
>
> FWIW I'm also concerned that we are doing too many different NAT
> traversal protocols. It should be sufficient to just define how IPv6 is
> tunneled across NATs and start using more IPv6 in the applications.
I agree wholeheartedly.  Lets face the reality of the situation.
Carriers have abused IPv4 for financial reasons.  As a result, NAT is
widely deployed, because it was and is an effective workaround for
dealing with siad carriers trying to squeeze extra money from IP
addresses.  There is nothing that can be done about that now, except
implement the solution that has been written to solve the problem, IPv6,
right on top of the existing NAT's.  With full application layer support
for v6, NAT will eventually deprecate, and be little more than a bad
memory.  The open source community has a wide variety of v6 enabled
daemons and clients already, for almost every widely used protocol.  While
these can easily be implemented on any host, good luck getting the general
public to do so.  The solution for migration most likely lies in somebody
developing a little v6 router, that autoconfigs a tunnel with a small
allocation of addresses.
Scott
>
> >>On another topic, why is it that the API is so sacred that we will create
> >>a massive array of complex approaches to avoid defining a real session
> >>layer. We put imitation session efforts at layer 4 (SCTP), layer 3.5 
(HIP),
> >>layer 3.25 (shim), and the TRILL crap is trying to do it at layer 2.5.
>
> I don't understand what makes you think TRILL is trying to do a session
> layer. If it does, then any other routing and tunneling approach should
> also be given the same verdict.
>
> Erik
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>

sleekfreak pirate broadcast
http://sleekfreak.ath.cx:81/
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

Re: Complaining about ADs to Nomcom (Re: Voting (again))

[Joel M. Halpern]

You raise two questions about making the candidate list public.
You raise the question of whether we can afford the loss of candidates from 
those people not willing to be seen as losing.  I will admit to not being 
sure I understand the driver for people who both have that concern and 
could do the job of AD.  (I can see it for IAB membership.)  I can't swear 
that we won't lose one or two vialbe candidates, but I tend to doubt it.

You also ask about the nuances.  The details / constraints / parameters for 
a volunteer would, I think, still be confidential.  I can't see any problem 
with that information being only in the hands of the nomcom.  The public 
will not be able to tell that the nomcom might have chosen a different 
person but for some constraints.  (Heck, that is probably always the case.)

There is one reason I have heard occasionally that I wonder about.  If the 
list is made public, will this cause public second guessing based on 
insufficient information after the results are announced.  That, I think, 
would be a serious problem.

And there is some risk (small, I think) of people pushing others to endorse 
them.  This would seem easier with a public list, because the nomcom is not 
left wondering why they got the supportive email.

On balance, I think we would be significantly better off with a public list 
because of the ability to get much wider feedback.

Yours,
Joel
At 09:18 AM 5/7/2005, John C Klensin wrote:
... initial discussion of publishing candidates elided ...

Even assuming that publishing candidate lists would result in
better-quality feedback and permit the Nomcom to make better
choices among plausibly-appropriate candidates, please look at
the other side.   There are people in the community who, for
whatever reassons, find the prospect of a "volunteer, have that
public, and then not be selected" process sufficiently painful
to prevent them from volunteering... or certainly from
volunteering more than once or twice.  There are also subtle
differences in how one can volunteer that can be expressed in
confidence to the Nomcom: "I don't really want to do this, but
will serve if you conclude that it is important and I'm the best
choice" or "I can't work with X and would accept the position
only if X were not selected" are comments that can be made
today, but which don't show up on public lists.   I believe that
many of the people who would semi-volunteer with such conditions
would decline to volunteer at all if their names would go on an
undifferentiated public list.
So, those of you who strongly advocate a public list...  What
percentage of the already-too-small potential candidate pool are
you willing to lose?   Are you convinced that anyone with
sensitivities or conditions similar to those outlined above
would make a bad AD if selected?   Do you think the tradeoffs
are worth it?
  john
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

Re: Complaining about ADs to Nomcom (Re: Voting (again))

[Joel M. Halpern]

I agree that electioneering is extremely undesirable.
And it does currently agree to some degree.
The question is whether publishing the list would actually cause a 
significant increase in that behavior.  If we conclude that publishing 
would indeed result in such an increase, then that is a good reason to not 
publish the list of candidates.

But given that electioneering already goes on, and that the feedback the 
nomcom receives is somewhat affected by the question of who can manage to 
discern the candidates from the leaky information flow, I am doubtful as to 
whether it would result in a significant increase.

Yours,
Joel M. Halpern
At 01:33 PM 5/8/2005, Geoff Huston wrote:
And there is some risk (small, I think) of people pushing others to 
endorse them.  This would seem easier with a public list, because the 
nomcom is not left wondering why they got the supportive email.
A risk not without quite extensive precedent over the years, and the 
concept of overt electioneering is one that personally I find a strange 
perversion of an already somewhat strange process. Are we after the the 
judgement of a few as to the best qualified individual for the role, or 
the one who is seen as being the "most popular" on the basis of a 
concerted campaign of electioneering? What is this body again? What is its 
purpose? Why does it exist? etc.

Geoff

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

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

Re: Simplistic metrics Re: WG management

[Joel M. Halpern]

Actually, based on experience in effective and ineffective working groups, 
I don't think the 1 week (or even two weeks) suggested below is a 
reasonable measure of activity.


When I was a WG chair, there were often multi-week periods when I did not 
post anything to the list.  Sometimes this was because nothing was 
happening.  Sometimes it was because the design teams were making good 
progress.  Note that this could mean that the design team was working to 
get something coherent to post to the list, and therefore nothing appeared 
from anyone on the list.
In other working groups I have been in,  there have often been multi-week 
periods where the work is going well and there are plenty of posts on the 
list, just none from the chairs because there is no need for them to post.


So, I think measuring the chairs posting rate is not a good measure of 
anything.


Measuring activity on the working group mailing list is probably 
sensible.  But a one week time horizon is usually wrong.


Yours,
Joel

At 10:34 AM 6/21/2005, Harald Tveit Alvestrand wrote:



--On 20. juni 2005 07:39 -0500 Spencer Dawkins <[EMAIL PROTECTED]> wrote:


Two related problems here, as you pointed out in another posting - when
the WG is only active for six weeks per year, and when the WG chair is
only active for nine weeks per year. I don't see how we can focus on this
with our current milestone tracking ("no, really, we'll finish that draft
by the NEXT meeting, this time for sure"), so your comments in the
"front-end delays" thread apply here as well.


Let me offer a simplistic metric.

if a WG chair has posted nothing to the WG mailing list for a week, and 
that WG chair has not told the WG he's on holiday, that WG chair is 
probably not doing his/her job.


If NOBODY's posted to the WG mailing list for a week, it's time to close 
the WG.


Harald





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



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

Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option

[Joel M. Halpern]

To whatever small degree it matters, I agree with Brian on this.

There have been many clear statements indicating that the writer believes 
that the policy in force for the allocation of these code points is 
wrong.  The policy may be right, and it may be wrong.  But that is not the 
point.
But the policy as written in the RFC requires that the IESG review the 
proposal.  Such a review clearly implies technical review, not just a check 
for document completeness.  The IESG did what the RFC tells them to do.


Yours,
Joel M. Halpern

At 07:04 PM 6/28/2005, Brian E Carpenter wrote:

John, I'm probably replying out of sequence, and I'll say this once
again only:

I don't believe that the IESG is entitled, under the BCP in force,
to authorise the IANA to assign a hop by hop option number to
a usage that we believe clearly needs IETF technical review.
So we don't go to question 2 until we've dealt with question 1.

Brian



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

Re: S stands for Steering [Re: Should the IESG rule or not?]

[Joel M. Halpern]

As a general statement, I think this document goes too far.
Several issues occur to me reading it.  A sampling follow.

1) As written, the document seems to say that all small allocation spaces 
should be "repaired".  This does not always follow.  Making the IP version 
space bigger does not seem a desirable approach to interoperability, for 
example.


2) There are issues of appropriateness that are complex, and need to be 
considered.   For example, there is an ongoing debate in the routing area 
as to how much information, and of what kinds, ought to be carried in the 
routing protocols.  (The problem exists for both BGP and our intra-domain 
link state routing protocols.)  It would really complicate such a 
discussion if the working groups did not have the ability to say "no, there 
are uses of these fields which are wrong, and we will not encourage them be 
registering them."


3) No matter how much we claim that registration is not endorsement, it 
will frequently be seen as endorsement.


4) Allowing arbitrary values in fields which need to be understood for 
interoperability can make life very difficult.  It turns out that even when 
the protocol has planned well for unknown values, the negotiations and 
exchanges can get very tricky.  And the more extensive the set of options, 
the harder it gets.


5) There are sometimes subtleties about who is appropriate to provide the 
definitions for some values.  Particularly if the meaning relates to 
proprietary activities.  Just having clear documentation is not always 
sufficient.


6) For some purposes it is important that the document actually be right, 
not just clear.  To use a historical case, there was a request for 
registration of a number space at one time which was accompanied by I-Ds, 
etc.  It was however mathematical falsehood.  It would not 
work.  Registering it would have been a disservice to the community.  In 
that particular case, the problem was clear.  But other cases may not be so 
clear.
6') We are usually fairly careful about registering cryptographic 
algorithms, and we try to make sure that our experts think the algorithms 
make sense.  This document would seem to do away with such checks.  (I 
believe this is an example of one way that a document may be extant, and 
readable, but subtly harmful or false.)


7) There are clearly spaces / applications / domains where people can and 
should be encouraged to experiment.  But not all spaces have that 
property.  We have enough trouble with junk in spaces like DNS without 
agreeing to register any type code / meaning that someone wants to write up.


Yours,
Joel M. Halpern

At 12:11 AM 7/1/2005, Spencer Dawkins wrote:

If I may plead for a moment of silence ...

There is an Internet Draft that is intended to give the community a chance 
to provide comments on what the IETF vision of option registration might 
be - or, might not be.


If we could discuss this draft, and say things like "I agree", "I 
disagree", "goes too far", "doesn't go far enough", it seems to me that we 
might actually be able to come closer to closure in this thread (and its 
predecessors), one way or the other.


That URL, again, is 
http://www.ietf.org/internet-drafts/draft-klensin-iana-reg-policy-00.txt.


And I apologize for having nothing whatsoever to say about spamops, 
killfiles, or steering.


Thanks,

Spencer


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



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

Re: draft-klensin-nomcom-term-00.txt

[Joel M. Halpern]

I have to disagree somewhat with this line suggesting stricter limits on 
serving duration.
I agree that a lack of bench strength is a real problem that should be 
addressed.

I suspect that we may have more bench strength than we think.
I strongly suspect that with some of the other changes being discussed (I 
like the separate review idea, although I think it needs some work) there 
will be more capability to do more sane jobs.


However, defining the process so taht if we turn out to have insufficient 
bench strength we produce a disaster seems extremely bad design.  (When 
folks bring me protocol designs like that, I ask them ~are you really, 100% 
sure that problem can not occur so you don't need to design for it?~)  The 
statements as written in the draft have the nice property that there is 
some wiggle room if things look wrong.


My biggest worry is the one piece of structure that has no wiggle room.  As 
defined, if the Nomcom in phase 1 decides not to reappoint the incumbent, 
there is no way to recover if that turns out not to work.  I like the idea 
of considering incumbents on their own.  But I can not find a way to make 
the two-phase system work without severe risk of backing ourselves into a 
corner.


Yours,
Joel M. Halpern

At 08:42 AM 7/27/2005, Spencer Dawkins wrote:
I too like this draft and agree that having most IESG members serve for 
two terms is ideal and making it more the exception that people serve 
for three or four terms.  I also like the flexibility it gives the 
NOMCOM without creating strict term limits.


When someone is "needed" for more than two terms, what does that say 
about the state of their area?


The IETF is based on the commitment of community participation, rather 
than the brilliance of individual leadership.


If we do not have multiple, acceptable choices for an AD slot, then we 
have a deeper problem with the Area (and/or with the job of being AD, of 
course.)


What would happen if the term limit were firm, with no exceptions?


John Klensin keeps telling me that we do better when we don't have 
absolute prohibitions in our processes.


In this case, I think he's trying to have enough flexibility that (for 
instance) if you have just replaced one AD in an area and some event 
happens that makes it impossible for the newest AD to serve, you don't 
have to replace the other AD AND the first AD's replacement in the same 
NOMCOM, just because the BCP says "two terms and out".


I'm OK with this level of flexibility.

Do I think we could survive replacing both ADs in one NOMCOM? It hasn't 
happened often, but it has happened (isn't Routing the most recent 
example? and we still have a Routing Area).


I am sympathetic to Dave's concern about areas that don't have "AD bench 
strength". The draft still allows ADs to serve in a fourth term. If you 
can't replace an AD after three terms (one for training, one for effective 
leadership, and maybe one for transition), I think that's really, really bad.


I would hope most NOMCOMs would be comfortable with replacing both ADs in 
the same cycle, but if the longer-serving AD has a bunch of working groups 
that are winding down, the NOMCOM might reasonably say "we'll replace this 
AD next year" - and if the BCP allows this, it might be the right thing to do.


Spencer


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



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

Re: On standards review panel and division of work

[Joel M. Halpern]

I think the concept of separating the responsibility for final document 
review and approval from the responsibility for chartering and managing 
working workings.
Yes, there are some tricky details.  But it looks like they are solvable 
and the approach leads to improvement in several regards.


Yours,
Joel M. Halpern

At 06:09 AM 8/4/2005, John C Klensin wrote:
See my note posted a short time ago (which was written before seeing 
yours).  But, yes.This is exactly the thing I was commenting about in 
that note.  It is, at some level, a detail. It can be tuned in any of a 
number of ways.  I picked one, not quite at random.  You suggest a 
different one above.  I think we need to decide the concept is worthwhile 
(I'm not sure there is consensus on that yet), and then sort through these 
details. IMO, the "I don't like that detail so the proposal is invalid and 
should not be considered" approach is just not a productive way to proceed.


john



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

Re: I'm not the microphone police, but ...

[Joel M. Halpern]

I think the companies deserve a minimal amount of recognition for 
supporting our participation.
And our place in the world informs our perspectives.  That is why it is 
common in the routing discussions to have the question "how many people in 
this room are operators?"  We want their perspective.


Yours,
Joel M. Halpern

At 06:00 AM 8/6/2005, Keith Moore wrote:
I actually think IETF might function better if nobody's badge had his 
company's name on it, and nobody used a company email address.  People 
place way too much importance on someone's employer.  Yes, sometimes 
people break the rules and speak for their employers, but it's not wise to 
assume that this is the case.


As for those who want to acknowledge who pays the travel bills - It 
doesn't matter who pays the bills.  What matters is whether what's being 
said makes good technical sense.


Keith

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



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

Re: [Re: regarding IETF lists using mailman: nodupes considered harmful]

[Joel M. Halpern]

I really hate lists with "reply-to" pointing to the list.
I know when I want to reply to the list, and when I want to reply 
individually to the sender.  When reply-to points to the list, it is 
extremely difficult with most mailers to send a reply to the originator.


Yours,
Joel

At 11:49 AM 8/26/2005, you wrote:

On 26-aug-2005, at 10:33, Peter Dambier wrote:


Hi Jeroen,



I forwared your message - not replying to show your headder:



From: Jeroen Massar <[EMAIL PROTECTED]>
To: Keith Moore 
Cc: ietf@ietf.org



So you had sent to [EMAIL PROTECTED]
ietf@ietf.org received only a copy. Some people might have got
nothing.



My own Mozilla/Thunderbird behaves the same way:



I would have had to manually change to/cc for all recipients.



That is what we all need to do now if I got it correctly.


No, what needs to happen if we collectively decide we don't want the
current behavior is that the mailinglist software sets a "reply-to"
header, so when you hit "reply" or "group reply" your reply is sent
with the list in the "To:" field and nothing else. This used to work
well, not sure if modern clients handle this correctly, though. Try
to reply to this message to see what happens.

(BTW I got so fed up with receiving endless CCs for each discussion
thread I've ever posted to (you can actually manually remove those,
people!) that I now have procmail remove all messages with duplicate
msgids.)

Iljitsch

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



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

Re: Last call comments on LTRU registry and initialization documents

[Joel M. Halpern]

This document defines structure and meaning for labels, as well as the 
procedure for registering parts of that structure.
As such, the structure is "bits on the wire" and is subject to 
interoperability concerns.


Yours,
Joel M. Halpern

At 03:14 PM 9/6/2005, Sam Hartman wrote:

John, what does it mean to put a registry document on the standards
track?  In particular, how do you get multiple implementations of a
registry?

--Sam


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



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

Re: IETF Process Evolution

[Joel M. Halpern]

Two observations:
1) Having been an active participant in the Nomcom working group, it is 
amaxing it actually worked.  The process took an absurdly long time to 
converge on a very small set of changes.  Having tried to drive ICAR, which 
many people said was important, I again conclude that WGs are just the 
wrong tool for this.


2) If we were at the point that we knew that the changes below were what we 
wanted, that might be reasonable.  But at the moment we have a polarized 
community who collectively want multiple incompatible things.  And they 
want them all now.  A working group will not resolve such a situation.


Yours,
Joel

PS: I don't know if Brian's proposal is the right answer.   But it is sure 
a heck of a lot better than chartering anotehr working group.



At 03:22 PM 9/16/2005, Ted Hardie wrote:

At 1:39 PM -0500 9/16/05, Spencer Dawkins wrote:
>
>While it seems plausible that we could use the same mechanism for 
protocol design and for process evolution, my understanding of the 
Problem working group's efforts and the subsequent 
newtrk/icar/proto/mpowr (and yes, there were others) efforts is that this 
approach simply does not work.


Spencer,
"simply does not work" is good rhetoric, but it doesn't fit all 
the facts.

Groups like NomCom and IPR have taken on tasks and done them, with community
discussion of their charters and with community discussion as their documents
went through the process.  They are process change groups, and they work.
Let's say I put forward a charter like the following:


>WG Name:  New Queues (NQ)
>Description of Working Group:
>
>The IETF has too many decisions passing through the same body, the IESG.
>The creation of the IASA and IAD has removed one set of tasks from that 
queue,

>but there are a considerable number of others which might be moved.
>
>In order to return the IESG to its historic task of managing working 
groups and
>their output, this working group will describe a process by which new 
decision
>making queues can come into being.  While the process will be general, 
the working
>group will fully specify the creation of a process management decision 
making
>body.  Among other targets for new queues:  oversight of registered 
values in IANA
>registries; IETF responses to RFC-Editor queries related to RFC-Editor 
published documents;

>approval of experimental and informational documents that are not created by
>working groups.
>
>Goals and Milestones:
>
>1st Draft of document describing general queue creation mechanism
>
>1st Draft of document describing process management decision making body
>
>2nd Draft of GQCM
>
>2nd Draft of PMDM
>
>WGLC GQCM
>WGLC PMDM
>
>Publish QGCM
>Publish PMDM
>
>Re-charter to use GQCM for new queues, or close.

Can the IETF community not discuss whether this is the output it 
wants
and this is the direction of change it wants in terms of this charter?  It 
may say "no",
but how to say yes or no to a charter is pretty clear, as is how to 
participate in the
group or react to its output.  Using an ad hoc mechanism to get from the 
existing
process change mechanism to a new one would work well if we had strong 
consensus
on where we want to go in process change, but that is the same condition 
in which
working groups achieve success as well.  If we do not have strong 
consensus on the

desired process change, the ad hoc mechanism has far muddier mechanisms by
which it is created, by which people participate, and by which its output 
may be
challenged.  The most obvious mechanism for the last is for someone to put 
forward
an alternate proposal.  If there are alternate proposals than those coming 
from the design

team, how do you want to decide among them in the absence of a working group?
Sure, we can invent all kinds of mechanisms to handle it that are equally 
ad hoc, but
as I said in the Paris plenary, the hard but probably right answer is to 
use the
existing mechanism one last time to replace it, then move on.  That will 
require
a lot of work from the Area Director, the WG Chair, and the community, but 
it is

still the right answer.
regards,
Ted Hardie

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



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

Re: EARLY submission deadline - Fact or Fiction?

[Joel M. Halpern]

There is an aspect of the deadline that is helpful for me, even when the 
deadline is not rigidly enforced.
The presence of the deadline means that the bulk of I-Ds are in by the 
deadline, and are out by not too long after the deadline.  This means that 
I can collect announcements for I-Ds of interest and have time to read the 
I-Ds across most of the range of working groups that I try to stay current on.
If working groups as a matter of course published I-Ds within a few days of 
the meeting, it would be almost impossible for me to read most of what I 
need to in order to be an informed participant.


Yours,
Joel

At 01:10 PM 11/29/2005, Dave Crocker wrote:

...
A simpler rule is that the working group gets to decide its deadlines and 
what will be discussed at the meeting.  (All of this is predicated on 
moving towards fully automated I-D issuance.)



d/
--

Dave Crocker
Brandenburg InternetWorking


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



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

Re: I-D ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt

[Joel M. Halpern]

While I applaud the sentiment, I believe as written this is an unfortunate 
and undesirable constraint.

Something along the lines of:
The IETF should endevour to choose venues where all participants who 
choose to can attend the meeting

would seem to capture the goal as a goal.

Yours,
Joel M. Halpern

At 04:01 AM 1/22/2006, Brian E Carpenter wrote:

>  Meetings should not be held in countries where some
>  attendees could
>   be disallowed entry or where freedom of speech is not
>  guaranteed for all participants.


This is a very important issue as we consider visiting countries we've never
visited before and as visa regulations change in countries we have been
to often. It would be very useful to know how more people feel we should
tune these criteria.

   Brian



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

Re: John Cowan supports 3683 PR-action against Jefsey Morfin

[Joel M. Halpern]

Assuming I have properly understood Mr. Morfin's email, the best argument I 
have seen for permitting all IETF email list adminsitrators to ban him as 
they deem necessary is his own description of his behavior.


Mr. Morfin appears to have stated that if he feels an opinion is important 
he will push for it (as he should.)  He has also indicated that he will 
keep pushing for it on any and all mailing lists even after the working 
group chair has determined that a rough consensus exists.


If I have understood his postings in this discussion correctly, Mr. Morfin 
has specifically indicated that he intends to behave in ways that are not 
in accord with the rules.  It seems to me that the sensible response to a 
notice of intended misbehavior is to be prepared to respond immediately and 
directly to such behavior.


The proposed action specifically gives the list managers / chairs that 
necessary authority in the light of Mr. Morfin's exhibited and asserted 
behavior.


Yours,
Joel M. Halpern


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

Re: I-D ACTION:draft-hartman-mailinglist-experiment-00.txt

[Joel M. Halpern]

This experiment is a good idea.

Joel M. Halpern

At 06:50 PM 1/24/2006, you wrote:
A New Internet-Draft is available from the on-line Internet-Drafts 
directories.



Title   : Experimental Procedure for  LongTerm 
Suspensions from Mailing Lists

Author(s)   : S. Hartman
Filename: draft-hartman-mailinglist-experiment-00.txt
Pages   : 8
Date: 2006-1-24

   Discussion in the community has begun to question whether RFC 3683
   and RFC 3934 provide the appropriate flexibility for managing IETF
   mailing lists.  This document is an RFC 3933  experiment designed to
   allow the community to experiment with a broader set of tools for
   mailing list management while trying to determine what the long-term
   guidelines should be.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hartman-mailinglist-experiment-00.txt



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

Re: I-D ACTION:draft-hartman-mailinglist-experiment-00.txt

[Joel M. Halpern]

As I read the description of the experiment, when the IESG decides on the 
appropriate response to a specific case, they can decide whether that 
response is a single-list response or a multi-list response.


Yours,
Joel

At 07:03 PM 1/26/2006, Spencer Dawkins wrote:

I agree. One question...

As best I can see, the proposed experiment is silent on whether suspension 
from one list has any effect on suspension from other lists, so I'm 
assuming this aspect of RFC 3683 still applies?


(Text is something like "maintainers of any IETF mailing list may, at 
their discretion, also remove posting rights to that IETF mailing list" 
for a period of time not to exceed the remaining period of the suspension 
from any other IETF list?)


Thanks,

Spencer



This experiment is a good idea.

Joel M. Halpern




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



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

RE: I-D ACTION:draft-ash-alt-formats-01.txt

[Joel M. Halpern]

Aside from the issues already raised on the list, I see some other problems.

First and foremost, if the input format is PDF, how will the RFC Editor 
edit the document?  PDF documents are not editable.


Secondarily, as a lesser matter, for the WG / Documents that get selected 
for the experiment, can you indicate what composition tools (editors) are 
likely to be suitable for producing this?  Are we going to be requiring 
that the document editors for those documents have and use word?  (Or Open 
Doc, or ...)  Or are we expecting them to find their own tools to 
participate in the experiment?


Thirdly, it would probably be a good idea to have greater clarity on 
judging success.  If the WG loved it, and the IETF list is divided, and ... 
which condition is most important, and why?  Given that the impact of this 
experiment is quite broad, I think that clarity on the judgement is important.


Yours,
Joel M. Halpern

At 11:29 AM 1/31/2006, Ash, Gerald R \(Jerry\), ALABS wrote:

Hi All,

As a follow-up to our recent discussion, please review the draft at
http://www.ietf.org/internet-drafts/draft-ash-alt-formats-01.txt,
.pdf version available at
http://www.ietf.org/internet-drafts/draft-ash-alt-formats-01.pdf.

We propose an experiment based on RFC 3933 allowing, in addition to
ASCII text as a normative input/output format, PDF as an additional
normative output format.

We look forward to your comments and suggestions.

Thanks,
Regards,
Jerry, Stewart, Yaakov



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

Re: Reminder: Copyright 2006

[Joel M. Halpern]

Actually, the copyright notice covers more than just the boilerplate.
The authors retain their copyrights (there is no "transfer" of rights 
as confuses some folks sometimes.)
However, the IETF needs a right to copy (a copyright) so as to 
distribute, and work on, the Internet-Drafts and RFCs.

The text of the boilerplate grants us those rights.
Those rights are now invested in the IPR trust, and managed by the 
trustees (who are also the IAOC.)


Making sure we get those rights correct goign forward is part of that 
the IPR working group is dealing with.


Yours,
Joel

At 11:27 AM 3/5/2006, John C Klensin wrote:

The position taken over and over again in the
IPR WG is that the ISOC (or "Trust") copyright applies to the
boilerplate and structure, not to the substantive text and that
ISOC and the IETF use that text only by releases from the
authors.



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

Re: Suggestion on a BCP specific WG...

[Joel M. Halpern]

A) BCPs have an issue date.  They are the best current practice at 
the time of issue.  There is no requirement that we maintain them, 
although we like to.
b) There is, as far as I can tell, no intellectual property issue 
relative to BCPs that needs to be managed by anyone.

c) There is not any issue I know of to manage with the "collection" of BCPs.

Yours,
Joel M. Halpern

At 12:37 PM 3/14/2006, todd glassey wrote:

Not that you folks take suggestions from me - but there would be a
tremendous value in creating a specific BCP WG that was a permanent part of
the IETF to manage the collection and IP issues within BCP's.



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

RE: Guidance needed on well known ports

[Joel M. Halpern]

I would not that starting dynamic ports above 1024 or even above 4096 
is not sufficient.  There are already services with assigned ports 
higher than that.  And it keeps growing.  The IANA list of well-known 
ports is quite long.


If we could go back and start over, something like dynamic DNS and 
SRV records would get us out of the mess.  But that is not a viable choice.


Yes, whenever possible one starts services before applications which 
grab dynamic port numbers.  Unfortunately, that sometimes does not work.


All that aside, the IANA has a distinction (based on history) between 
ports below 1024 and those above.  And whne asking for a port number 
assignment, one specifies which range one wants.  I had least can not 
find a coherent strategy for what should be on one side or the other 
of that boundary.


Yours,
Joel

At 03:41 PM 3/18/2006, Christian Huitema wrote:

> A more interesting question is this: what are the odds that a user
> process will accidentally grab the port number before the system
> process gets to it?  The notion of a "privileged" port number is
> certainly preposterous; that said, putting services in a range that
> ordinary applications tend not to use has its merits.

There are two issues there, accidental collision between a dynamic port
and a service port, and "voluntary" collision between applications
trying to open the same port.

The practical solution to the first problem are to start services and
grab ports as part of the boot sequence, i.e. before user processes
start, and start dynamic allocations at some high number (e.g. larger
than 1024 or larger than 4096 or some admin defined value depending on
system version and configuration). If there is a reserved range, then it
is easy to start dynamic allocation outside the range.

Starting services quickly also helps with the "voluntary collisions"
between system services and applications, but is not foolproof. In any
case, it does not help with collisions between applications, e.g. two
applications trying to use the same port. What does help there is an
easily accessible registration system, so application developers can
easily "do the right thing", i.e. reserve a port and avoid collisions.
Note the emphasis on "easily accessible": if there are too many hoops to
jump through, the developers will likely just pick a number at random.

-- Christian Huitema


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



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

RE: Guidance needed on well known ports

[Joel M. Halpern]

While in general I would like to see this approach taken, this 
particular case is a perfect example of where I think one can not 
reasonably do that.  The protocol is for the purpose of configuring a 
router.  The router that needs to be configured could easily be 
between the network engineer and the DNS server.  The protocol can 
not rationally depend upon DNS (no matter how much I like the 
elegance of removing ports, using dynamic port numbers, and using dynamic DNS.)

Yes, we could invent a better way to make things work.  And maybe we should.
But Netconf should not be held up waiting for that to be developed.
Until we develop such a beast, we have to use port numbers.
Given that constraint, what guidelines ought to be used for whether a 
protocol gets a port number above or below 1024?


Yours,
Joel

At 05:09 PM 3/18/2006, Hallam-Baker, Phillip wrote:

Content-class: urn:content-classes:message
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
micalg=SHA1; boundary="=_NextPart_000_0011_01C64AAE.C23D25B0"

The whole idea of fixed ports is broken.

The idea that there are only 1024 or even 65535 Internet applications is
broken.

The Internet has a signalling layer, the DNS. Applications should use it.
The SRV record provides an infinitely extensible mechanism for advertising
ports.

Fixed ports do not work behind NAT. Anyone who wants to deploy IPv6 would be
well advised to pay careful attention to that restriction. SRV ports work
just fine behind a NAT.


IANA should be told to close the well known ports registry. Applications
should use DNS SRV records for service location.





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



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

Re: 2 hour meetings

[Joel M. Halpern]

I agree that having presentations which review all the detailed 
context is not helpful.  One slide reminding folks of context can be 
very helpful even for folks who have been reading and following all the drafts.


At the same time, I have always found it very helpful that different 
working groups are meeting at the same time, and that I can attend a 
number of different things.  I typically follow activities in 2 or 3 
(sometimes even 4) different areas.  And I do benefit from being 
there for the face-to-face discussion of issues (at least when the 
working group works properly.)


Yours,
Joel M. Halpern

At 12:56 PM 3/25/2006, Andy Bierman wrote:

Edward Lewis wrote:

At 15:51 +0100 3/25/06, Brian E Carpenter wrote:


If somebody comes to the IETF for a two hour meeting and wastes
the opportunity of another 30+ hours of learning about what other
WGs and BOFs are up to, that would indeed be a shame.
I agree with this, but find that (in some instances) that meetings 
are run counter to this goal.
I sat in an session outside my area of experience and heard this 
from the first speaker, "if you haven't read the drafts, you 
shouldn't participate here.  Therefore I will not have slides and 
dive into the details."  As this was outside my area of experience, 
I had not taken the time to read up on the session. I figured that 
having scribed for it at the previous meeting would give me enough cover.
Before each speaker in that session, the question "who has read" 
was asked, with few hands going up each time.  It would be far more 
helpful to try to be "inclusive" rather than "exclusive" towards us tourists.
If the IETF wants to foster cross-fertilization, which is the 
reason for the mass enclaves, then temper the theme of "you must 
have read all the drafts."  Temper, not "remove."  Taking a few 
moments to set the problem up for the uninitiated and then assuming 
they have the protocol engineering smarts is all I'm asking.



IMO, the purpose of a Working Group meeting is to gather
people together to work.  If 40 out of 45 people come to
the meeting totally unprepared to work on the stated agenda,
then don't be surprised if you don't get any work done.
The purpose is not to explain the entire draft to tourists
with slideware.

If the purpose of all our face to face meetings is to foster
cross-area review and not for WGs to get any work done, then
I guess this is not a problem.  IMO, 1 out of 3 of these
non-work-oriented meetings would be plenty, and 3 out of 3
is clearly harming productivity.


Andy


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



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

RE: Stupid NAT tricks and how to stop them.

[Joel M. Halpern]

If we are willing to accept arbitrarily long paths to get from point 
A to point B, there are techniques which allow topologically 
insensitive packet handling.  The Home-Register (aka HLR lookup) is 
one way.  (The routing reserachers have described this topic as 
"stretch > 1" routing.  There are many non-deployable ideas 
there.  If we really didn't care about path distortion at all, I am 
sure something deployable could be crafted.)
Note however that local number portability is actually a bad 
analogy.  The phone system internally does not work on phone numbers 
any more (it once did).  Your phone number is really more akin to an 
identity.  Phone you call someone, the system does a name lookup (ala 
DNS) and then gets a routable location.


Yours,
Joel

At 10:48 AM 3/28/2006, Gray, Eric wrote:

To: [EMAIL PROTECTED], ietf@ietf.org
Subject: RE: Stupid NAT tricks and how to stop them.

Noel,

I think the "street address" analogy is not close
enough - anymore than longitude and latitude numbers or
any other description of physical location.

The problem with physical location portability is
that the location remains even if you're not in it.  So
someone else might need to describe their own physical
location using the same description.

Number assignments, however are substantially more
portable.

It is certainly possible for an IPv6 address pool
manager to allocate personalized IPv6 addresses from an
IPv6 address pool that they manage and thereby assume
responsibility for end-delivery (by any means possible)
- thus providing for indefinite address portability.
In this sense, this is more analogous to phone number
portability or tax identifiers.

--
Eric



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

RE: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]

[Joel M. Halpern]

If I the only choices available are widespread PI and widespread NAT, 
then we need to really change the way we approach things.  Either of 
those is a very bad answer.


Now, at least some of the folks supporting this PI assignment 
initiative have indicated that they do not believe it will be 
widespread (either because the barriers will still be high or because 
the demand for BGP based multi-homing is small, or maybe for some 
other reason.)  If that assumption is correct, then the comparison 
with NAT is irrelevant.


Yours,
Joel M. Halpern

At 06:57 PM 4/17/2006, Terry Gray wrote:


On Mon, 17 Apr 2006, Noel Chiappa wrote:

> PI is like spam - it looks attractive to the people using it, because it's
> free to them. The fact that it costs *other* people money is something
> they don't care about - it's not coming out of their pocket.

Noel,
While I might have chosen a different metaphor, I can agree with
the basic point, yet I wonder:

Would you agree with the thesis that *without* pervasive PI, the
future of NAT (or some other mechanism for providing address autonomy
to organizations) is absolutely guaranteed forever (even with v6)?

To me, that seems obvious, so I'd be interested in counter arguments.
It does make me wonder if there is any hope for resurrection of 8+8...

-teg

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



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

Re: LC on draft-mankin-pub-req-08.txt

[Joel M. Halpern]

Reading this, a few items caught my eye.

The POSTEDIT requirements seem to be worded as if it is desirable to 
minimize the changes that the document editor makes, or even the 
changes the document editor can make.  The general tone of "don't 
mess with the words we have carefully honed" is 
understandable.  However, in practice many of the words have not been 
carefully honed.  And they need to be.  For example, there is a 
document I just reviewed to which my personal reaction is "this needs 
massive editing."  It is not technically wrong.  But the language use 
makes it hard for the reader to understand what is intended.  I would 
sincerely hope that if it is approved as-is by the IESG that the RFC 
Editor would edit the document.
In general the editor has little or no way to tell which words are 
"carefully crafted."  I would hate to have a presumption that all the 
words a sacrosanct.
I realize that the text calls out the special case of "don't touch a 
letter of this", and even acknowledges that it is a rare case.  But 
the wording of the earlier text is not in line with 
that.  Specifically, POSTEDIT-4 reads "The IETF Technical editor 
should refrain from changes to improve readability that may change 
technical and consensus wording."  This appears to be a directive 
that prohibits almost all changes, since in a formal sense all the 
words in an WG and IETF LC approved document are "consensus 
wording."  That leads to what I consider a bad situation where we 
have essentially prohibited the editor from editing.


On a related note, POSTEDIT-3 seems to be inadvertently worded too 
strongly.  It prohibits changes which "introduce a substantial review 
load but only provides incremental increase in the clarity of the 
specification."  However, by definition any change at all, even a 
significant change that transforms a document from unintelligible to 
highly readable, is always an "incremental increase in the clarity of 
the specification."


With regard to the metrics, I think that it would be helpful to 
separate the notion of having metrics from the specific values.  I 
would suggest moving the specific values to an appendix, with a 
notation that these values are advisory and based on IETF perception 
at the time of writing.  I don't want to lose the numbers, but I 
think that they have a different status as requirements than the 
point that these time frames should be tracked, and should have well 
understood targets.  Separating this also allows for negotiation of 
cost-benefit tradeoffs without violating "requirements."



As a minor matter, figure one is trying to make a useful statement, 
but one of the headings caused me to have to spend more time staring 
at the figure, rather than making things clearer.  In the row labeled 
"Actors", WGLC and IETF LC appear.  Those are states, not 
actors.  Also, the action listed (Formal Reviewing) does not, as far 
as I know, currently occur during those phases.  The formal reviewing 
occurs after IETF LC ends, during IESG deliberations.


Yours,
Joel M. Halpern


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

RE: LC on draft-mankin-pub-req-08.txt

[Joel M. Halpern]

I can live with that.
And I hope so can those who want to be restrictive as to what editing 
takes place.


Yours,
Joel

At 09:27 PM 5/25/2006, Stephen Hayes (TX/EUS) wrote:
After some consideration, I can understand how the current text in 
mankin-pub-req would be discouraging to the technical publisher.


If we changed "refrain from" to "exercise restraint in making" in 
requirements POSTEDIT-3 and POSTEDIT-4, I assume this would solve 
Joel and John's concerns.


The question now is if I will get shot from the "keep your grubby 
hands off my document" crowd.


Stephen



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

RE: The Emperor Has No Clothes: Is PANA actually useful?

[Joel M. Halpern]

In reading the PANA Framework document,  what I read seemed to me to 
be more of a "system" or "solution" document than a clean IETF 
protocol framework.


I saw efforts to address three different problems:
1) Securing an otherwise unsecured link, when the access node is not 
known to the client in advance.

2) Selecting an authorization (charging, possibly packet handling) service
3) Authenticating the user

EAP over IP (or UDP, or link) is about authenticating the user.  If a 
media independent technique better than just using a browser is 
needed, then solve that problem.  Personally, I would find the work 
far more persuasive if it did not also try to solve the problem of 
creating an IPSec association to the access device, nor of the 
authorization selection problem.


And spell out in clear English what use case needs that problem 
solved.  I can read between the lines and start to guess.  But the 
document is quite unclear.  The appendix about DSL is not helpful in 
that regard.


Yours,
Joel M. Halpern


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

Re: The Emperor Has No Clothes: Is PANA actually useful?

[Joel M. Halpern]

I have to disagree.
Firstly, if many of us reading the document can not figure out what 
problem it is solving, then the framework is not doing its job.
Secondly, if there are existing, viable, deployed solutions to the 
problem that the WG is attempting to solve then the WG needs to 
explain somewhere (the framework document would seem the obvious 
place) why there is a need for a new solution.


I am not claiming that the PANA protocol can't work.  As was said 
many years ago "with sufficient thrust, pigs will fly."  But that 
does not make flying pigs a good thing.


Yours,
Joel M. Halpern

At 11:34 AM 5/26/2006, Dave Crocker wrote:



Joel M. Halpern wrote:
EAP over IP (or UDP, or link) is about authenticating the user.  If 
a media independent technique better than just using a browser is 
needed, then solve that problem.  Personally, I would find the work 
far more persuasive if it did not also try to solve the problem of 
creating an IPSec association to the access device, nor of the 
authorization selection problem.

And spell out in clear English what use case needs that problem solved.
I can read between the lines and start to guess.  But the document 
is quite unclear.  The appendix about DSL is not helpful in that regard.



Although not a guaranteed way to distinguish among criticisms, it 
can be helpful to categorize them as either "It will not work" 
versus "I don't like it". The former indicates a basic technical 
flaw, and the latter a matter of preference.


If it is common for readers of a specification to fail to understand 
what it is for then it has, perhaps, the most basic kind of 
technical flaw.  How can a specification succeed if there is 
confusion about its implementation or use?


By contrast observations such as "there are better solutions" moves 
into the fuzzier and more subjective realm of trying to predict 
market preferences. The IETF is not very good at making these 
predictions.  Absent any indication of actual harm that would ensue 
from publishing a specification, fear that no one will adopt it or 
that there will be multiple solutions seems an inappropriate basis 
for denying publication.  (On the other hand, strong indication of 
community interest in deplying a specification is supposed to be a 
factor in deciding whether to charter the work in the first place; 
however as Sam noted, we are rather late in the process.)


In any event, I would claim that concerns over who will use PANA 
fall into the "I don't like it" category, since it basically seeks 
to make statements about market preferences, which is a small step 
from personal preferences.


Having looked over this thread and the -framework document a bit, I 
find myself unclear which of the two lines of concern is being 
pursued, although I impressed by the degree of confusion about PANA 
after what appears to be considerable effort to understand it.  This 
does not bode well for community understanding, and that of course 
does not bode well for adoption and use.


I would find it particularly helpful to have a concise statement 
from someone who says that PANA will not work.  Cannot be 
implemented (properly) by virtue of technical errors or 
documentation too confusing to understand.  Or cannot be deployed 
and used, by virtue of administrative complexity or, again, 
documentation too confusing to understand.


Absent this, I will ask why it is productive to note that the 
emperor is pursuing an idiosynchratic sartorial style?


d/

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



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

Re: The Emperor Has No Clothes: Is PANA actually useful?

[Joel M. Halpern]

I think the confusion and complexity that I perceive comes from the 
fact that the framework problem treats all the tasks (user 
authentication, network selection, and securing the network 
connection as being of the same significance or same relationship to 
the solution.


I think that most of the discussion of IPSec and pre-post PANA 
addresses does not belong here at all.


Let me suggest an approach that might simplify and shorten the document:
[Unfortuantely, I can't promise that it will fix everyone's problems.]

2. Describe the primary goal of PANA, and approach thereto.  This 
would state that the goal is to authenticate the user using an IP 
level protocol.  This would probably state that the primary approach 
is to proivde a transport for EAP that meets the requirements for an 
EAP transport [cite RFC.]


3. Describe very briefly the interaction between the EP and the 
PAA.  State that the protocol between them is out of scope.  Note 
that the EP must allow PANA messages to the PAA before authentication 
is completed.  (Yes, that's obvious, but it is actually worth stating.)


4. Describe that PANA protocol needs to provide for negotiation of 
information before authentication.  List briefly some of the things 
to be negotiated (services available, algorithms available.)  Also 
indicate that the PANA protocol can provide additional 
post-authentication information to the client (in the PANA response) 
and to the EP.


Securing the data channel between the PCC and the EP should be out of 
scope.  If you want to say anything about that, you might note that 
this may be done in a link specific fashion, in may be done with an 
unauthenticated IP exchange before PANA, or PANA may be used to carry 
additional credentials / keys to be used to establish an 
authenticated secure association.  The reason I would not include 
this is that the question of why I need an authenticated exchange 
will complicate the document.  The other reason for not describing it 
is that it does not change the framework at all, and should be 
documented as a usage of PANA capabilities, in its protocol RFC.


I would then probably dramatically reduce section 10.  Trying to 
describe all those cases does not actually help the reader get the 
mental model.  And I think they are too deployment specific.


The real key here is to focus on the primary goal.  The resulting 
document ought to be clearer, and focused on the problem that needs 
to be solved.  It can indicate that PANA can be used to help other 
things, but that those things are not the purpose / point of PANA.


At 12:29 AM 5/30/2006, Yoshihiro Ohba wrote:

Hi Joel,

Thank you for spending your time reading the framework document and
sending your feedback.  Please see my response below.

On Fri, May 26, 2006 at 08:27:29AM -0400, Joel M. Halpern wrote:
> In reading the PANA Framework document,  what I read seemed to me to
> be more of a "system" or "solution" document than a clean IETF
> protocol framework.

I think your reading is correct.  The document describes how different
types of access network deployments are enabled by PANA.

>
> I saw efforts to address three different problems:
> 1) Securing an otherwise unsecured link, when the access node is not
> known to the client in advance.
> 2) Selecting an authorization (charging, possibly packet handling) service

Just to make sure, do you mean by 2) network selection that is
described in Section 8 of pana-framework draft?

> 3) Authenticating the user
>
> EAP over IP (or UDP, or link) is about authenticating the user.  If a
> media independent technique better than just using a browser is
> needed, then solve that problem.

This is surely one problem PANA is trying to solve, and has been
clarified from the beginning of the work and more in this dicussion, I
believe.

> Personally, I would find the work
> far more persuasive if it did not also try to solve the problem of
> creating an IPSec association to the access device, nor of the
> authorization selection problem.

Bootstrapping lower-layer ciphering (IPsec and link-layer ciphering)
from EAP-based network access authentication is another problem.  When
a lower-layer does not provide EAP service, it is clear that PANA is a
standard way to solve the problem.  Perhaps the main confusion is
coming from the fact, as a side effect of solving this bootstrapping
problem, that it is possible to use PANA to bootstrap lower-layer
ciphering *even if the lower-layer supports EAP*.  While I understand
the confusion but let me explain several reasons for why I think this
is still viable for lower-layers that support EAP.

- Use of PANA for bootstrapping IKEv2.  I explained several reasons
for why doing this while IKEv2 can carry EAP, in my response to Vidya:
http://www1.ietf.org/mail-archive/web/ietf/current/msg42002.html.

- Use of PANA for bootstrapping IEEE 802.11i PSK mode.  This make

Re: LC on draft-mankin-pub-req-08.txt

[Joel M. Halpern]

Reading this, a few items caught my eye.

The POSTEDIT requirements seem to be worded as if it is desirable to 
minimize the changes that the document editor makes, or even the 
changes the document editor can make.  The general tone of "don't 
mess with the words we have carefully honed" is 
understandable.  However, in practice many of the words have not been 
carefully honed.  And they need to be.  For example, there is a 
document I just reviewed to which my personal reaction is "this needs 
massive editing."  It is not technically wrong.  But the language use 
makes it hard for the reader to understand what is intended.  I would 
sincerely hope that if it is approved as-is by the IESG that the RFC 
Editor would edit the document.
In general the editor has little or no way to tell which words are 
"carefully crafted."  I would hate to have a presumption that all the 
words a sacrosanct.
I realize that the text calls out the special case of "don't touch a 
letter of this", and even acknowledges that it is a rare case.  But 
the wording of the earlier text is not in line with 
that.  Specifically, POSTEDIT-4 reads "The IETF Technical editor 
should refrain from changes to improve readability that may change 
technical and consensus wording."  This appears to be a directive 
that prohibits almost all changes, since in a formal sense all the 
words in an WG and IETF LC approved document are "consensus 
wording."  That leads to what I consider a bad situation where we 
have essentially prohibited the editor from editing.


On a related note, POSTEDIT-3 seems to be inadvertently worded too 
strongly.  It prohibits changes which "introduce a substantial review 
load but only provides incremental increase in the clarity of the 
specification."  However, by definition any change at all, even a 
significant change that transforms a document from unintelligible to 
highly readable, is always an "incremental increase in the clarity of 
the specification."


With regard to the metrics, I think that it would be helpful to 
separate the notion of having metrics from the specific values.  I 
would suggest moving the specific values to an appendix, with a 
notation that these values are advisory and based on IETF perception 
at the time of writing.  I don't want to lose the numbers, but I 
think that they have a different status as requirements than the 
point that these time frames should be tracked, and should have well 
understood targets.  Separating this also allows for negotiation of 
cost-benefit tradeoffs without violating "requirements."



As a minor matter, figure one is trying to make a useful statement, 
but one of the headings caused me to have to spend more time staring 
at the figure, rather than making things clearer.  In the row labeled 
"Actors", WGLC and IETF LC appear.  Those are states, not 
actors.  Also, the action listed (Formal Reviewing) does not, as far 
as I know, currently occur during those phases.  The formal reviewing 
occurs after IETF LC ends, during IESG deliberations.


Yours,
Joel M. Halpern


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

Re: Remote Participation Services

[Joel M. Halpern]

Keith, you seem to be asking for something (discussion, wit no 
presentation), that has never happened in the WGs I have attended in the 
last 20 years.  Even the WG sessions that had the best, most useful, 
discussions, generally started with a presentation of the topic and issue.


Such initial presentation is usually strongly helped by clear bullets 
that everyone can follow to keep straight what is being discussed.


yes, many of the briefings (here and elsewhere) are people reading their 
slides.  yes, Powerpoint seems to make this worse in the way the tool is 
designed.  But the issues seems to me not to e slides.


If I had to guess, it is a combination of folks lacking confidence to 
discuss their material, folks doing what they have seen, and the 
patterns the tools encourage.  There almost certainly are other factors.


If you could assume that all 10 people you were talking to were fully up 
to speed on the topic, and had not lost context to the other 10 WG 
sessions they have been preparing for, and if we knew how to hold 
conversations effectively in rooms with 50+ people, and ...


Yes, we should be looking for encouraging, and thanking / rewarding, 
those people who use their slots to briefly present and then engage in 
conversation with the WG.


But lets not invent a fictional past in which this was some how natural, 
or even the norm.


Yours,
Joel

On 2/11/2013 11:34 PM, Keith Moore wrote:

On 02/11/2013 10:46 PM, Bob Hinden wrote:

Keith,

On Feb 11, 2013, at 5:17 PM, Keith Moore wrote:


On 02/05/2013 11:04 AM, IETF Chair wrote:

3.4. Slide Sharing

Slides are often sent by email in advance of the meeting.
WebEx allows the slides and desktop applications to be
viewed by the
remote participants.  These are controlled by the presenter.  The
presenter can be shifted from participant to participant as needed.


Can we *please* discourage the habit of treating IETF WG meetings as
one series of PowerPoint presentations after another?   This makes
the meetings much less productive.

The notion that there are supposed to be slides for each
presentation, is IMO, a huge error.

I disagree.  The slides are a great help for non-native english speakers.


Let me back up a bit, because I don't think I stated my case strongly
enough.

WG meetings should not, in general, be used for presentations.  They
should primarily be used for discussions.   Presentations are largely a
waste of precious WG time.

It is sometimes possible to prepare slides to help facilitate
discussions.  But more often than not, the exercise of preparing slides
encourages the speaker to fill up most or all of the available time with
presentation material, leaving insufficient time for discussion of
important questions.

I certainly agree that when presentations are made, the slides can be
helpful to those who aren't so fluent in English.   My point is that
presentations should be made only rarely.

Keith

Re: Appointment of a Transport Area Director

[Joel M. Halpern]

Gaving discussed TCP Congestion behavior with the TCP folks, and tried 
to understand the issues, it seems to be very hard.


And if the AD is not well-versed in it, there is a serious issue.  It 
seems to me that unless we restructure the entire way the IESG operates 
(maybe a good idea, but a VERY different question) the AD needs to have 
significant understanding of the technical questions of his area.


Otherwise, the AD gets a directorate review calling out congestion 
problems.  He puts in the discuss.  And can not discuss it with the 
other ADs.  It is not his discuss.  He can not work out how to resolve it.


Directorates are critical.  I would hope tat all areas can move to a 
situation where finding the issues rests primarily with the 
directorates.  But the AD has to have enough details in his area to deal 
with it.


Yours,
Joel

On 3/3/2013 11:32 AM, Mary Barnes wrote:

Lars,

Do you not have individuals in the directorate that are experts on
congestion control (that aren't document authors) that can review for
technical sanity of the proposal?  ISTM that some of the TSV nominees
have broad technical skills, including management that could be quite
useful.  Certainly, we have an example where a Nomcom appointed
someone with little expertise for a specific area and the result was
not good. However, I believe that was far more to do with how the
individual approached the role - authoritarian versus understanding
that from a technical perspective they should really listen to the
experts.  IMHO, that's the most important skill that some ADs lack -
i.e., listening.

In my experience at not all ADs carefully scrutinize WG items and they
tend to rely on the write-up of the shepherd.  While the shepherd is
most often the WG chair, if they do their job properly, I believe that
the problems that an AD might encounter are fewer.   I will note that
from what I have seen not all shepherds actually review the documents
themselves, which is a problem unto itself. There is often quite
visible when one does gen-art reviews.   ISTM, there is a way for the
process to work with an AD that is not the technical expert in
specific areas IF others down the chain do their jobs properly.  Of
course, IETF is really bad at managing down the chain when there are
weak links. IMHO, someone with decent project management and people
management skills can make a huge difference.

Regards,
Mary.


On Sun, Mar 3, 2013 at 9:55 AM, Eggert, Lars  wrote:

Hi,

On Mar 3, 2013, at 15:35, Brian E Carpenter  wrote:

What I'm getting at is that this line of argument doesn't scale.
The only solution I see is to replace it by
"Several people on the Y Directorate need to understand X."


only if the Y directorate reviews all IDs going through the IESG. Which in 
itself is a scaling issue. It may work for some topics, but things will fall 
through the cracks for various reasons.

IMO congestion control is important and fundamental enough that the IESG itself 
needs to have the knowledge. YEs, I'm biased.

Lars

Re: Nomcom is responsible for IESG qualifications

[Joel M. Halpern]

I read 3777 as somewhere in between, with some important caveats.
As I understand the rules and practice of the game we are playing:

The IESG (and the IAB and IAOC) specify what they want to see (their job 
requirements).
The nomcom collects those, and community input.  Community input is 
explicitly asked for both on candidates, positions, and general 
operational behaviors.  This includes community feedback on the job that 
needs to be done.

The nomcom selects candidates.
The nomcom tells the confirming body who the candidates are, what the 
nomcom felt the requirements were and why, and how the candidate meets 
the requirements.

the confirming body reaches its conclusion, and responds.

Do note that while the nomcom is free to interpret the job requirements, 
they are NOT free to redefine the job.  If asked for a Security AD, they 
can not appoint an extra applications AD.  Even i the community input 
strongly led them to conclude that is what is needed.


One of the interesting things is that the nomcom does not in practice 
have a way to tell the community exactly what it decided the job 
requirements are.  I say this because the explanation of how the 
requirements were interpreted is often tied in with the available and 
selected candidates and their qualifications, which must not be 
discussed with the community.  And the confirming body can not tell the 
community what it did with the nomcom statements.


Yours, through my narrow lenses,
Joel

On 3/7/2013 4:28 PM, Andrew Sullivan wrote:

On Thu, Mar 07, 2013 at 01:02:09PM -0800, Dave Crocker wrote:

in the interpretation across different Nomcoms.  Since this is a
strategic issue, it's too important to leave that ambiguous, IMO.


Why?  It seems to me that merely having drawn attention to these bits
of RFC 3777 provides a hint to future nomcoms that they may not be so
bound as they think.  Why isn't that enough?  I suppose it may be too
late for this year, but this fact will surely be remembered by some
eligible volunteers next year, and they can use the apparent power
they already have to modify the stance the Nomcom takes.  No?

The alternative seems, to me, to be yet another IETF meta-discussion.
These seem inevitably to be giant time-holes into which we throw our
most engaged participants, and in this case we'd be doing it where the
RFC and the existing practice don't align well.  Why not just realign
to what the text says?

Best,

A

Fwd: Re: [IAB] WCIT slides

[Joel M. Halpern]

With apologies for the problems making these slides available, and 
thanks to Bernard for finding a work-around, for now the slides are 
available via links from

http://www.iab.org/2013/03/14/wcit-what-happened-whats-next/

Yours,
Joel M. Halpern

 Original Message 
Subject:Re: [IAB] WCIT slides
Date:   Fri, 15 Mar 2013 13:40:04 +
From:   Bernard Aboba 


I have created a blog entry on the IAB website that points to
the slides, agenda and session recording:
http://www.iab.org/2013/03/14/wcit-what-happened-whats-next/

[Gen-art] Review: draft-ietf-ipfix-flow-selection-tech-14.txt

[Joel M. Halpern]

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-ipfix-flow-selection-tech-14.txt
Flow Selection Techniques
Reviewer: Joel M. Halpern
Review Date: 21-March-2013
IETF LC End Date: 1-April-2013
IESG Telechat date: N/A

Summary: This document is ready for publication as a proposed standard.

Major issues: none (the previous major issue has been resolved by 
revision.  Thank you.)


Minor issues:
The tracker does not indicate a document shepherd for this document.

	If compliance is a big issue, then this document seems under-specified. 
For example, it says in section 5.1 "In order to be compliant with this 
document, at least the Property Match Filtering MUST be implemented." 
However, Property Match Filtering as defined in section 5.1.1 is a range 
of behaviors, so it is unclear which property tests must be supported 
(any, all possible?) in order to be compliant.



Nits/editorial comments: None

Re: Less Corporate Diversity

[Joel M. Halpern]

I would have to disagree with:

On 3/22/2013 11:17 PM, Mark Prior wrote:
...


Hi John,

I think that any small shop (whatever that means) would be put off if
they sent someone to an IETF as it appears that it is dominated by the
big vendors pushing their own agendas. Given that impression I imagine
the small shop has better things to do with its resources.

Mark.




While I work for a very large shop now, for most of my career I have 
worked for small or mid-size shops.  Even startups.  And all saw value 
in sending me to IETF meetings.


Yours,
Joel

Re: On the tradition of I-D "Acknowledgements" sections

[Joel M. Halpern]

I think I at least partly disagree.  The acknowledgements section of 
RFCs was not, and to the best of my knowledge is not, concerned with 
capturing the history of where specific changes or ideas came from.  It 
ought to be concerned with giving credit to folks who made particularly 
large, but not authorship level, contributions to the document.


I have seen I-Ds which included change logs which made an effort to 
capture the major changes to a document and their cause.  these were, at 
best, ungainly.  And are, as far as I know, always removed before 
publicaiton as an RFC.


Yours,
Joel

On 3/24/2013 8:55 PM, Abdussalam Baryun wrote:

  Just to make things clear that the intention of documents
acknowledging is to reflect the truth of any document process and
connect information or resources. IMHO, it is not the purpose to show
credit to any person including authors, it is to show how changes were
developed and show true document-history.

  So when I read a RFC I may go through the document process and its
draft versions, while going through the drafts related I see
acknowledged names so I may find the input on the list for such name.
In this way we have connections between inputs otherwise the IETF
system has no connection between its important information.

AB

Re: It's a personal statement (Re: On the tradition of I-D "Acknowledgements" sections)

[Joel M. Halpern]

It seems to me that you are setting up by assertion a standard that has 
never applied to this community.


Having said that, if we want to go down this path, then we could do what 
groups like IEEE do.  Remove all authors names, all personal 
acknowledgements, etc.  The work is simply the product of the committee. 
 I would prefer not to go down that path.  But if the alternative is 
copying every name from every person reported to have commented on the 
draft in the minutes or shown in the archive to have sent an email about 
the draft into a meaningless acknowledgements section, then the pure 
committee view would seem more sensible.


Yours,
Joel

On 3/25/2013 8:36 AM, Abdussalam Baryun wrote:

Hi Carsten,

  In general, I agree we don't force authors/owners of documents, as
tradition in the world and in all reasonable organisation, we never
force any author to be thankful. But don't forget the situation in
IETF is different and the documents are different as well.

  The document is a IETF document (not individual) and the authors are
not the only owners of the I-D as in other documents outside IETF (we
name them editors because IETF works/documents are shared for its
better publication not the authors' publication). The documents were
called for volunteers in IETF to participate and review, why the IETF
request that if it does not include them.

  In any I-D it is a personal statement for the IETF not the authors,
this is my beleive, otherwise why I should participate/volunteer if i
am not dealing with IETF business (don't want to participate in
private or public companies business),

AB

On 3/25/13, Carsten Bormann  wrote:

Further, the IETF should acknowledge that the contents of Acknowledgments
sections varies widely between RFCs. Some are fairly complete, some are
fairly vague and incomplete, and some are between.


Bingo.  It is up to the sole discretion of the document authors what they
want to list in the Acknowledgements section.

Trying to force people to thank other people strikes me as completely
misguided.

(That said, as a contributor, I have certain expectations of document
authors here, but these are *not* actionable in any sense.)  As an author, I
sometimes have forgotten to include people who made contributions worth a
mention, and I would have been spared the shame if the contributor would
have alerted me to that at the right occasion.  As a contributor, I have
never felt the need to pressure an author to include me, though.

It does make sense to relay some common sense of what is expected in an
Acknowledgements section to new authors.
I don't know we do this at the moment.


If you feel like you should be listed in the Acknowledgements section of a
WG document due to your contribution, and you're not listed in WG Last
Call, ask the WG to be included. 'Nuff said.


I'd modify this to "ask the authors".
Ask, as in "shouldn't the Acknowledgement section be updated", not demand as
in "I have an **g right to be in there".

The contents of the Acknowledgment section is about as much subject to WG
consensus as the authors' street addresses.

Grüße, Carsten

Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06

[Joel M. Halpern]

Would it suffice to replace
Old:
   If the bridging topologies which connects the switches changes, or
   if LACP [IEEE802.3ad] changes which links are used to deliver
   traffic, the switch may need to move the SAVI state to a different
   port, are the state may need to be moved or reestablished on a
   different switch.
New:
   If the bridging topologies which connects the switches changes, or
   if LACP [IEEE802.3ad], VRRP, or other link management
   operations, change which links are used to deliver
   traffic, the switch may need to move the SAVI state to a different
   port, are the state may need to be moved or reestablished on a
   different switch.
?

Proposed changes on the second - fourth lines above.
Yours,
Joel

On 3/26/2013 7:45 PM, Black, David wrote:

Ted,


Remembering that this is an informational draft, which does a pretty good job
of informing the reader about the problem space, is it your opinion that the
issues you have raised _must_ be addressed before the document is published,
or do you think the document is still valuable even if no further text is
added to address your concern?


At a minimum, in section 4.1.2, this should be addressed:

b) the new text implies that LACP is the only way to cause this situation - it's
not, so LACP should be used as an example.

I'm not sure I've seen Fred's response, but that change would suffice.  An RFC
Editor note should suffice.

Thanks,
--David


-Original Message-
From: Ted Lemon [mailto:ted.le...@nominum.com]
Sent: Monday, March 25, 2013 9:38 PM
To: Black, David
Cc: McPherson, Danny; Fred Baker; joel.halp...@ericsson.com; gen-...@ietf.org;
Jean-Michel Combes; s...@ietf.org; ietf@ietf.org
Subject: Re: Gen-ART review of draft-ietf-savi-threat-scope-06

On Mar 25, 2013, at 9:04 PM, "Black, David"  wrote:

Summary: This draft is on the right track, but has open issues, described in

the review.

While I identified the same issue you did with switching systems that do link
aggregation and other magic, I think that the document is useful whether this
is fixed or not.  It's true that it doesn't have a full section that talks
specifically about this problem, but I think it's unlikely that the authors
are going to add one-when I mentioned it to Joel, he didn't express excitement
at the prospect.

I think Fred's response, while a little salty, accurately represents the
situation: the working group produced this document, the document does what
it's supposed to do, one could continue to polish it indefinitely, but then
the document would never get published.

Remembering that this is an informational draft, which does a pretty good job
of informing the reader about the problem space, is it your opinion that the
issues you have raised _must_ be addressed before the document is published,
or do you think the document is still valuable even if no further text is
added to address your concern?



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

Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06

[Joel M. Halpern]

I have a draft version with this correction.
David, would adding:
  When such a move
  is done without changing the MAC address, the SAVI switches
  will need to update their state.  While the ARP may be
  helpful,
  traffic detection, switch based neighbor solicitation,
  interaction with orchestration system, or other means may be
  used.
to the end of 5.2.3 address your concern?  I am not sure whether I have 
the right end of the question here, given that SAVI can not create new 
protocol.


Yours,
Joel

On 3/27/2013 10:56 PM, Ted Lemon wrote:

On Mar 27, 2013, at 12:45 PM, Joel Halpern Direct  
wrote:


Then it will be done.  I will wait for the AD to decide what other changes are 
needed, and then will either make this change or include it in an RFC Editor 
note.



Old:
   If the bridging topologies which connects the switches changes, or
   if LACP [IEEE802.3ad] changes which links are used to deliver
   traffic, the switch may need to move the SAVI state to a different
   port, are the state may need to be moved or reestablished on a
   different switch.
New:
   If the bridging topologies which connects the switches changes, or
   if LACP [IEEE802.3ad], VRRP, or other link management
   operations, change which links are used to deliver
   traffic, the switch may need to move the SAVI state to a different
   port, are the state may need to be moved or reestablished on a
   different switch.


I think you probably meant "or", not "are", in the second word of the 
second-to-last line of the new text.

As far as I am concerned, given that David is happy with your recent change, 
I'm happy with it too.   However, since you are asking, if you were willing to 
also accommodate David's other request (see below) by adding some text to the 
document in section 5, that would be an added bonus:


A paragraph has been added to 5.2.3 to address all three of the above concerns. 
  I guess that's ok, but I would have liked to see some text pointing out that 
a MAC move can be detected by the switches and used to update SAVI state about 
which port(s) a MAC is accessed through.


So if you can do this, it would be much appreciated; if you can't do it, I 
think the document is valuable enough to move forward without this additional 
work.

[Gen-art] Review: draft-ietf-netmod-rfc6021-bis-01

[Joel M. Halpern]

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-netmod-rfc6021-bis-01
Common YANG Data Types
Reviewer: Joel M. Halpern
Review Date: 19-April-2013
IETF LC End Date: 1-May-2013
IESG Telechat date: N/A

Summary: This document is nearly ready for publication as a Standards 
Track RFC


Major issues:
(The following may well be a non-issue.)
In the revision of the ietf-inet-types, the patterns for the new 
ip4-address-no-zone and ipv6-address-no-zone are drastically simplified 
from the ipv4-address and ipv6-address patterns.  The new 
ipv4-address-no-zone allows any sequence of decimal digits an periods, 
while the original was carefully defined as dotted quads of 0..255. 
Similarly, te ipv6-address-no-zone allows any arbitrary sequence of hex 
digits and colons.  The original patterns were very careful to match 
rules for validity.  Is there a reason for the change.


Minor issues:

Nits/editorial comments:

Re: [Gen-art] Review: draft-ietf-netmod-rfc6021-bis-01

[Joel M. Halpern]

I am guessing that the authors intended the addition of the text 
emphasizing that the no-zone typedefs are derived general typedef 
addresses the difference in the patterns.


Is there a YANG rule that says tat if typedef X is derived from typedef 
Y then the string for X must match the pattern for X and the pattern for 
Y?  If so, then my concern below is misplaced.  (The fact that I find 
the vague pattern for the child misleading is not a fault with the 
document, but rather in my head, under that requirement.)


Yours,
Joel

On 4/19/2013 6:24 PM, Joel M. Halpern wrote:

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-netmod-rfc6021-bis-01
 Common YANG Data Types
Reviewer: Joel M. Halpern
Review Date: 19-April-2013
IETF LC End Date: 1-May-2013
IESG Telechat date: N/A

Summary: This document is nearly ready for publication as a Standards
Track RFC

Major issues:
 (The following may well be a non-issue.)
 In the revision of the ietf-inet-types, the patterns for the new
ip4-address-no-zone and ipv6-address-no-zone are drastically simplified
from the ipv4-address and ipv6-address patterns.  The new
ipv4-address-no-zone allows any sequence of decimal digits an periods,
while the original was carefully defined as dotted quads of 0..255.
Similarly, te ipv6-address-no-zone allows any arbitrary sequence of hex
digits and colons.  The original patterns were very careful to match
rules for validity.  Is there a reason for the change.

Minor issues:

Nits/editorial comments:
___
Gen-art mailing list
gen-...@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-ietf-netmod-rfc6021-bis-01

[Joel M. Halpern]

Thank you Juergen.  I see that the pattern statement is therefore correct.
And presumably it is a judgment call as to hw to write te new pattern to 
restrict the old one.  Personally, I find a pattern statement that 
covers a whole lot of other things, but that happens when combined with 
the parent patter to give the right result, to be a confusing way to 
document what is needed.  But I can not claim it is technically 
incorrect.  (And I suppose that some would claim that repeating the more 
detailed parent pattern is redundant.)


Yours,
Joel

On 5/13/2013 6:37 AM, Juergen Schoenwaelder wrote:

Joel,

this is specified in the third paragraph of section 9.4.6 of RFC 6020:

9.4.6.  The pattern Statement

The "pattern" statement, which is an optional substatement to the
"type" statement, takes as an argument a regular expression string,
as defined in [XSD-TYPES].  It is used to restrict the built-in type
"string", or types derived from "string", to values that match the
pattern.

If the type has multiple "pattern" statements, the expressions are
ANDed together, i.e., all such expressions have to match.

If a pattern restriction is applied to an already pattern-restricted
type, values must match all patterns in the base type, in addition to
the new patterns.

/js

On Mon, May 13, 2013 at 12:33:37PM +0200, Benoit Claise wrote:

Forwarding to the authors and WG

Regards, Benoit

I am guessing that the authors intended the addition of the text
emphasizing that the no-zone typedefs are derived general typedef
addresses the difference in the patterns.

Is there a YANG rule that says tat if typedef X is derived from
typedef Y then the string for X must match the pattern for X and
the pattern for Y?  If so, then my concern below is misplaced.
(The fact that I find the vague pattern for the child misleading
is not a fault with the document, but rather in my head, under
that requirement.)

Yours,
Joel

On 4/19/2013 6:24 PM, Joel M. Halpern wrote:

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-netmod-rfc6021-bis-01
 Common YANG Data Types
Reviewer: Joel M. Halpern
Review Date: 19-April-2013
IETF LC End Date: 1-May-2013
IESG Telechat date: N/A

Summary: This document is nearly ready for publication as a Standards
Track RFC

Major issues:
 (The following may well be a non-issue.)
 In the revision of the ietf-inet-types, the patterns for the new
ip4-address-no-zone and ipv6-address-no-zone are drastically simplified

>from the ipv4-address and ipv6-address patterns.  The new

ipv4-address-no-zone allows any sequence of decimal digits an periods,
while the original was carefully defined as dotted quads of 0..255.
Similarly, te ipv6-address-no-zone allows any arbitrary sequence of hex
digits and colons.  The original patterns were very careful to match
rules for validity.  Is there a reason for the change.

Minor issues:

Nits/editorial comments:
___
Gen-art mailing list
gen-...@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: call for ideas: tail-heavy IETF process

[Joel M. Halpern]

It seems to me that if it is really a discussion, then there may be many 
possible things which could resolve it, and the AD raising the question 
may not know exactly what is feasible to clear it.  Otherwise it is a 
demand, not a discussions.  And in my experience while ADs can be pushy 
(like the rest of us), they are generally prepared to have discussion.


Thus, I find your second item below to be inappropriate.

At the same time, discussions do have to be resolvable.  If there is no 
way to address it, then it is not a discuss.  But "required to clar" is 
the wrong picture as far as I can tell.


Yours,
Joel

On 5/14/2013 5:12 PM, Joe Touch wrote:

I am *not* suggesting getting rid of it.

I *am* suggesting that it needs to be used only where necessary, and
that 'necessary' ought to be clearly proved by:

 - citing the specific DISCUSS criteria involved

 - providing explicit information on what would
 be required to clear the DISCUSS

Re: call for ideas: tail-heavy IETF process

[Joel M. Halpern]

Below:

On 5/14/2013 6:04 PM, Joe Touch wrote:



On 5/14/2013 3:00 PM, Joel M. Halpern wrote:

It seems to me that if it is really a discussion, then there may be many
possible things which could resolve it, and the AD raising the question
may not know exactly what is feasible to clear it.  Otherwise it is a
demand, not a discussions.  And in my experience while ADs can be pushy
(like the rest of us), they are generally prepared to have discussion.

Thus, I find your second item below to be inappropriate.

At the same time, discussions do have to be resolvable.  If there is no
way to address it, then it is not a discuss.  But "required to clar" is
the wrong picture as far as I can tell.


Point taken - at least some indication on what is expected to be changed
toward a path of resolution.

As you note, otherwise it's not a DISCUSS.

Joe
Thanks Joe.  I am glad we are on the same apage about the kind of 
clarity of description needed in discusses.  We may have different 
experiences, but the vast majority of the discusses I have dealt with 
have been sufficiently clear on the question of how to approach 
resolving them.  Sometimes an actual conversation with the AD has been 
necessary to understand the issue and reach a practical point for 
resolving it, but that is a communication style issue, not a discuss 
substance issue.


Yours,
Joel





Yours,
Joel

On 5/14/2013 5:12 PM, Joe Touch wrote:

I am *not* suggesting getting rid of it.

I *am* suggesting that it needs to be used only where necessary, and
that 'necessary' ought to be clearly proved by:

 - citing the specific DISCUSS criteria involved

 - providing explicit information on what would
 be required to clear the DISCUSS

Re: call for ideas: tail-heavy IETF process

[Joel M. Halpern]

And your bottom line is exactly what te rules say, what I said, what Ted 
said, and what Joe agreed is reasonable.  It also matchesthe practice I 
have seen.  Even the discuss that I had a lot of arguments with did 
include proposals for paths forward.  Sometimes they were ard to 
understand.  That's probably inevitable with all these opinionated 
humans doing this.


Yours,
Joel

On 5/14/2013 7:15 PM, Dave Crocker wrote:

On 5/14/2013 3:46 PM, Andrew Sullivan wrote:


To be fair, for what it's worth as a WG chair I've had the latter
experience at least as often as the former in the use of DISCUSS, and
I've observed some DISCUSSes cleared without any change at all to the
document in question.


We suffer a continuing logic error in the IETF.  We use "sometimes it
happens the other way" as if that negates the existence and problem
cause by what is being criticized.

So, yeah, of course a Discuss /sometimes/ causes a small delay with no
changes.  /Sometimes/ ADs use the sledgehammer of the Discuss to ask for
a bit of conversation.  That's all irrelevant.

What's relevant is the nature of the mechanisms, its capability, and the
cost it can and does impose on authors and the working group.

When a serious defect is identified, it's entirely worth the cost.

When it isn't, it isn't.

In all cases, the person imposing the cost has an obligation to
facilitate closing it, including making clear the criteria for closing
it.  It is unreasonable to have those who must do the work to clear it
play a guessing game.

[Gen-art] review: draft-ietf-cuss-sip-uui-10

[Joel M. Halpern]

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-cuss-sip-uui-10
A Mechanism for Transporting User to User
Call Control Information in SIP
Reviewer: Joel M. Halpern
Review Date: 19-May-2013
IETF LC End Date: 29-May-2013
IESG Telechat date: N/A

Summary: This document is nearly ready for publication as a Proposed 
Standard


Major issues:

Minor issues:
The requirements discussions for redirection and referral (second 
paragraph of section 3, in regards REQ-3) includes what appears to be 
normative requirements on redirecting devices.

a) This would seem to belong in section 4 on Normative Definition.
b) It would seem that there ought to be some discussion of what happens 
with redirecting devices that do not understand this new UUI. (I presume 
things work, but I don't see how.)


Nits/editorial comments:
In section 8.2, given that this is a WG document, should the "the 
authors believe" actually be "the WG believes"?  Or even, given IETF 
rough consensus on this document, "the IETF believes"?

Re: When to adopt a WG I-D

[Joel M. Halpern]

In reading through the draft, particularly the section on questions for 
WG adoption of a draft, I did not see the questions I consider most 
pertinent:
Does the WG think this is a reasonable (preferably good) basis for 
starting to work collectively on the deliverable?


(Apologies if it was there and I missed it.)

Another question many WGs have found useful is:
Are there enough people interested and willing to write and / or review 
the document?

This is not the same as WG support for the document.

Yours,
Joel

PS: The chairs opinion on the technical content of the document ought to 
be irrelevant as far as I can tell.  On the other hand, detecting and 
raising concerns if the document is badly written is probably part of 
the chair's job.


On 5/28/2013 5:32 AM, Adrian Farrel wrote:

Hi,

Dave Crocker and I have this little draft [1] discussing the process
and considerations for creating formal working group drafts that are
targeted for publication.

We believe that this may help clarify some of the issues and concerns
associated with this part of the process. We are targeting this as
Informational (i.e. commentary on existing process, not new normative
definition of process) and would like your input.

What is not clear? What have we got wrong? How should we resolve the
remaining editor notes?

Thanks, Adrian (per pro Dave)

[1]
http://www.ietf.org/internet-drafts/draft-crocker-id-adoption-02.txt

Re: Registration for IETF 87 in Berlin has re-opened

[Joel M. Halpern]

Thank you, and ISOC.  Well done.
Joel

On 7/5/2013 11:57 AM, The IAOC wrote:

Registration was suspended after discussions with tax specialists and attorneys 
convinced
us that that the rules had changed in the EU and Germany with regard to the 
impact of the
Value Added Tax (VAT) on registration fees.

There is an EU requirement to impose the country's Value Added Tax to 
registration fees
where the meeting is held.  Accordingly, Germany's 19% VAT has to be collected 
and paid
over to the German tax authorities.

The IAOC had to decide whether to change the registration fee to add the tax to 
it, or
whether to keep the fee in place for the meeting and state that the VAT was 
included in
the fee, which action would result in a registration revenue shortfall greater 
than
$100,000 USD. After discussions with the Internet Society the IAOC has decided 
not to change
the total registration fee for IETF87 because of the complexity of dealing with 
those who
have already paid, and those who had budgeted assuming a total fee of $650.  
ISOC has agreed
to cover any resulting yearly budget shortfall resulting from including the VAT 
in the IETF87
registration fee.  We thank the Internet Society for this support.

You will notice a change in your final receipt for the meeting,  It will 
include VAT information
and a VAT identification number.  It is expected that final receipts will 
become available in the
next two weeks.  You or your employer may qualify to recover the VAT.  We will 
be providing
guidance on this matter in the next two weeks.

We and the Internet Society have learned that VAT is a very complex matter and 
that expertise
is required on a going forward basis.  To that end the Internet Society is 
considering proposals
to retain a European tax specialist firm to assist us and them in the future.  
We will be
investigating similar issues in other regions.

This decision to not change the fee is for this meeting only. The 2014 Budget 
will take the VAT
into consideration when the fees are set for meetings in Europe next year and 
beyond.

We look forward to seeing you in Berlin.

Bob Hinden
IAOC Chair

Re: Radical Solution for remote participants

[Joel M. Halpern]

Maybe I am missing something.
The reason we have face-to-face meetings is because there is value in 
such meetings that can not reasonably be achieved in other ways.
I would like remote participation to be as good as possible.  But if 
would could achieve "the same as being there" then we should seriously 
consider not meeting face-to-face.
Conversely, until the technology gets that good, we must not penalize 
the face-to-face meeting for failures of the technology.


Yours,
Joel

On 8/15/13 9:48 PM, Mark Nottingham wrote:


On 13/08/2013, at 11:00 AM, Douglas Otis  wrote:


1) Ensure exact digital interfaces driving projectors are fully available 
remotely.


That would be fantastic, if feasible. Much simpler than sharing through 
software.



2) Ensure Audio access requires an identified request via XMPP prior to 
enabling either a remote or local audio feed.


Hm.



3) RFI tags could facilitate enabling local audio feed instead of an identified 
request via XMPP.


Could be quite interesting; many conferences now provide attendees with RFID 
tags...



4) In the event of the local venue loosing Internet access, the device 
regulating A/V presentations must be able to operate in a virtual mode where 
only remote participants are permitted to continue the meeting proceedings.


That seems… extreme.


5) Important participants should plan for alternative modes of Internet access 
to remain part of the proceedings.


Not exactly practical.



6) Develop a simple syntax used on XMPP sessions to:
1) signify a request to speak on X
2) withdraw a request to speak on X
3) signify support of Y
4) signify non-support of Y
5) signal when a request has been granted or revoked.  For local participants 
this could be in the form of a red or green light at their microphone.


The W3C does much of this already with IRC bots, e.g.:
   http://www.w3.org/2001/12/zakim-irc-bot.html

(also can pick a scribe, track an agenda, etc.)



7) Develop a control panel managed by chairs or their proxies that consolidate 
and sequence requests and log support and nonsupport indications and the 
granting of requests.


See above (I think).



8) Chairs should be able to act as proxies for local participants lacking 
access to XMPP.


Not practical, unless they delegate.



9) Chairs should have alternative Internet access independent of that of the 
venue's.


Seems extreme.



10) Establish a reasonable fee to facilitate remote participants who receive 
credit for their participation equal to that of being local.

11) The device regulating A/V presentations must drive both the video and audio 
portions of the presentations.  A web camera in a room is a very poor 
replacement.

12) All video information in the form of slides and text must be available from 
the Internet prior to the beginning of the meeting.


Cheers,


--
Mark Nottingham   http://www.mnot.net/

Re: Protocol Definition

[Joel M. Halpern]

I suspect that the "correct" choices depends upon how you look at the 
analogy.
What seemed to me the closest analog to "process" would be the actual 
messages on the wires.


yours,
Joel

On 1/5/2012 10:03 PM, Dave CROCKER wrote:



On 1/5/2012 1:41 PM, Dave Cridland wrote:

Association, to my mind, means a transport layer connection, hence
it's usage in
SNMP and other OSI-related things.

Session isn't much less damaged, as a term, I admit, but it is in
common usage.
And like algorithms, and protocols, you can open up a session to find
other
sessions inside.



Actually, my recollection is that 'association' was an application-level
construct from OSI.

But I came to the same conclusion as you: "session" is an established
term in IETF parlance and has the basic reality of describing a protocol
in operation between two (or more?) hosts/endsystems/endpoints/...

Does this resonate with others?

d/

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

Re: Another last call for draft-weil

[Joel M. Halpern]

I agree.  This needs to be published by the IETF as an RFC. the current 
form is quite suitable for that.


Yours,
Joel

On 2/14/2012 1:28 PM, Scott O Bradner wrote:

+1

On Feb 14, 2012, at 1:25 PM, Ross Callon wrote:


+1.
Ross
*From:*ietf-boun...@ietf.org
[mailto:ietf-boun...@ietf.org]*On Behalf
Of*Owen DeLong
*Sent:*Monday, February 13, 2012 2:06 PM
*To:*ietf@ietf.org 
*Cc:*draft-bdgks-arin-shared-transition-space@tools. org
*Subject:*Re: Another last call for draft-weil
I support draft-weil as revised. There is a vital need for this to
move forward and the IETF should stop standing in the way and let ARIN
allocate the space already.
Owen
On Feb 13, 2012, at 10:09 AM, Chris Grundemann wrote:


Fellow BDGKS Authors,
FYI: draft-weil is in another Last Call following an update that was
requested by IESG Ads (on their December telechat, some ADs asked us
to turn our request into a request for more 1918 space, but with a few
caveats to home router manufacturers about not breaking when exposed
to a CGN environment.). At this point we don't expect to change any
minds. Basically everyone who is against the draft has spoken up. Now
it is just a numbers game, we need to demonstrate significant support
for the draft.
If you do support this I-D and the allocation of the /10 for shared
CGN use, please consider posting a statement of support. Something as
simple as "I support this draft as updated" or "I think the updated
draft is more flexible, and would satisfy additional use cases that
don't work with RFC1918 space" would be very helpful.
You can respond to the "Last Call:
 (IANA Reserved
IPv4 Prefix for Shared Address Space) to BCP" thread or post
individually to ietf@ietf.org . Also, please
feel free to encourage anyone else you know who supports the draft to
make a similar post. Every statement we can gather is vital right now.
Last call ends on Thursday, so reply's must be made before then. Thank
you.
Cheers,
~Chris
___
Ietf mailing list
Ietf@ietf.org 
https://www.ietf.org/mailman/listinfo/ietf




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

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

Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp)

[Joel M. Halpern]

If I may separate issues for a moment,
the absence of milestones is because Terry and I have to come up with a 
proposal for them which matche sthe revised goals.


If you read the rest of the differences, you will see that the general 
question of what LISP is aimed at providing is indeed still there.


The largest single difference is the addition of the architecture draft, 
which the IESG considers a gating item for any of the longer term work 
(such as the security solutions or the additional mapping system.


Some of the apparent removal is because, as Jari stated, the IESG has 
requested that the working group focus on fewer deliverables.


Yours,
Joel

On 2/16/2012 12:00 PM, John Scudder wrote:

Hi Thomas,

On Feb 15, 2012, at 4:31 PM, Thomas Narten wrote:


A WG Review message for this WG already went out a month ago.

What has changed to necessitate another Last Call?

Could the-powers-that-be please make it easier for those who might
care to understand if there is something here that we should know and
possibly comment about?

A simple explanation, or a pointer to diffs, etc. would do the job
nicely.


Good question! I did go back and diff the last couple of versions and though 
this isn't the exhaustive diff, these are the key changes that caught my eye:

This text was lost from the previous draft charter:

This analysis will explain what
role LISP can play in scalable routing. The analysis should also look at
scalability and levels of state required for encapsulation,
decapsulation, liveness, and so on as well as the manageability and
operability of LISP. Specifically, the group will work on:

- documenting areas that need experimentation
- summarizing the results of implementation, experiments, and deployment
   experience
- describing the implications of employing LISP
- operational guidance for using LISP

And so were these Goals and Milestones:

Jun 2012Forward to the IESG an operational document which should
include cache management and ETR synchronization
techniques (draft-ietf-lisp-deployment).

Dec 2013Publish an example cache management specification.

Jun 2014Summarize results of specifying, implementing, and testing
LISP and forward to IESG and/or IRTF.

Jun 2014Analyze and document the implications of LISP deployments in
Internet topologies and forward to IESG for publication.

I'm not sure why these were removed, and I would like to see them reinstated or 
at least have a discussion about their removal.

Thanks,

--John

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

Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp)

[Joel M. Halpern]

Actually John, I would have to disagree with your assertion about what 
it takes to describe the archtiecture.
It may take engineering and evaluating some cache management schemes 
before one can decide whether the archtiecture is a good one.  But that 
is very different from being able to describe the archteicture so that 
one can understand the system level behavior.


Yours,
Joel

On 3/13/2012 2:37 PM, John Scudder wrote:

Barry and all,

On Mar 8, 2012, at 4:34 PM, Barry Leiba wrote:
...

But it's not clear to me that these (especially architecture and impacts) can
be said to have been properly analyzed until some of the lower-priority items
(I'm thinking of threats, cache, ETR sync) have been fleshed out.


I hear what you are saying. But I think the opinion in the IESG at least
was, however, that those three really are high priority, and that other
documents before them are not so useful before they are completed. I guess
it is a different perspective, whether you do things top-down or bottom-up.
I do agree with both points of view, actually.


The dependencies (threats, cache, ETR sync, and whatever else) can
certainly be discussed to the extent needed to lay out the
architecture and other priority documents, with notes taken and saved
for when other documents need to be produced.  That still says that
the working group needs to focus on discussion that leads to the
completion of the three priority documents first, before tackling the
others.  Everyone understands that these priority items can't be
developed in a vacuum; we just don't want things to wander off into
lower-level details such as protocol elements and text that can wait
for the next phase.


You don't want to boil the ocean; that's fine. My point is that without covering (at 
least) cache management and ETR synchronization, the architecture will not be done. Think 
about the old joke about the mathematical proof that includes "... then a miracle 
occurs" as one of its steps (http://star.psy.ohio-state.edu/coglab/Miracle.html). 
Similarly, threats and the impacts document.

One way to handle this (other than what I've already suggested) might be to 
explicitly note that the respective documents should cover these topics. For 
example (edits set off by [[ ]]):

- Architecture description: This document will describe the
   architecture of the entire LISP system, making it easier to read the
   rest of the LISP specifications and providing a basis for discussion
   about the details of the LISP protocols. [[The document will
   cover relevant issues including though not limited to cache
   management and ETR synchronization.]]

and

- A description of the impacts of LISP: This document will describe
   the problems that LISP is intended to address and the impacts that
   employing LISP has. While the work on LISP was initiated by Internet
   routing scaling concerns, there has also been an interest on
   improved solutions to a number of different problems, such as
   traffic engineering. This document should describe problem areas
   (such as scaling or traffic engineer) where LISP is expected to have
   a positive effect, as well as any tradeoffs that are caused by
   LISP's design. [[The document will discuss potential security-
   related impacts, whether positive or negative.]]

Regards,

--John
___
lisp mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lisp


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

Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp)

[Joel M. Halpern]

Relevant?  Yes.
Gating?  No.

In fact, I would put it the other way around.
The architecture documentis very useful, almost necessary, for deciding 
whether the solution is a good one.
The cache management evaluations are another component of such an 
evaluation.
Even understanding the cache management quesiton is made significantly 
easier by having a clean architecture description.


Yours,
Joel

On 3/14/2012 10:40 AM, John Scudder wrote:

One further remark:

On Mar 13, 2012, at 3:04 PM, Joel M. Halpern wrote:
...

It may take engineering and evaluating some cache management schemes
before one can decide whether the archtiecture is a good one.

...

Agreed.

Isn't it relevant to the architecture document, that it be possible for a 
reader to judge whether the architecture is a good one or not?

--John

Re: [lisp] Last Call: (LISP EID Block) to Informational RFC

[Joel M. Halpern]

Whatever else is going on, LISP EIDs do not have geographic 
significance.  They do not have IP Routing topological significance. 
The are not aggregateable.


They are intended to beused by a site as a single prefix.  Hence, the 
desired behavior (within the /16) is exactly the same as that needed to 
respond to a PI request.


Yours,
Joel

On 11/15/2012 5:24 PM, George Michaelson wrote:


Dino, to come back on topic. I understand the drafts purpose is to request a 
block of IPv6 address be delegated for this specific purpose, from IANA. The 
request is to the IAB. So, its a request for architectural aspects of 
addressing, facing an experiment.

a /12 is a very large amount of space. This demands rigour in the process to apply, even 
a reservation requires a sense of why, and justification. "we think its about 
right" isn't appropriate and the document needs more work to specify why a 16, and 
why a /12, and what the implications are of eg a smaller allocation under a /16 
reservation, or some other size (a /32 even, for which there are both precedents, in 
experimental allocations, and an existing process inside the RIR address management 
framework).

Secondly, you appear to assume these allocations to EID can simply use current 
RIR practices. The problem is that you need to understand what needs-based and 
justification means in process terms: Hostmasters in the RIR system try very 
hard not to be placed in a position of making arbitrary subjective decisions: 
they have processes which are designed to ask for objective justifications to 
specify why an allocation should take place, and at what scale. Those objective 
criteria face addresses as addresses. not EID.

For an example: IPv6 address allocation process currently is implemented using 
sparse allocation (binary chop with some modifications) in the APNIC region. 
This maximises space around allocations to equalise the distribution of free 
blocks such that the commons, the unallocated space, remains as usefully large 
as possible and when the next binary stride is entered, there is some 
understanding its going to be applied in common to all occupants of that region 
of space (in terms of the size of hole around them, which is not a reservation 
per se, but provides for risk-management of future growth to the largest 
extent).

We're really quite proud of sparse: its extended the life of the /12 we occupy 
quite markedly. What impact will EID have on this? Is sparse an appropriate 
allocation engine to use for EID? What if eg you have expectations of 
almost-geographic aspects of address management in EID. Doesn't that require 
documentation as a process? And, you may be specifying a cost on the RIR 
system, to engineer support for the new allocation logic. If it doesn't 
logically fit in sparse allocation, we need to know. And we need to know why.

EID are not going to be used like 'normal' addresses. So, the normal justifications don't 
look entirely appropriate to me from 10,000ft. The document needs to say "maybe we 
need to understand the allocation processes that the RIR should objectively apply" 
or maybe you need to step outside of draft space and engage inside the RIR policy process 
and seek a global policy which can document the process.

To ask for an IANA allocation without having undertaken this process looks 
wrong to me. So, I stand by my concern the document isn't ready for IETF last 
call: it hasn't addressed substantive issues around the process and 
expectations of address/registry function, to manage the /16, and it hasn't 
documented the basis of asking for a /16 in the first place, or a /12 
reservation.

cheers

-George
___
lisp mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Last Call: (LISP EID Block) to Informational RFC

[Joel M. Halpern]

It is a fair question to ask whether the allocation strategy and polices 
need to be spelled out at the time of the reservation.  Possibly we made 
the wrong call on keeping them separate.  Part of the issue is that fo 
current experimentation having the block is more important, but for 
longer term experiments, and for implications on other parties, the 
allocation policies matter more.


With regard to interworking and deployment, there are a number of 
documents that deal with that.  They discuss what the currently 
understood deployment incentives are, and what paths are currently seen. 
  (As Noel noted, this is an experiment, and one should expect that the 
actual path will be different from the expectation.)  Given that 
interworkng dives are data plane devices, altruism is clearly not a 
sufficient incentive to get this to scale, and the models do not depend 
upon that.


Yours,
Joel

On 11/16/2012 6:57 AM, Roger Jørgensen wrote:

On Tue, Nov 13, 2012 at 3:45 PM, The IESG  wrote:


The IESG has received a request from the Locator/ID Separation Protocol
WG (lisp) to consider the following document:
- 'LISP EID Block'
as Informational RFC

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 2012-11-27. 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.



I think LISP is an important factor in the future of Internet and I do
support the idea of having different IP block for LISP based network.

However, I can not support the publication of this document, it has
some unclear issues that need good answers first.



Anyhow, I see two issues that need to be addressed better

1.) How should the address space be administrated, RIR structure or
something else closer to 6bone? I support the suggested idea of
discussing this part with the different RIRs to look more into how
this are going to work in practice.
And as Dino said, "No, I am not making any assumptions either way. How
allocation gets done is subject to more work." the document should
state this.




2.) The interaction between none-LISP and LISP Internet. This problem
has two sub-problems within it

a.) Why is there a need for a special LISP block. This is partly
answered in section 3.  Rationale and Intent. Is this the entire
reason?


With the current specifications, if an ITR is sending to all types of
destinations (i.e., non-LISP destinations, LISP destinations not in
the IPv6 EID Block, and LISP destinations in the IPv6 EID Block) the
only way to understand whether or not to encapsulate the traffic is
to perform a cache lookup and, in case of cache-miss, send a Map-
Request to the mapping system.  In the meanwhile, packets can be
dropped.




b.) the routing integration between none-LISP and LISP internet, how
are that going to work?
The current document isn't clear enough on that as I see it. Are there
an assumption that some ISPs will announce the entire LISP space (/16
are mention) for free ?
If each and every EID space holder (/32 or similiar) each have to
connect to Internet and get their address space routed, then it's
nothing different than regular RIR allocated /32's.



Address these thing somehow in the document, even just mention that
it's subject for other document and I'm happy... :-)

Re: [lisp] Last Call: (LISP EID Block) to Informational RFC

[Joel M. Halpern]

Why does any operator have a reason to carr any routes other than their 
paying customers?  Because it provides connectivity for their customers.
If we get this block allocaed, then it results in 1 extra routing entry 
in the global routing table to support LISP inter-working.
An entry that some of their customers may use, whether the operator 
carrying it knows that or not.


In fact, it would take significant extra work for the operator to 
somehow block this aggregate.


If LISP fails, this is a small cost to find out.
If LISP succeeds, this results in significant reduction in core tabl 
sizes for everyone.


Yours,
Joel

On 11/16/2012 11:35 AM, Brian E Carpenter wrote:

Joel,

On 16/11/2012 16:00, Joel M. Halpern wrote:
...

With regard to interworking and deployment, there are a number of
documents that deal with that.  They discuss what the currently
understood deployment incentives are, and what paths are currently seen.
   (As Noel noted, this is an experiment, and one should expect that the
actual path will be different from the expectation.)  Given that
interworkng dives are data plane devices, altruism is clearly not a
sufficient incentive to get this to scale, and the models do not depend
upon that.


My concern with this allocation request was not about scaling
but about black holes. What are the incentives for operators not
very interested in LISP to carry the routes that make it work?
That's the root of many of the problems with 6to4 (and, I think,
many of the problems of the MBONE, for those with long memories).

Regards
 Brian

Re: PowerPoint considered harmful (was Re: Barely literate minutes)

[Joel M. Halpern]

There is another unfortunate community habit that I have noticed.
It is, I believe, a consequence o their being simply too much stuff to 
look at.


If you have a working group that is considering new ideas (looking to 
recharter), you are more likely to get folks to read the draft, either 
before or shortly after the meeting, if you get a presentation slot in 
the meeting.  In particular, if the presentation sounds interesting, he 
odds of readership go up.


This is not discussion.  The odds of getting much discussion if the idea 
is competent are pretty low.  (I am putting aside the useful result 
where the participants go to the mike and bash the idea hard.  That at 
least is discussion, even if not the discussion the presenter wanted.) 
But it seems to be one of the few ways we have to get folks to pay 
attention.


Yours,
Joel

On 12/2/2012 10:12 AM, Keith Moore wrote:

On 12/02/2012 10:03 AM, John C Klensin wrote:


--On Sunday, December 02, 2012 09:53 -0500 Keith Moore
 wrote:


...
(Another way to put is that even if we provide such cameras in
meetings along with colored pens and paper, we will continue
to see PowerPoint being used as it is today unless there's a
community-wide effort to change our entrenched habits.)

Sure.  But it is the now-entrenched habits that are the problem.
The overuse of PowerPoint for purposes of which neither of us
approve is merely a symptom, not, IMO, a cause (even if it
reinforces the behaviors).

Agreed, though sometimes when changing habits it helps to focus
attention on the most visible or tangible part of the habit.

It's always been possible, and will presumably remain possible, to build
small PowerPoint decks that consist of only a few diagrams, to leave
some blank slides in the middle of the deck for the purpose of typing in
comments made at meetings, etc.  -- all for the purpose of facilitating
discussion.  I wouldn't have a problem with PowerPoint being used in
that way, though I suspect that it will be difficult for people to
restrain themselves to using PowerPoint in that way as long as that's
the tool that they're using.


Anyone for incorporating a slide (!) into the Newcomer's
Presentation (!!) that says "a presentation in a f2f meeting
that makes extensive use of PowerPoint decks with many and/or
dense slides brands the presenter as either a newcomer, someone
who is trying to avoid an actual discussion, or a fool"?   :-(

Yes, but first we need to get existing WG chairs to say that to their
participants, and to push back on people who continue to do use
PowerPoint in that way in meetings.

Keith

Re: Idea for a process experiment to reward running code...

[Joel M. Halpern]

And I will strongly oppose any IETF policy that treats commercial or 
proprietary code differently from Open Source code.


Out mantra is "running code".  We try to stay out of people's business 
models.


The presence of a implementation is a useful measure.  The presence of 
interoperability between two independent implementations is clearly a 
much better measure.
But reading the code is not a good measure of the spec.  An implementer 
familiar with the discussions in the WG is likely to get right tings 
that are under-specified.  Such an implementation does not tell us 
anything about the quality of the spec.  Should we require an 
implementation done from the spec without talking to the authors or WG? 
 That would measure the spec better.  But would seem to be an 
unreasonable requiremet.


he IETF, to the degree it wants to encourage something, wants to 
encourage implementation.  It ought to be up to the implementors whether 
they see value in an open source, closed source, or some other form of 
implementation.


One could argue that it does not matter, since the experiment is not 
going to change anything.  But I will assume that it matters, and will 
change something.  If so, it should be "running code" that is the issue.


Yours,
Joel

PS: "Free" for whatever definition of "Free"distinct from Open Source 
the suggester meant, would seem to be completely irrelevant to the IETF.


On 12/3/2012 12:06 PM, Marc Petit-Huguenin wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/03/2012 08:54 AM, Stephen Farrell wrote:


On 12/03/2012 04:41 PM, Marc Petit-Huguenin wrote:

I support this idea, but I think that free software should also be
considered as part of this experiment (free software and open source are
not synonymous). Using the acronym FOSS and defining it as Free or Open
Source Software in the document would achieve this.


Fair point. OTOH, there are folks who want to not require open-source too.
For now, I'd gone with "ideally open-source." As I said to Sam, let's deal
with that, if need be, at IETF LC.


OK, but note that I will oppose for this experiment the use of software that
is not either available in source form or accompanied with a conformance test
suite.



In the meantime, I've posted -01 [1] with a bunch of changes. Do let me
know if I forgot to ack someone and as before all comments (inevitable,
this being a process thing;-) are very welcome.

Thanks, S.

[1] http://tools.ietf.org/html/draft-farrell-ft-01




- --
Marc Petit-Huguenin
Email: m...@petit-huguenin.org
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJQvNv6AAoJECnERZXWan7EV3QP/2Tv/rn7+GSwK2KkB3RsnS00
ryB5FH0drUdMr7c+TreHDXh/uR6HLYxB1Cg9rDd5CZQaSBQlTtwIKVUxMPOW805k
Uf3/xi8d3DpXVTmlesMtmbT/GeE7S0hJ3wf6LUwl4OkctX8GMDNuaONNudarl3Qt
sR+AJw8OU8KOFMqEn6fOqpLwY7OiQG3M6tuMwfNIm1Z0bHb/WAssF9l+J2ZTqq8L
AmJpHPql65WVSPck+jRnYyNtfnSkVCmCQ1y5cMeNoEnm5tkEt5oeinsvDwEAWBB3
5YzbUb+q72SCEyTbeVOrwTU1cBU/CKzOH+8r0ykK51KlZ1acYetwh31U4h1jDpHd
tNrwu1Z5wvKCa4b4dvzkiEBE83gAr6IGMDlPWNkEtotB1ZZd/MUpRNsSCzyivtl5
zr1rwpMY/5w6LljGO4jN4ZXKtXErFovEQpTc+bUz9K23WYyZMkARehXZLkbEvpb8
/MY1zGlgRSrGHr5Wn+k9egCeWqYjGNQedYpDcqWw7oQ5V956W+/AvKHo6jPGGweC
wpW3Hm+AWc3gPZ2pgYYt8dVScscWLo0qDWW4daHwAqu0rvge7PUB8aVagE72fQUn
fPEPhETD2QqZfXDeCtfNqOVS1/v+SYsAYxcGFYwu7NR51OROBkhMpWT5KDuaPp02
OPRv2MwPcsanVoQ1uNfY
=30oW
-END PGP SIGNATURE-

Re: Gen-ART Telechat Review of draft-ietf-karp-routing-tcp-analysis-06

[Joel M. Halpern]

Nick, I appreciate that you have read this document and commented.

Two general questions:
1) Can you be more specific about where you see unclear language usage? 
 It is hard to fix a general coment.


2) A number of your comments seem to be about general router security. 
Many of them would see far more appicable to RFC 6518.  This document is 
just about changes to protect TCP sessions (yes, what we are concerned 
about are the TCP sessions used by routers.)  Can you take a look at 
your comments, and tell us which ones are applicable to this document, 
and which ones should be held for when the community is ready to revise 
RFC 6518?


Thank you,
Joel

On 12/18/2012 5:12 PM, Nick Hilliard wrote:

On 18/12/2012 20:14, Ben Campbell wrote:

** Nits/editorial comments:

-- The 2119 paragraph was removed, but there's still an orphaned 2119 entry in 
the informational reference section.


I'm not sure that this was a good idea.  There are a lot of "has to"s in
this text, and it's not clear to me whether they are phrased like that as a
way of getting around 2119, or what's going on.  Whatever the reason, "has
to" sounds very informal and probably not suitable for a document like
this.  Could we have some clarification as to why "has to" doesn't mean
"MUST" (or even "SHOULD").

--

-   protocol stack from CPU-utilization based attacks.TCP Robustness
+   protocol stack from CPU-utilization based attacks. TCP Robustness

--

I have a general issue with the statement "TCP MD5 [RFC2385] has been
obsoleted by TCP-AO [RFC5925]."  At this time, I'm not aware of any live
TCP-AO implementations.  So while I understand that md5 is effectively
obsolete from the specification point of view, from the point of view of
operational reality it's still the only show in town (no-one uses ipsec for
this).

Secondly, as a general comment about the TCP MD5 option, no-one that I know
uses it as a serious security mechanism, but instead as a means of putting
the equivalent of a padlock on the barn door.  This does two things: 1. it
stops bgp sessions from being accidentally re-used (e.g. at IXPs or on
commercial providers who are re-using access ports), and 2. it simply
raises the bar in terms of difficulty.  If your barnyard door has a
padlock, and the one beside doesn't, the average lazy human being will
attempt to poke at the one which doesn't.


From an operational view, i would generally see the difference between

tcp/md5 and tcp/sha1 (via tcp-ao) as being similar to the difference
between a 5 pin and a 7 pin barrel lock.  Both look like a lock on the
outside, and the thief is probably going to smash a window to get in
anyway, or look for the key which the owners left under the mat.

--

There is a second operational issue which may merit mention here, namely
the issue of ensuring that whatever session layer authentication is
implemented on an actual network device, that it doesn't create more
problems than it solves.  Specifically, if session layer authentication is
pushed too far down the protocol stack, cryptographic authentication can
occur before other basic checks which might be a whole pile less CPU
intensive.  There was a scare about this several years ago when it turned
out that a well-known vendor had implemented tcp md5 checksumming before
more basic tcp session checks (e.g. seq numbers, ttl, etc).  In the event,
this turned out to be a red herring because md5 is sufficiently gentle on
the CPU that it didn't make much difference in reality.

However, there is cryptographic value in using more computationally
intensive hashing algorithms, and if routers (which often have relatively
slow general CPUs or route-processor CPUs) were to get trashed with a large
flood of packets which were signed with a cpu-intensive hashing algorithm,
and if the checksum were to be implemented in the wrong place in the TCP
stack, then this could become an actual problem.

I don't know whether these things should be noted in the draft.

--

It may be useful to consider whether to acknowledge the existence of rfc
6192 in the context of providing a link to what other steps might be useful
to secure routers.

--


pairs of routers when using TCP MD5.  It is well known that the
longer the same key is used, the greater the chance that it can be
guessed or exposed


I'm split between {{cn}} and [[Wikipedia:OBVIOUS]].  Hmmm, life's little
decisions.

--


Routers lack comprehensive key management and keys derived from it
that they can use to authenticate data.


clumsy wording (and grammatically incorrect).

--


Authentication, tamper protection, and encryption all require the use


should that second comma be dropped?  Not sure what the ietf style dictates.

--


Authentication, tamper protection, and encryption all require the use
of keys by sender and receiver.  An automated KMP therefore has to
include a way to distribute MKT between two end points with little or
no administration overhead.  It has to 

Re: Gen-ART Telechat Review of draft-ietf-karp-routing-tcp-analysis-06

[Joel M. Halpern]

Thank you Nick.
With regard to the suggest text replacement of "has to" with "needs to", 
if you think that will help, lets go wit it (at then let the RFC Editor 
tell us if it doesn't work.)


With regard to obsoleting TCP-MD5, that is what the RFCs say.  The 
TCP-MD5 is obsoleted by the TCP-AO RFC.  Further, the security folks are 
quite adamant that we should be shifting our recommendations, and where 
possible our practice.  If there are not yep implementations, we need to 
be pushing folks harder to get them.


If I understand your next item properly, you are asking that we add a 
sentence about the fact that implementation of security mechanisms needs 
to be doe carefully, so as not to make things worse.  Seems easy to do 
and can't hurt, so we should do so.


And equally, noting that security is more than cryptography, and more 
than signatures, is probably sensible.


Authors, WG, can we live with these?  I would think so.

Yours,
Joel

On 12/19/2012 6:14 PM, Nick Hilliard wrote:

On 18/12/2012 22:26, Joel M. Halpern wrote:

Nick, I appreciate that you have read this document and commented.

Two general questions:
1) Can you be more specific about where you see unclear language usage?  It
is hard to fix a general coment.


I was referring to the use of "has to", but the phrase only appears three
times so maybe it's not going to be a large amount of work to eradicate it.
  This might work:

s/has to/needs to/g

I overestimated to myself the number of times it appeared by flicking back
and forwards through the document when looking at it last night.


2) A number of your comments seem to be about general router security. Many
of them would see far more appicable to RFC 6518.  This document is just
about changes to protect TCP sessions (yes, what we are concerned about are
the TCP sessions used by routers.)  Can you take a look at your comments,
and tell us which ones are applicable to this document, and which ones
should be held for when the community is ready to revise RFC 6518?


6518 looks like a roadmap to me.  I don't see any of these comments as
being especially relevant to that document.

There are 3 general suggestions and the rest of the issues are either style
or syntax editing issues, and I think they are all relevant to this
document.  These suggestions are:

1:


I have a general issue with the statement "TCP MD5 [RFC2385] has been
obsoleted by TCP-AO [RFC5925]."  At this time, I'm not aware of any live
TCP-AO implementations.  So while I understand that md5 is effectively
obsolete from the specification point of view, from the point of view of
operational reality it's still the only show in town (no-one uses ipsec for
this).


We don't have running code for the new protocol, but we have very wide
deployment for the older protocol.  So I question how appropriate it is to
make a statement on whether the new protocol has obsoleted the old one.
I'm not familiar enough with ietf nous to know whether this is relevant to
a document like this.  Wearing my operator hat, it looks a little odd,
that's all.

2:


There is a second operational issue which may merit mention here, namely
the issue of ensuring that whatever session layer authentication is
implemented on an actual network device, that it doesn't create more
problems than it solves.  Specifically, if session layer authentication is
pushed too far down the protocol stack, cryptographic authentication can
occur before other basic checks which might be a whole pile less CPU
intensive.  There was a scare about this several years ago when it turned
out that a well-known vendor had implemented tcp md5 checksumming before
more basic tcp session checks (e.g. seq numbers, ttl, etc).  In the event,
this turned out to be a red herring because md5 is sufficiently gentle on
the CPU that it didn't make much difference in reality.

However, there is cryptographic value in using more computationally
intensive hashing algorithms, and if routers (which often have relatively
slow general CPUs or route-processor CPUs) were to get trashed with a large
flood of packets which were signed with a cpu-intensive hashing algorithm,
and if the checksum were to be implemented in the wrong place in the TCP
stack, then this could become an actual problem.


Whatever a router manufacturer does in terms of implementation, they need
to be careful when writing code to ensure that they don't accidentally open
up other attack vectors by implementing transport layer security badly.  It
almost happened once before, and this could have caused damage at the time
if we had had been using a computationally expensive algorithm like openbsd
bcrypt instead of md5.

3:


It may be useful to consider whether to acknowledge the existence of rfc
6192 in the context of providing a link to what other steps might be useful
to secure routers.


What I'm suggesting here is a single s

Re: Poster sessions

[Joel M. Halpern]

To be blunt, if someone is holding a bar BoF without making it primarily 
a focus for discussion, they are missing the benefit of a Bar BoF.  Yes, 
we have a lot of "bar bofs."  And to the degree people are using these 
as unapproved BoFs for presenting their ideas to a wider audience, 
rather than for small group discussions in order to figure out what 
takes place, I think folks are making a mistake.  (The existence of, or 
attendance at, such a  pre-BoF is basically irrelevant to the process of 
getting a BoF or working group at a future IETF.)  In fact, whether they 
get called that or not, we have a very large number of very effective, 
ad hoc, bar bofs where a group of people working on a topic get together 
to work on a set of issues around that topic.  If this is not yete a 
topic that the IETF is working on, then often the issues include 
figuring out more clearly what the problem is, so that it can be 
effectively presented to the IETF.


I think that the requester is asking for some way to have a large number 
of different individuals briefly present their ideas, somewhat 
informally, to the community, to see if there is interest in the idea. 
In principle, this sounds good.  It is indeed one of the functions of 
the area meetings, but that does not mean we can not do something 
additional.
However, when I try to work out the logistics of such a thing, at the 
scale of the IETF, my head starts to hurt.  We would not want it to 
conflict with any working group sessions, for example, since there could 
be "posters" on any imaginable topic.  And we would want some filtering, 
since there are many ideas that, while interesting, belong in other fora 
(NANOG does review, limit, and select their lightning talks, for 
example.)  And it is not clear how one would use such a session to take 
thing forward.  Finding a more effective way to get early ideas useful 
airing in the community seems like a very good thing for the community, 
and would help encourage new ideas.


Yours,
Joel

On 1/10/2011 8:47 AM, Yoav Nir wrote:


On Jan 10, 2011, at 1:22 PM, Loa Andersson wrote:


ALl,

what is here called "poster session" reminds me a awful lot of the
bar bof's we been running for a long time.


No coincidence. There's been a lot of criticism of these bar BoFs, and we keep 
looking for better ways to present new ideas.


Anyone care to draw the line between the two and try to motivate why
we need boths. As I see nothing stops from bringing a poster to a bar
bof, or a white board for taht matter.


Despite the name, a bar BoF today is very much lecture-style. You have a 
presentation and a time for questions. There's really very little room for 
actual discussion (which supposedly happens later in some mailling list). A 
poster session allows for conversation with the I-D author, which may or may 
not lead to better results.



/Loa



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


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

Re: Fwd: [OPS-DIR] OPS-DIR Review of draft-yevstifeyev-tn3270-uri-12

[Joel M. Halpern]

I would also point out that there is a difference between a contact for 
a draft and a contact for a registry.
For a draft, there is always an individual contact.  We frequently 
accept that the only contact information is an email address.


For a registry, the contact information requirement depends upon what 
the update policy is for the registry.


Yours,
Joel

On 1/13/2011 12:42 PM, Worley, Dale R (Dale) wrote:


From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Mykyta 
Yevstifeyev [evniki...@gmail.com]

Mentioning my full contact data makes no sense.  I can hardly imagine
that somebody will come to Ukraine, search Kotovsk (that is rather small
town) and than particular street, etc. to ask me about the URI scheme.
Those who want that would prefer to contact me by email.
___

In many cases, a person's postal address is more stable and easier to translate 
into other contact information than the person's e-mail address.

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


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

Re: draft-housley-two-maturity-levels

[Joel M. Halpern]

It seems to me that this proposal strikes a good balance in making an 
effort to improve the situation regarding our document track.


Regarding the particular clause:

On 1/24/2011 1:30 PM, Peter Saint-Andre wrote:
...

2. I found this statement to be strange:

The intention of the two-tier maturity
ladder is to restore the requirements for Proposed Standard from RFC
2026.

Why "restore"? Have they been superseded or ignored? I suggest "retain".


I think the use of the word "restore" is very important. Over the years, 
our informal requirements and our sense of what was needed for Proposed 
Standard have moved up noticeably.  This reflected a number of factors, 
all of them driven as best I can tell by good intentions.
Restoring the lower bar for PS is probably the most direct benefit this 
proposal can have on our work.


Separately, the replacement of the requirement for verified 
interoperability with the assumption of interoperability based on wide 
deployment is an understandable compromise.  I am not sure I like this 
change, but I can live with it, which is good enough.


I do like the more relaxed wording on the removal of unused features.

Yours,
Joel M. Halpern
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Request for review of draft-yevstifeyev-genarea-historic-03

[Joel M. Halpern]

There are, in my opinion, two problems with Mr. Yevstifeyev's assertion 
below that it is easy to determine when things are out of use.
The first point, to echo Andrew Sullivan, is that even if a protocol is 
in use on the public Internet, it is not always easy to detect.  It may 
be used in only some portions of the net.  It may be used inside some 
other protocol that makies detection ahrder.
The second point is that enterprise uses and other private network uses 
are still valid uses.  The fact that a protocol may be used only inside 
a virtual private network, or only inside a corporate data center, or in 
only within a military facility, does NOT mean that it is not used. 
Such limited use is still valid use and should not result in our 
declaring something obsolete.


Yours,
Joel

On 3/3/2011 4:27 AM, Mykyta Yevstifeyev wrote:

Hello Eliot,

Thank you for reading the document.  Pleas efind some comments in-line.

2011/3/2, Eliot Lear:

...

I bring to your attention RFC-4450, in which we made a bulk status
change of a bunch of PS to Historic precisely because we couldn't find
anyone using those protocols.  However, such observations are
imprecise.  For one, it is hard to observe what is going on on the
Internet, and those who do don't usually share their data (there is
some, but it is often regionally based, like the GINORMOUS store at
ETHZ).  Another issue is that a protocol that is not detectable on the
Internet might be in use on private networks.


When we say 'out-of-use' we consider the usage of something in the
overall Internet.  It is mostly not very difficault to find this out
via those people who take part in the IETF.

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

Re: Request for review of draft-yevstifeyev-genarea-historic-03

[Joel M. Halpern]

No, I do not agree with you.
Our current definition for historic, and our current choices for when to 
move things, have worked sufficiently well.

I have not seen any evidence that there is a problem that needs solving.
I have also not seen any evidence that the changes you propose to the 
definitions would help anything.


Yes, there are problems with our current definitions.
Those problems serve to keep us from declaring something historic when 
we shouldn't.
They do, as a side effect, make it harder to declare things historic 
even if they actually are?
I will even agree that there is a small cost to that.  Users of our 
standards may sometimes think some things are relevant that aren't.


But changing the definitions to make it easier to change the status does 
not actually change the problem.  The problem is that it is hard for 
anyone (the IETF, vendors, operators) to reliably know what is actually 
in use.


Yours,
Joel

PS: I have actually noticed with several specifications I worked with 
that it can easily take 5 or 10 years for the actual usage (often not 
the initially expected usage) for a standards track or experimental 
protocol to emerge.  So premature declaration taht something is historic 
can do actual damage.


On 3/3/2011 10:28 AM, Mykyta Yevstifeyev wrote:

Joel,

I agree with you that it is really hard and even impossible to determine
what is going on in the Internet regarding some technology, protocol,
etc. If we set the impossible criterion for the Historic documents, this
will really make very few sense. So, as I have been pointed out, I find
removing the regulation about 'out-of-use' technology at all quite
acceptable. Do you agree?

And as for the comment from Dave.

03.03.2011 17:18, Dave CROCKER wrote:



On 3/3/2011 7:11 AM, Joel M. Halpern wrote:

The first point, to echo Andrew Sullivan, is that even if a protocol
is in use
on the public Internet, it is not always easy to detect.

...

The second point is that enterprise uses and other private network
uses are
still valid uses. The fact that a protocol may be used only inside a
virtual
private network, or only inside a corporate data center, or in only
within a
military facility, does NOT mean that it is not used. Such limited
use is still
valid use and should not result in our declaring something obsolete.



+1

Declaration of historic needs to be based on affirmative data. The
declaration is actually only important to make for protocols that are
known to be problematic.

This is already covered by the 'deprecated' criteria in my draft.

All the best,
Mykyta Yevstifeyev


Issuing a declaration for mere non-use is a matter of convenience, not
need, IMO.

d/


03.03.2011 17:11, Joel M. Halpern wrote:

There are, in my opinion, two problems with Mr. Yevstifeyev's
assertion below that it is easy to determine when things are out of use.
The first point, to echo Andrew Sullivan, is that even if a protocol
is in use on the public Internet, it is not always easy to detect. It
may be used in only some portions of the net. It may be used inside
some other protocol that makies detection ahrder.
The second point is that enterprise uses and other private network
uses are still valid uses. The fact that a protocol may be used only
inside a virtual private network, or only inside a corporate data
center, or in only within a military facility, does NOT mean that it
is not used. Such limited use is still valid use and should not result
in our declaring something obsolete.

Yours,
Joel

On 3/3/2011 4:27 AM, Mykyta Yevstifeyev wrote:

Hello Eliot,

Thank you for reading the document. Pleas efind some comments in-line.

2011/3/2, Eliot Lear:

...

I bring to your attention RFC-4450, in which we made a bulk status
change of a bunch of PS to Historic precisely because we couldn't find
anyone using those protocols. However, such observations are
imprecise. For one, it is hard to observe what is going on on the
Internet, and those who do don't usually share their data (there is
some, but it is often regionally based, like the GINORMOUS store at
ETHZ). Another issue is that a protocol that is not detectable on the
Internet might be in use on private networks.


When we say 'out-of-use' we consider the usage of something in the
overall Internet. It is mostly not very difficault to find this out
via those people who take part in the IETF.

...





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

[Gen-art] review: draft-ietf-netext-pmip6-lr-ps-05

[Joel M. Halpern]

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-netext-pmip6-lr-ps-05
PMIPv6 Localized Routing Problem Statement
Reviewer: Joel M. Halpern
Review Date: 7-March-2011
IETF LC End Date: 14-March-2011
IESG Telechat date: 17-March-2011

Summary: This document is close to ready for publication as an 
Informational RFC.


Moderate issues:
The abstract is misleading.  It reads as if the problem is allowing 
communication between a PMIP mobile node and a correspondent, wherever 
the correspondent is.  Even the introduction is somewhat hazy on its 
scope, sometimes referring to the generalized notion of correspondent 
node, and sometimes seeming to mean just the sub-case of two nodes, both 
attached to MAGs, in the same domain.  It is only in the conventions and 
terminology that "Localized Routing" is actually defined in a way to 
make clear what problem is of interest.



Minor issues:
	In the introduction, the word "problem space" is used to describe what 
is being covered in this document.  However, the document includes 
sections such as section 4, Functional Requirements for Localized 
Routing which are not about the problem, but rather about what 
mechanisms are needed for a solution.  Rather than argue about what 
belongs in this document, or the document name, I would suggest 
clarifying in the introduction what this document is actually doing.
	While the arguments at the end of section 3.1 sound plausible, they 
are, as far as I can tell, quite controversial in the mobile industry. 
I have heard speakers make exactly opposite assertions about several of 
these claims.  As such, I think this paragraph ought to be toned down.
	I found myself confused by the text in section 5. I think that the 
problem is that I assume that a "Local Mobility Agent" will be in the 
same domain as the Mobile Access Gateway handling the client the LMA is 
supporting (otherwise it sems not to be local.)  Given the discussion of 
Roaming, and the way it is constructed, this appears not to be the case. 
 If there is no such domain coupling requirement, then could you please 
add a note to that effect somewhere early in the document (possibly in 
the introduction along with a better description of the problem.)


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

Re: draft-housley-two-maturity-levels

[Joel M. Halpern]

There seems to be a minor but important inconsistency which leaves us 
still not clearly addressing the interoperability issues.


The commentary text on the second standards level includes, when 
commenting on the removal of the requirement for interoperability 
testing reports:

   subsumed by the requirement for
   actual deployment and use of independent and interoperable
   implementations.

While not perfect (nothing is), such a requirement would probably leave 
me satisfied.  However, there is no requirement in general for multiple 
independent implementations.  There is a requirement for multiple 
implementations and successful operational experience.  There is only a 
requirement for independent implementations relative to patented or 
otherwise controlled technologies.  And even that requirement does not 
say anything about any interoperability of those independent 
implementations.


Yours,
Joel


On 3/13/2011 7:32 PM, Russ Housley wrote:

There have been conflicting suggestions about the best way forward.  We have 
constructed an updated proposal.  It has been posted as 
draft-housley-two-maturity-levels-04.

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


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

Re: draft-housley-two-maturity-levels

[Joel M. Halpern]

As far as I can tell, your proposal does not match the meaning we use 
for Historic.
More importantly, there does not seem to be a problem that needs to be 
addressed in this area.
Most importantly, if there is a problem, it should in my opinion be 
addressed separately from the topic of this draft.  Please do not 
conflate the two.


Yours,
Joel M. Halpern

On 3/24/2011 11:32 AM, Mykyta Yevstifeyev wrote:

Russ, all,

Another proposal as for your document. So, it fails to mention what are
the procedures for reclassification of Standards Track RFCs to Historic.
Therefore, I propose the following text:



6. Procedures for Reclassification of Standards Track RFCs as Historic
Documents

Under some circumstances Standards Track RFCs may be reclassified to
Historic document (i. e. its initial status may be changed to
Historic). RFC 2026 [1], as well as its predecessors, contains some
words about the Historic RFCs, but it failes to define the procedures
for reclassification of RFCs to Historic status. Such situation, of
course, causes misunderstandings of the members of the community. This
document removes this uncertainty; it defines the circumstances under
what the Standards Track RFC should be moved to Historic status and
describes the procedures for such action.

The Standards Track RFC, either Proposed Standard or Internet
Standard, should be considered to be appropriate for reclassification
as Historic document if (a) there is another document that replaces it
or (b) it described the protocol or other technology that got out-of-use.

In the case mentioned as (a) above the superseding document should
just have the notice of the necessity of reclassification of its
predecessor to Historic. However such action is not obligatory.

In the case mentioned as (b) above the procedure is as follows. If the
individual or a group of individuals (e. g. IETF working group) assume
that the protocol or other technology defined in the Standards Track
RFC is now out-of-use and is very unlikely to become widely used in
the future, they SHALL apply to IESG to request the reclassification
of such document to Historic. IESG SHALL then issue the IETF-wide Last
Call on this action, not shorter than 2 weeks, in order to determine
whether there is the community consensus on reclassification. If Last
Call did not reveal community objection to this action, this document
SHALL be reclassified to Historic.

During the sunset period, set by this document, Draft Standards SHALL
be reclassified to Historic using the procedure as defined above.

... and renumber the following sections.

What do you think about this proposal?

Mykyta Yevstifeyev

14.03.2011 1:32, Russ Housley wrote:

There have been conflicting suggestions about the best way forward. We
have constructed an updated proposal. It has been posted as
draft-housley-two-maturity-levels-04.

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



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


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

Re: [IAB] IETF and APIs

[Joel M. Halpern]

Specifying the service interface a protocol provides (and what it 
requires from other protocols) is often very useful.  And is something 
we have done in many cases.
Writing a set of subroutine definitions in some specific language is, in 
my experience, usually far less useful.


As a related note, a program is not a protocol spec, and a protocol spec 
is not an implementation design document.  They serve different purposes 
and should not be conflated.


Yours,
Joel

On 3/30/2011 7:02 AM, Joe Touch wrote:



...

RFC793 is a great example that a protocol provides a service, and that
service needs to be explained - and that explaining it does NOT need to
be done in a specific language.

...

And yes, it is still one of the great RFC; is that because it describes
something that became rather popular or is it because it describes
something so well that popularity was inevitable?


I think the latter; it understood that a protocol is:

A- format on the wire of messages that arrive and depart
B- state within participating parties
C- events from/to the upper layer
D- rules that relate the three above

The "API" as we commonly call it is "C" above. I've seen quite a few
IETF "protocols" that focus only on "A".

IMO it takes all four to be complete.

Joe


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

Re: [paws] WG Review: Protocol to Access White Space database (paws)

[Joel M. Halpern]

I think this working group is a good idea.
My inclination would be to place it in the Applications area.  It looks 
like a nice application protocol to me.
There is a reasonable argument for placing it in RAI, as that is where 
the relevant GEOLOC work has been done up till now.


Yours,
Joel M. Halpern

On 4/19/2011 12:56 PM, IESG Secretary wrote:

A new IETF working group has been proposed.  The IESG has not made any
determination as yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to the
IESG mailing list (i...@ietf.org) by Tuesday, April 26, 2011.


Protocol to Access White Space database (paws)

Current Status: Proposed Working Group
Last updated: 2011-04-14

Chairs:
TBD

Area Directors:
TBD

Area Advisor:
TBD

Mailing lists:
Address: p...@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/paws
Archive: http://www.ietf.org/mail-archive/web/paws/

Description of Working Group:

Governments around the world continue to search for new pieces of radio
spectrum which can be used by the expanding wireless communications
industry to provide more services in the usable spectrum. The concept
of allowing secondary transmissions (licensed or unlicensed) in
frequencies allocated to a primary user is a technique to "unlock"
existing spectrum for new use. An obvious requirement is that these
secondary transmissions do not interfere with the primary use of the
spectrum. Often, in a given physical location, the primary user(s) may
not be using the entire band allocated to them. The available spectrum
for a secondary use would then depend on the location of the secondary
user. The primary user may have a schedule when it uses the spectrum,
which may be available for secondary use outside that schedule. The
fundamental issue is how to determine for a specific location and
specific time, if any of the primary spectrum is available for secondary
use. One simple mechanism is to use a geospatial database that records
protected contours for primary users, and require the secondary users to
check the database prior to selecting what part of the spectrum they
use. Such databases could be available on the Internet for query by
users.

In a typical implementation of geolocation and database to access TV
white space, a radio is configured with, or has the capability to
determine its location in latitude and longitude. At power-on, before
the device can transmit or use any of the spectrum set aside for
secondary use, the device must identify the relevant database to query,
contact the database, provide its geolocation and receive in return a
list of unoccupied or "white space" spectrum (for example, in a TV
White space implementation, the list of available channels at that
location). The device can then select one of the channels from the list
and begin to transmit and receive on the selected channel. The device
must query the database subsequently on a periodic basis for a list of
unoccupied channels based on certain conditions, e.g. a fixed amount of
time has passed or the device has changed location beyond a specified
threshold.

The databases are expected to be reachable via the Internet and the
devices querying these databases are expected to have some form of
Internet connectivity, directly or indirectly. The databases may be
country specific since the available spectrum and regulations may vary,
but the fundamental operation of the protocol should be country
independent, thus extensibility of data structures will be required. The
solution will not be tied to any specific spectrum, country, or
phy/mac/air interface but may incorporate relevant aspects of these as
needed for proper operation.

The proposed working group will :
- standardize a protocol for querying the database, which includes a
location sensitive database discovery mechanism and security for the
protocol, and application services.
- Standardize the data structure to be carried by the query
protocol.

The protocol must protect both the channel enablement process and the
privacy of users. Robust security mechanisms are required to prevent:
device identity spoofing, modification of device requests, modification
of channel enablement information, impersonation of registered database
services and unauthorized disclosure of a users location.

Existing IETF location data structures and privacy mechanisms may be
considered for use. The WG will also investigate the need for other
mechanisms and related protocols to the White Space DB.

The Working Group will set up and maintain appropriate contact and
liaison with other relevant standards bodies and groups, including IEEE
802.11af and IEEE 802.22 to begin with. The working group may also
consider input from regulatory entities that are involved in the
specification of the rules for secondary use of spectrum in specific
bands.

Goals and Milestones

Sep 2011  Subm

Re: [paws] WG Review: Protocol to Access White Space database (paws)

[Joel M. Halpern]

Clearly, the discussion about whether the application protocol should be 
XML, plain ASCII/UTF8, binary, or some other encoding needs to take 
place.  But that can take place wherever we place the working group.


There is an argument, which you allude to, which would place this WG in 
the Internet Area as part of "infrastructure."  While that does not 
resonate with me, I do see that there is some merit in that perspective.


I tend to think we need to focus on transactional application experience 
(the apps area) or where we have experience with protocols that need to 
communicate geolocation (RAI).


I would hope, and expect, that the ADs for any area would be receptive 
to a proper evaluation of any candidate protocol and encoding.  (The 
arguments get complex, and it takes care to avoid religious assertions.)


Yours,
Joel

On 4/19/2011 3:47 PM, Paul Lambert wrote:



How does the area that the group is assigned impact the choices of technology?

I'm an advocate for an efficient solution set for PAWS ... it will be much like 
DNS for spectrum in the future and should be viewed as a core infrastructural 
component that needs careful design.  There are good reasons that routing 
protocols don't use XML.

Applications now days tend to go for the simple, quick to make a web application 
solutions using XML or the like ...  My concern is that "Applications" imply 
that efficiency does not matter.

Paul




-Original Message-
From: paws-boun...@ietf.org [mailto:paws-boun...@ietf.org] On Behalf Of
Joel M. Halpern
Sent: Tuesday, April 19, 2011 10:50 AM
To: i...@ietf.org
Cc: p...@ietf.org; IETF discussion list
Subject: Re: [paws] WG Review: Protocol to Access White Space database
(paws)

I think this working group is a good idea.
My inclination would be to place it in the Applications area.  It looks
like a nice application protocol to me.
There is a reasonable argument for placing it in RAI, as that is where
the relevant GEOLOC work has been done up till now.

Yours,
Joel M. Halpern

On 4/19/2011 12:56 PM, IESG Secretary wrote:

A new IETF working group has been proposed.  The IESG has not made

any

determination as yet. The following draft charter was submitted, and

is

provided for informational purposes only. Please send your comments

to the

IESG mailing list (i...@ietf.org) by Tuesday, April 26, 2011.


Protocol to Access White Space database (paws)

Current Status: Proposed Working Group
Last updated: 2011-04-14

Chairs:
TBD

Area Directors:
TBD

Area Advisor:
TBD

Mailing lists:
Address: p...@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/paws
Archive: http://www.ietf.org/mail-archive/web/paws/

Description of Working Group:

Governments around the world continue to search for new pieces of

radio

spectrum which can be used by the expanding wireless communications
industry to provide more services in the usable spectrum. The concept
of allowing secondary transmissions (licensed or unlicensed) in
frequencies allocated to a primary user is a technique to "unlock"
existing spectrum for new use. An obvious requirement is that these
secondary transmissions do not interfere with the primary use of the
spectrum. Often, in a given physical location, the primary user(s)

may

not be using the entire band allocated to them. The available

spectrum

for a secondary use would then depend on the location of the

secondary

user. The primary user may have a schedule when it uses the spectrum,
which may be available for secondary use outside that schedule. The
fundamental issue is how to determine for a specific location and
specific time, if any of the primary spectrum is available for

secondary

use. One simple mechanism is to use a geospatial database that

records

protected contours for primary users, and require the secondary users

to

check the database prior to selecting what part of the spectrum they
use. Such databases could be available on the Internet for query by
users.

In a typical implementation of geolocation and database to access TV
white space, a radio is configured with, or has the capability to
determine its location in latitude and longitude. At power-on, before
the device can transmit or use any of the spectrum set aside for
secondary use, the device must identify the relevant database to

query,

contact the database, provide its geolocation and receive in return a
list of unoccupied or "white space" spectrum (for example, in a TV
White space implementation, the list of available channels at that
location). The device can then select one of the channels from the

list

and begin to transmit and receive on the selected channel. The device
must query the database subsequently on a periodic basis for a list

of

unoccupied channels based on certain conditions, e.g. a fixed amount

of

time has passed or the device has changed location beyond a specified
threshold.

Re: [paws] WG Review: Protocol to Access White Space database (paws)

[Joel M. Halpern]

Actually, as far as I can tell, there is very little parallel between 
the PAWS problem and SNMP.
SNMP tends to be initiated by the manager, and used to extract 
information from the device in the network, or set information in teh 
device.
This protocol is used by the client.  It extracts basically stable 
information about what frequencies can be used in this geographic region 
at this time.
There is no "network management" going on.  the interaction does not 
look like SNMP.  And the effect does not look like SNMP.  While Radius 
or Diameter are closer, this protocol is not even a policy decision 
protocol.  There is no "policy".


So no, I do not think this looks anything like network management.
The protocols, the transaction drivers and behavior, the problem space, 
and the underlying data behavior are all very different from any of our 
NM work.


Yours,
Joel

On 4/19/2011 5:21 PM, Rex Buddenberg wrote:

On Tue, 2011-04-19 at 12:47 -0700, Paul Lambert wrote:


How does the area that the group is assigned impact the choices of
technology?

I'm an advocate for an efficient solution set for PAWS ... it will be
much like DNS for spectrum in the future and should be viewed as a
core infrastructural component that needs careful design.  There are
good reasons that routing protocols don't use XML.


While the DNS analogy works, I was thinking more a parallel -- or
extension -- of SNMP.

Still remain within 'applications', Joel?



Applications now days tend to go for the simple, quick to make a web
application solutions using XML or the like ...  My concern is that
"Applications" imply that efficiency does not matter.

Paul




-Original Message-
From: paws-boun...@ietf.org [mailto:paws-boun...@ietf.org] On Behalf Of
Joel M. Halpern
Sent: Tuesday, April 19, 2011 10:50 AM
To: i...@ietf.org
Cc: p...@ietf.org; IETF discussion list
Subject: Re: [paws] WG Review: Protocol to Access White Space database
(paws)

I think this working group is a good idea.
My inclination would be to place it in the Applications area.  It looks
like a nice application protocol to me.
There is a reasonable argument for placing it in RAI, as that is where
the relevant GEOLOC work has been done up till now.

Yours,
Joel M. Halpern

On 4/19/2011 12:56 PM, IESG Secretary wrote:

A new IETF working group has been proposed.  The IESG has not made

any

determination as yet. The following draft charter was submitted, and

is

provided for informational purposes only. Please send your comments

to the

IESG mailing list (i...@ietf.org) by Tuesday, April 26, 2011.


Protocol to Access White Space database (paws)

Current Status: Proposed Working Group
Last updated: 2011-04-14

Chairs:
TBD

Area Directors:
TBD

Area Advisor:
TBD

Mailing lists:
Address: p...@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/paws
Archive: http://www.ietf.org/mail-archive/web/paws/

Description of Working Group:

Governments around the world continue to search for new pieces of

radio

spectrum which can be used by the expanding wireless communications
industry to provide more services in the usable spectrum. The concept
of allowing secondary transmissions (licensed or unlicensed) in
frequencies allocated to a primary user is a technique to "unlock"
existing spectrum for new use. An obvious requirement is that these
secondary transmissions do not interfere with the primary use of the
spectrum. Often, in a given physical location, the primary user(s)

may

not be using the entire band allocated to them. The available

spectrum

for a secondary use would then depend on the location of the

secondary

user. The primary user may have a schedule when it uses the spectrum,
which may be available for secondary use outside that schedule. The
fundamental issue is how to determine for a specific location and
specific time, if any of the primary spectrum is available for

secondary

use. One simple mechanism is to use a geospatial database that

records

protected contours for primary users, and require the secondary users

to

check the database prior to selecting what part of the spectrum they
use. Such databases could be available on the Internet for query by
users.

In a typical implementation of geolocation and database to access TV
white space, a radio is configured with, or has the capability to
determine its location in latitude and longitude. At power-on, before
the device can transmit or use any of the spectrum set aside for
secondary use, the device must identify the relevant database to

query,

contact the database, provide its geolocation and receive in return a
list of unoccupied or "white space" spectrum (for example, in a TV
White space implementation, the list of available channels at that
location). The device can then select one of the channels from the

list

and begin to transmit and receive on the selected channe

Re: [paws] WG Review: Protocol to Access White Space database (paws)

[Joel M. Halpern]

Building from Bernard's note, it strikes me that if we are going to get 
into device identity, we probably need to be communicating with (liaise) 
3GPP/3GPP2, because they have very strong views on that topic.  (Whether 
one agrees or disagrees with their biases, talking to them seems important.)


Yours,
Joel

On 4/20/2011 10:55 AM, Bernard Aboba wrote:

When I hear the term "device identity spoofing", IEEE 802.1ar comes to
mind (see http://standards.ieee.org/getieee802/download/802.1AR.-2009.pdf).

In addition to the liaisons with IEEE 802.19, 802.22 and IEEE 802.11af,
is there a liaison contemplated to IEEE 802.1 relating to "device identity"?


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

[Gen-art] Review: draft-ietf-mboned-maccnt-req-10

[Joel M. Halpern]

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-mboned-maccnt-req-10
Requirements for Multicast AAA coordinated between
Content Provider(s) and Network Service Provider(s)
Reviewer: Joel M. Halpern
Review Date: 22-April-2011
IETF LC End Date: 5-May-2011
IESG Telechat date: N/A

Summary: This document is not ready for publication as an Informational RFC.

Top Line: This document seems to assume a very specific deployment and a 
specific set of tools from our repertoire.  It also tends to make 
assumptions about the solution that it envisions, which confuse the 
requirements statements.  As such, it needs significant work before it 
may be suitable for publication.


Major issues:
1) The document assumes a specific set of protocols are used, and are 
the only tools used, for handling the problem space.  IGMP / MLD is not 
our only tool, and the document should not be written as if it is the 
only tool.

  This was noted in a 2006 Discuss comment! 

1') The document says that it is about Requirements for AAA related to 
Multicast.  It then repeatedly dives into QoS issues.  Other than the 
quesiton of enabling the AAA to provide the QoS information (which is 
never discussed at all), QoS should not appear in this document.


There seem to be a number of cases in section 4 of assuming a solution, 
rather than stating the requirements.


2) After postulating a business model in which the network operator and 
the content provider are distinct, the requirements then assert that 
content distribution control is the network's job.  Enabling the content 
provider to ensure that only authorized users get content is the 
network's job.  But the methods for doing so should be left to the 
solution, not the requirements.  (And then makign the requirement a 
network option makes it even more confusing.)


3) The item on Sharing Program Data seems to have some sort of 
assumption about how information is managed.  Since I can easily 
envision architectures for the separation, which allow multicast, which 
do not required what the document calls "Shard Programming data", there 
seems to be a problem here.


4) In section 5, the documents appears to assume that the network must 
and needs to unilaterally decide whether to admit users to multicast 
trees.  It also states that this is needed for QoS protection.  Given 
the nature of multicast, both statements are likely misleading.


5) The last paragraph of section 5 seems to assert that the operator 
could choose not to deliver some multicast streams to some subscribers 
if this would adversely affect the QoS experienced by other users.  I 
think that there are serious problems with such an assertion appearing 
in an IETF informational document.


6) The section on concomitant requirements mixes items of a different 
nature together.  It has one item that really belongs in this document, 
namely scale.  It has one very confusing item, namely Small Impact on 
the Existing Product.  And the rest of the items in teh section do not 
belong in this document at all.


6') On the "Small Impact" item, given that different operators have 
deployed different solutions, using different pieces of technology, it 
seems very hard to define a solution that has "small" impact on all 
operators.


7) What is section 9?  Is it a diagram  of some existing deployment 
architecture?  Is it an effort to define a solution?  It does not define 
any requirements.


Minor issues:
1) I find the approach the document takes to its "requirements" 
ingenuous, and misleading.  The document is actually a proposal for a 
business model that it wants supported.  This business model includes 
well-respected notions, such as the separation of content providers from 
network operators.  it also includes assumptions about the charging 
basis for the service, and who needs what visibility to whom.  While 
these may indeed be accurate assumptions, treating them as givens, on 
the basis of which a set of requirements can be asserted, seems 
inappropriate.


2) There is a related implicit assumption that individual user usage is 
somehow related to overall network consumption.  The whole point of 
using multicast is to avoid that coupling, i.e. the increase in network 
consumption is much lower than the increase in user consumption.


3) The paragraph in section 5 on the user edge stream join admissions 
seems to be about a particular view of how an operator would deliver 
suitable QoS to a subscriber.  This seems to assume certain 
relationships between the user's requests and the operators network, and 
certain operational behaviors.  They may or may not be accurate.  They 
also appear to be a

Re: Last Call: (The 'about' URI scheme) to Proposed Standard

[Joel M. Halpern]

The question is what "necessary" means in terms of willful violations of 
specs.  There are at least three cases I can understand, with different 
implications:


There are cases where the existing spec, while it claims to apply, 
actually is a bad idea.  Then we need to document the problem and the 
solution, and make sure the community agrees to the change.  This 
happens.  It usually results in an "updates" indication in the new spec, 
so folks know that the old one is not complete.


There are cases where a spec is documenting existing practice.  IIt can 
document that practice is different from the spec.  It has to do so 
while carefully being clear that the standards should apply, and that 
the practice does not match.  It is often useful to discuss the reasons 
for the mismatch.


Then there are cases where folks are attempting to standardizea space 
that has been unclear, under-specified, or a mess, and much of the space 
does not comply with the specs.  That is NOT a good reason to 
standardize non-compliant behavior.


I can not tell which of those you mean when you say that "Willful 
violations of other specs where necessary are acceptable."


Yours,
Joel


On 6/16/2011 5:20 AM, Lachlan Hunt wrote:

On 2011-06-16 11:14, Julian Reschke wrote:

On the other hand, you're trying to define a URI scheme. If it's
handling conflicts with the base URI spec, that's a bug. Period. You may
*document* that some UAs have this bug, but you can't change it to be
not a bug.


Theoretical purity is not a priority for the specs I edit. Wilful
violations of other specs where necessary are acceptable.


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