Re: 2119bis

[Sam Hartman]

> "Eric" == Eric Burger  writes:

Eric> This highlights an interesting issue as an RFC goes from PS to
Eric> IS.  I would offer that most SHOULDs in a document will, if
Eric> there are real implementations out there, migrate to MUST or
Eric> MUST NOT.
Eric> On Aug 31, 2011, at 9:57 AM, hector wrote:

Hmm.  Most of the times I use SHOULD I'd expect them to stay SHOULD.
SHOULD doesn't mean "this feature is desired," it means "do this unless
you have justification for doing something else." There are a few cases
(new algorithms) where you mean SHOULD+ (we'll move to MUST in the
future) but often you mean do this unless you're in a constrained
environment, or you know you won't need it or something like that. In
those cases, SHOULDS tend to stay SHOULDS.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Conclusion of the last call on draft-housley-two-maturity-levels

[ned+ietf]

> On Sep 2, 2011, at 7:07 PM, Ned Freed wrote:

> >> As far as our process is concerned, the question is, do we have rough
> >> consensus to accept it?  I think it's dubious that we have such consensus, 
> >> and
> >> apparently so do others.
> >
> > Simply put, I've watched the responses to this fairly closely, and I 
> > completely
> > disagree with your assessment.

> ok.

> >> Personally I think this proposal is Mostly Harmless, so I'm willing to hold
> >> my nose about it.   But I'm very concerned about the argument that the 
> >> default
> >> assumption should be that we change our process even in the absence of
> >> consensus to do so.
> >
> >> Regarding the proposal, I get the impression that people are mostly in 
> >> three
> >> camps:
> >
> > Well, none of these describe my own position, which is that eliminating the
> > three step process will at a minimum act as an incentive to move more 
> > documents
> > along. (You, and most others engaging in this debate, routinely neglect the
> > psychological factors involved.)
> >
> > I can easily name a dozen RFCs, all currently at proposed, that I for one 
> > will
> > be strongly incented to work to advance if this step is taken.

> At the risk of playing devil's advocate, how will that help?  Will the
> specifications significantly improve in quality and interoperability improve
> as a result?

First of all, since when is improving specifications the sole purpose of the
IETF standards advancement process? As I understand it, the goal behind having
different document statuses is for the labels to tell implementors how well
things are likely to actually work.

In other words, I categorically reject your implied assumption here that the
IETF advancement process only makes sense when specifications are improved
along the way. Plenty of specifications currently at proposed are of sufficient
quality to be full standards right now. Our problem is right now the process is
so onerous few people bother, so the presence of the higher label is useful but
the absence of it is not.

But even if I were to accept your tacit assumptions about the purpose of the
process - which I most assuredly do not - the answer is yes, some and perhaps
all of these specifications will be improved along the way, and at least a
couple are likely to be significantly improved. Features that in hindsight
turned out to be problematic will be removed, prose will be checked and
tightend, etc. etc.

If you think specification advancement doesn't receive this level of scrutiny
and resulting improvement currently, you haven't been paying attention.

> Will the blessing of these documents as Internet Standards result in wider
> implementation and thus greater benefit to users?   (not knowing which RFCs
> you're talking about, I can't even guess)

Keith, you know as well as I do that there can be no guarantess that the
Internet will care about anything we do, let alone see value in such
advancements. But given past experience it seems very likely that at least some
benefits along these lines will be accrued.

> From my perspective there's little problem with implementing and deploying at
> Proposed and having documents stay at Proposed indefinitely, provided we can
> ensure that the specifications are of high quality by the time they get to
> Proposed.  And given that people do tend to implement and deploy at Proposed,
> there's only marginal benefit to promoting them to anything else - except on
> those occasions where this serves as a carrot to fix bugs in the original spec
> that people might otherwise live with.  And it's not clear to me that the
> proposed change increases the incentive to do either.

And what happens in this world of only proposed standards when, as is often the
case despite all the absurd added scrutiny we now apply to proposed standards,
something problematic slips past us all? The simple fact that we almost always
make changes, and often significant ones, to documents that advance, shows we
don't always get it right. And when this happens what's the alternative? Once
something is approved it can be very difficult to get consensus to move it
historic.

You appear to be assuming that if we stare at stuff long enough and review it
hard enough we'll find all the issues in one step. Sorry, it never worked this
way in the past, and as the complexity of specifications has increased, it
works even less well now than ever before. Specifications have to be tried, and
tried at scale, to tell if they are any good.

Indeed, past experience indicates that the sorts of additional review you have
repeatedly advocoted for in these discussions usually backfires: It has an
uncanny way of turning the process into a beauty contest were important work
gets stifled just because it ran contrary to some higher-up's beliefs about
something. Once again you're failing to take psychological factors into
account, and they *matter*.

> > Additionally, by simplifying the process, we will gain essenti

Re: https

[Alexa Morris]

The new SSL certificates have been received, and installed.

Regards,
Alexa

On Sep 1, 2011, at 8:57 AM, SM wrote:


At 03:50 26-08-2011, Scott Schmit wrote:

Mistakes happen. Hopefully lessons are learned so that they don't get
repeated.


It has been a week since the problem was reported and the SSL  
certificate is still showing up as expired.


Regards,
-sm
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



---
Alexa Morris / Executive Director / IETF
48377 Fremont Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / Fax: +1.510.492.4001
Email: amor...@amsl.com

Managed by Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com 

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

Re: Discuss criteria for documents that advance on the standards track

[Bernard Aboba]

[BA] My comment is that having guidelines for this could help make the 
advancement process more predictable.  Thank you for working on this.   
Jari Arkko said:
During the discussion of the two maturity levels change, a question was brought 
up about DISCUSSes appropriate for documents that advance on the standards 
track. We discussed this in the IESG and I drafted some suggested guidelines. 
Feedback on these suggestions would be welcome. The intent is to publish an 
IESG statement to complement the already existing general-purpose DISCUSS 
criteria IESG statement 
(http://www.ietf.org/iesg/statement/discuss-criteria.html). 
 
Here are the suggested guidelines for documents that advance to IS: 
 
http://www.arkko.com/ietf/iesg/discuss-criteria-advancing.txt 
 
Comments appreciated. Please send comments either on this list or to the IESG 
(i...@ietf.org) in time before our next telechat (Thursday, September 8, 2011). 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Conclusion of the last call on draft-housley-two-maturity-levels

[Keith Moore]

On Sep 2, 2011, at 7:07 PM, Ned Freed wrote:

>> As far as our process is concerned, the question is, do we have rough
>> consensus to accept it?  I think it's dubious that we have such consensus, 
>> and
>> apparently so do others.
> 
> Simply put, I've watched the responses to this fairly closely, and I 
> completely
> disagree with your assessment.

ok.

>> Personally I think this proposal is Mostly Harmless, so I'm willing to hold
>> my nose about it.   But I'm very concerned about the argument that the 
>> default
>> assumption should be that we change our process even in the absence of
>> consensus to do so.
> 
>> Regarding the proposal, I get the impression that people are mostly in three
>> camps:
> 
> Well, none of these describe my own position, which is that eliminating the
> three step process will at a minimum act as an incentive to move more 
> documents
> along. (You, and most others engaging in this debate, routinely neglect the
> psychological factors involved.)
> 
> I can easily name a dozen RFCs, all currently at proposed, that I for one will
> be strongly incented to work to advance if this step is taken.

At the risk of playing devil's advocate, how will that help?  Will the 
specifications significantly improve in quality and interoperability improve as 
a result?   Will the blessing of these documents as Internet Standards result 
in wider implementation and thus greater benefit to users?   (not knowing which 
RFCs you're talking about, I can't even guess)

>From my perspective there's little problem with implementing and deploying at 
>Proposed and having documents stay at Proposed indefinitely, provided we can 
>ensure that the specifications are of high quality by the time they get to 
>Proposed.  And given that people do tend to implement and deploy at Proposed, 
>there's only marginal benefit to promoting them to anything else - except on 
>those occasions where this serves as a carrot to fix bugs in the original spec 
>that people might otherwise live with.  And it's not clear to me that the 
>proposed change increases the incentive to do either.

> Additionally, by simplifying the process, we will gain essential insight into
> where other problems lie. Without such simplification I see no chance at all 
> at
> making progress on any of these issues.

Okay, I can see that as a possibility.  Sometimes when undertaking a great 
task, it doesn't matter what subtask you pick to do next, as long as you do 
something.   Momentum is often more important than doing things in order of 
importance.   My question is then, how many people think that we need to 
undertake a great task where our process is concerned, and how many of those 
think that given current political conditions, if we undertake such a task, 
we're likely to end up with something substantially better than we have now?  
(I'm open to the idea but skeptical)

> 
>> 1) Even if this is a baby step, it's a step in the right direction.  Or even
>> if it's not a step in the right direction, taking some step will at least
>> make it possible to make some changes in our process.  Maybe we'll not like
>> the results of taking this step, but at least then we'll have learned
>> something, and if the result is clearly worse we'll be motivated to change 
>> it.
>> (I call this "change for the sake of change")
> 
> That last substantially and obviously mischaracterizes this position. In fact
> I strongly recommend that you stop trying to summarize complex position with
> cute - and utterly wrong - phrases like this. This is annoying and
> quite unhelpful.

There are definitely cases where "a journey of a thousand miles begins with a 
single step", I'm just skeptical that that argument applies in this specific 
case. 

>> 2) Fixing the wrong problem doesn't do anything useful, and will/may serve
>> as a distraction from doing anything useful.
>> (I call this "rearranging the deck chairs")
> 
>> 3) People should stop arguing about this and just hold their noses about it,
>> because the arguing will make it harder to do anything else in this space.
>> (I call this "Oceana has always been at war with Eurasia".  Ok, that's
>> probably too harsh, but it's what immediately comes to mind.)
> 
> Actually, I think there are a substantial numer of people who believe exactly
> the opposite of this.

I'm not sure I understand what you mean here.   Are you saying that there are a 
substantial number of people who wish to make it harder to do anything at all 
in this space, so they keep arguing about it?  Or something else?

>> The arguments that people are giving in favor of approving this bother me
>> more than the proposal itself does.  (I'm a firm believer that good decisions
>> are highly unlikely to result from flawed assumptions, and flawed assumptions
>> often affect many decisions.  So challenging a widely-held flawed assumption 
>> is
>> often more important than challenging any single decision.)
> 
> Well, the main argument I'm giving is

Re: Conclusion of the last call on draft-housley-two-maturity-levels

[Brian E Carpenter]

On 2011-09-03 09:29, Ross Callon wrote:
...
> I think that we should go to a "two maturity level" process, be done with 
> this little step, and also enthusiastically encourage people to write drafts 
> that propose *other* changes to the process. Then at least we can be debating 
> something different 6 months from now than we were debating last year. 

+1. Let's please not hear all over again the arguments that were made during
the *concluded* last call. The consensus is rough; time to move on.

   Brian

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

Re: Conclusion of the last call on draft-housley-two-maturity-levels

[ned+ietf]

First, I'm in full agreement with Ross.



Second, for the record and as a response to Keith, my read of the discussion
on the last call was the biggest group of responses said that we should move
forward with the draft. There were two smaller groups, those with a clear
objection and those with roughly a "no-objection" or "it does not cause harm"
opinion (and a group who seemed to discuss orthogonal issues and not respond to
the question). I could of course have made mistakes in this determination, but
I thought it was rough (perhaps very rough) consensus.


FWIW, this matches my own assessment almost exactly.


Of course, it gets more interesting if you start thinking about the reasons
why people wanted to move forward. Keith's latest e-mail has interesting
theories about those. I don't think anyone thinks this is the priority #1
process fix for the IETF.


Agreed.


For me, cleaning cruft from the IETF process RFCs is a big reason for
supporting this work. And I must admit that we seem to be in a place where its
very, very hard to make _any_ process RFC changes. Getting one done, even if
its a small change would by itself be useful, IMO. Finally, I think two levels
are enough.


Cruft elimination is also a Good Thing.

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

Re: Conclusion of the last call on draft-housley-two-maturity-levels

[ned+ietf]

> On Sep 2, 2011, at 5:36 PM, ned+i...@mauve.mrochek.com wrote:

> >> In looking through this discussion, I see:
> >
> >> - People saying that moving from 3 steps to 2 steps is a small step in the
> >> right direction, lets do it. Many people who have said this (including I) 
> >> have
> >> been silent for a while quite possibly because they have gotten frustrated 
> >> with
> >> the endless discussion.
> >
> > Ross, I'm right there with you. I fully support this document at worse a 
> > small
> > incremental step that clears away the some brush (at best it may actually 
> > turn
> > out to be quite valuable) and I'm completely frustrated that this 
> > discussion is
> > continuing.
> >
> > This really needs to stop now. And yes, some people aren't happy with the
> > outcome. Thems the breaks.

> As far as our process is concerned, the question is, do we have rough
> consensus to accept it?  I think it's dubious that we have such consensus, and
> apparently so do others.

Simply put, I've watched the responses to this fairly closely, and I completely
disagree with your assessment.

> Personally I think this proposal is Mostly Harmless, so I'm willing to hold
> my nose about it.   But I'm very concerned about the argument that the default
> assumption should be that we change our process even in the absence of
> consensus to do so.

> Regarding the proposal, I get the impression that people are mostly in three
> camps:

Well, none of these describe my own position, which is that eliminating the
three step process will at a minimum act as an incentive to move more documents
along. (You, and most others engaging in this debate, routinely neglect the
psychological factors involved.)

I can easily name a dozen RFCs, all currently at proposed, that I for one will
be strongly incented to work to advance if this step is taken. And there isn't
a chance in hell that I'll bother with any of them if this step doesn't happen,
especially after the recent debacle surrounding the attempt to move 4409bis to
full standard, and more generally given how the entire YAM experiment played
out. I'm sorry, but passing down the advancement gauntlet is plenty hard enough
to do once. Requiring it be done twice? Been there, done that, not remotely
interested in doing it again.

Additionally, by simplifying the process, we will gain essential insight into
where other problems lie. Without such simplification I see no chance at all at
making progress on any of these issues.

> 1) Even if this is a baby step, it's a step in the right direction.  Or even
> if it's not a step in the right direction, taking some step will at least
> make it possible to make some changes in our process.  Maybe we'll not like
> the results of taking this step, but at least then we'll have learned
> something, and if the result is clearly worse we'll be motivated to change it.
> (I call this "change for the sake of change")

That last substantially and obviously mischaracterizes this position. In fact
I strongly recommend that you stop trying to summarize complex position with
cute - and utterly wrong - phrases like this. This is annoying and
quite unhelpful.

> 2) Fixing the wrong problem doesn't do anything useful, and will/may serve
> as a distraction from doing anything useful.
> (I call this "rearranging the deck chairs")

> 3) People should stop arguing about this and just hold their noses about it,
> because the arguing will make it harder to do anything else in this space.
> (I call this "Oceana has always been at war with Eurasia".  Ok, that's
> probably too harsh, but it's what immediately comes to mind.)

Actually, I think there are a substantial numer of people who believe exactly
the opposite of this.

> All of these are defensible theories.As it happens, I don't believe #1
> applies in this space, I do believe #2, and I have to admit that #3 does
> happen.

> The arguments that people are giving in favor of approving this bother me
> more than the proposal itself does.  (I'm a firm believer that good decisions
> are highly unlikely to result from flawed assumptions, and flawed assumptions
> often affect many decisions.  So challenging a widely-held flawed assumption 
> is
> often more important than challenging any single decision.)

Well, the main argument I'm giving is based on my own perception of the effect
this will have on myself and similarly minded people as a contributor. If you
think that assessment is incorrect, then I'm sorry, but I think you're being
extraordinarily foolish.

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

RE: Conclusion of the last call on draft-housley-two-maturity-levels

[John C Klensin]

--On Friday, September 02, 2011 14:36 -0700 Ned Freed
 wrote:

>...
> Well, that's the real problem, isn't it? Even if you believe
> this is a distraction and even actively harmful, it's not like
> we've been able to move past it either. The "running code"
> result here seems pretty clear, and it does not argue in favor
> of another round of discussion.

To make one thing clear that I may not have been clear enough
about: I felt a need to respond to Jari's summary.  I did not
want to set off another round of discussion.  I do not think
another round of discussion would be in the least useful: as far
as I can tell, no one who is expressing opinions about whether
or not we should adopt this change now has changed opinions on
that subject (sometimes the reasons stated have changed).  That
doesn't suggest that more discussion would change any minds.

>From that point of view, I believe the _only_ question at this
point, with this process, is whether there is sufficient
consensus that this proposal meets the community's norms for
making process changes.  I've heard all of the following argued
to be those norms for this type of proposal:

(1) No worse than what we have (i.e., no proof that three levels
are better than two)

(2) Likely useless, but the burden is on those who don't like it
to prove that rather than on those who advocate it to
demonstrate its utility.

(3) Possibly useful and harmless at worst.  

(4) Possibly useful but possibly harmful.

(5) Definitely useful and a compelling argument established for
this change.

For the first, I think that consensus probably exists, but I'm
not on the IESG and may not have a correct perspective.  For (2)
- (4), I really don't have a good estimate of how the community
feels: figuring that out is why we pay the IESG the big bucks.
And I don't think anyone has really made a compelling case for
the 5th.  YMMV.

And, fwiw, I think it would be a pity to prolong this discussion
by debating those categories, either as to whether they are the
correct categories or as to which one we should be using.  To
paraphrase a recent note from Russ, if someone feels a need to
do that, at least start another thread.

john

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

Re: Conclusion of the last call on draft-housley-two-maturity-levels

[Barry Leiba]

I'm in the group that likes this document, thinks it will help us move
forward, and thinks we should stop babbling and just do it.

That said, I have a issue with what Ross says:

> Two things that I don't seem to have picked up on: (i) Any consensus that a 3 
> step
> process is better than a 2 step process; (ii) Any hint of moving towards an 
> agreement
> on other things that we might do to improve the process.

The issue is that we aren't looking for consensus that what we have is
better than what's being proposed.  What we're looking for is
consensus that what's being proposed is better than what we have.
That is, a proposal for change needs to establish consensus FOR THE
CHANGE, not the other way around.

It's up to Jari and the rest of the IESG to determine whether we have
that rough consensus.  I'm not sure.  In numbers, we seem to -- it's
mostly a vocal few who are urging us not to do it.  The thing is that,
as we know, rough consensus isn't just a numbers game, and one or two
reasonable minority arguments can derail things.

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

Re: Conclusion of the last call on draft-housley-two-maturity-levels

[Keith Moore]

My main conclusion for the moment is that Last Call comments should indicate 
first of all a definite Support or Oppose for the decision at hand if they are 
to be counted for or against consensus.

I'm not going to state a position, which means that you should not count me as 
either for or against the proposal.

Keith


On Sep 2, 2011, at 6:31 PM, Jari Arkko wrote:

> First, I'm in full agreement with Ross.
> 
> Second, for the record and as a response to Keith, my read of the discussion 
> on the last call was the biggest group of responses said that we should move 
> forward with the draft. There were two smaller groups, those with a clear 
> objection and those with roughly a "no-objection" or "it does not cause harm" 
> opinion (and a group who seemed to discuss orthogonal issues and not respond 
> to the question). I could of course have made mistakes in this determination, 
> but I thought it was rough (perhaps very rough) consensus.
> 
> Of course, it gets more interesting if you start thinking about the reasons 
> why people wanted to move forward. Keith's latest e-mail has interesting 
> theories about those. I don't think anyone thinks this is the priority #1 
> process fix for the IETF. For me, cleaning cruft from the IETF process RFCs 
> is a big reason for supporting this work. And I must admit that we seem to be 
> in a place where its very, very hard to make _any_ process RFC changes. 
> Getting one done, even if its a small change would by itself be useful, IMO. 
> Finally, I think two levels are enough.
> 
> Jari
> 
> On 03.09.2011 00:34, Keith Moore wrote:
>> (iii) Any consensus that a 2 step process is better than a 3 step process.
>> 
> 

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

Re: Conclusion of the last call on draft-housley-two-maturity-levels

[Jari Arkko]

First, I'm in full agreement with Ross.

Second, for the record and as a response to Keith, my read of the discussion on the last call was 
the biggest group of responses said that we should move forward with the draft. There were two 
smaller groups, those with a clear objection and those with roughly a "no-objection" or 
"it does not cause harm" opinion (and a group who seemed to discuss orthogonal issues and 
not respond to the question). I could of course have made mistakes in this determination, but I 
thought it was rough (perhaps very rough) consensus.

Of course, it gets more interesting if you start thinking about the reasons why 
people wanted to move forward. Keith's latest e-mail has interesting theories 
about those. I don't think anyone thinks this is the priority #1 process fix 
for the IETF. For me, cleaning cruft from the IETF process RFCs is a big reason 
for supporting this work. And I must admit that we seem to be in a place where 
its very, very hard to make _any_ process RFC changes. Getting one done, even 
if its a small change would by itself be useful, IMO. Finally, I think two 
levels are enough.

Jari

On 03.09.2011 00:34, Keith Moore wrote:

(iii) Any consensus that a 2 step process is better than a 3 step process.



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

Re: [websec] Last Call: (The Web Origin Concept) to Proposed Standard

[Frank Ellermann]

On 2 September 2011 23:15, Roy T. Fielding wrote:

>> this is still "avoid *any* folding", and not "avoid more
>> than one folding".

> That is the intention.  There is no reason to fold in HTTP
> outside of the message/http media type.

As a result you get an intentional difference from 
in messages, because HTTP has no line length limit.  This
 is about "insane" foldings, and your  is
about "unnecessary or insane" foldings.

I'm not sure that a sound but unnecessary folding is really
always a bad idea, e.g., I don't use programming languages
with a hardwired maximal string length, where "unnecessary"
could turn out to be "rarely almost required".

Still only "JFTR", if you are sure that this is precisely as
you want it stick to it.  The more spectacular examples with
"syntactically valid ASCII art consisting of commas" will be
obsoleted by , while  alone only tackles
the dangerous "apparently empty" lines -- but IIRC RFC 5322
also did something else about ASCII art.

>> I wonder why you don't demote HTAB generally to "obsolete"
>> in OWS.

> We already state that a single SP is preferred.

Two SHOULDs in the prose before the syntax.  If you move HTAB
to obs-fold = HTAB / ( CRLF (HTAB / SP)) and then rename this
to  it would more closely match the prose, "whatever
you do with one or even more than one SP, stay away from HTAB
and CRLF".

> That said, I'd also agree with Julian's suggestion that it
> is better to just define the field-value in ABNF and leave
> the rest to HTTP.

Yes, the Origin I-D shouldn't define any  if that is not
guaranteed to be precisely the same as in the future HTTPbis.

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

Re: Conclusion of the last call on draft-housley-two-maturity-levels

[Keith Moore]

On Sep 2, 2011, at 5:36 PM, ned+i...@mauve.mrochek.com wrote:

>> In looking through this discussion, I see:
> 
>> - People saying that moving from 3 steps to 2 steps is a small step in the
>> right direction, lets do it. Many people who have said this (including I) 
>> have
>> been silent for a while quite possibly because they have gotten frustrated 
>> with
>> the endless discussion.
> 
> Ross, I'm right there with you. I fully support this document at worse a small
> incremental step that clears away the some brush (at best it may actually turn
> out to be quite valuable) and I'm completely frustrated that this discussion 
> is
> continuing.
> 
> This really needs to stop now. And yes, some people aren't happy with the
> outcome. Thems the breaks.

As far as our process is concerned, the question is, do we have rough consensus 
to accept it?  I think it's dubious that we have such consensus, and apparently 
so do others.   

Personally I think this proposal is Mostly Harmless, so I'm willing to hold my 
nose about it.   But I'm very concerned about the argument that the default 
assumption should be that we change our process even in the absence of 
consensus to do so.   

Regarding the proposal, I get the impression that people are mostly in three 
camps:

1) Even if this is a baby step, it's a step in the right direction.  Or even if 
it's not a step in the right direction, taking some step will at least make it 
possible to make some changes in our process.  Maybe we'll not like the results 
of taking this step, but at least then we'll have learned something, and if the 
result is clearly worse we'll be motivated to change it.  
(I call this "change for the sake of change")

2) Fixing the wrong problem doesn't do anything useful, and will/may serve as a 
distraction from doing anything useful.  
(I call this "rearranging the deck chairs")

3) People should stop arguing about this and just hold their noses about it, 
because the arguing will make it harder to do anything else in this space.  
(I call this "Oceana has always been at war with Eurasia".  Ok, that's probably 
too harsh, but it's what immediately comes to mind.)

All of these are defensible theories.As it happens, I don't believe #1 
applies in this space, I do believe #2, and I have to admit that #3 does 
happen.  

The arguments that people are giving in favor of approving this bother me more 
than the proposal itself does.  (I'm a firm believer that good decisions are 
highly unlikely to result from flawed assumptions, and flawed assumptions often 
affect many decisions.  So challenging a widely-held flawed assumption is often 
more important than challenging any single decision.)

The core problem, I suspect, is that we don't really have any consensus on what 
IETF's role is.   Is it to help ensure that the Internet works well?  Or is it 
to enable vendors to ship products that use new/updated protocols as quickly as 
possible?  These two aren't diametrically opposed, but there's a fair amount of 
tension between them.

Keith

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

Other proposals (Was: :Re: Conclusion of the last call on draft-housley-two-maturity-levels)

[Jari Arkko]

SM,


The Sponsoring Area Director mentioned that the opposing opinions were more 
about a desire to do something else than specific objections about this 
proposal.  An Area Director generally sponsors documents that he or she 
believes in.  I would like to point out that even if a desire to do something 
else was tabled as a proposal, my perception is that it would be difficult to 
have such a proposal sponsored by the relevant Area Director.


I already responded to Scott, clarifying what I had said about the objections.

But what I really wanted to say here was a response to your concern about those 
proposals to do something else. Let me just state this clearly. I know I would 
be VERY happy to sponsor many different kinds of improvement proposals. In 
sequence or in parallel with the current proposal. I'm already sponsoring 
another one (though it is destined to an IESG statement and somewhat related to 
this one, but it could have been something else too). I think I'm speaking also 
for the rest of the IESG in this. Please make the proposals.

Of course, this does not mean that I would sponsor anything -- I do have to 
believe in it, I do have to think it has a reasonable chance of success. And 
I'm not too eager to take draft-grand-unified-theory-of-ietf-process-00.txt 
while everything else has to sit still. But if you have been sending e-mail to 
the list that we should not waste our time with Russ' draft and that we should 
do something else instead -- here's an idea. Send that something to us, and 
we'll get it done! Simple, no?

Jari

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

RE: Conclusion of the last call on draft-housley-two-maturity-levels

[James M. Polk]

At 04:29 PM 9/2/2011, Ross Callon wrote:

In looking through this discussion, I see:

 - People saying that moving from 3 steps to 2 steps is a small 
step in the right direction, lets do it. Many people who have said 
this (including I) have been silent for a while quite possibly 
because they have gotten frustrated with the endless discussion.


I think there are many that have voiced their frustrations that this 
draft isn't addressing the more important issue (or issues) in their 
minds. I don't see a consensus on what that 1 issue is, but many 
(including I) have said it's the problem of such a high hurdle to get 
a draft to PS. Because this draft isn't addressing that problem, I'm 
frustrated with this draft - because - I don't know that if this 
draft were to RFC that the high hurdle for PSs is the next thing tackled.


OTOH, if the high hurdle for PSs were what we worked on initially, 
and solve it, then I'd probably be much more comfortable with this 
draft progressing (then having started to appreciate what this means 
as a second step where getting a draft to PS is the first step).


just my opinion

James


 - People saying that there are other more important problems that 
we should be focusing on. Therefore, rather than either making this 
simple change or discussing other possible improvements in the 
process, instead let's debate this simple step forever and never 
get anything done.


 - People saying that this step won't do anything.

Two things that I don't seem to have picked up on: (i) Any consensus 
that a 3 step process is better than a 2 step process; (ii) Any hint 
of moving towards an agreement on other things that we might do to 
improve the process.


I think that we should go to a "two maturity level" process, be done 
with this little step, and also enthusiastically encourage people to 
write drafts that propose *other* changes to the process. Then at 
least we can be debating something different 6 months from now than 
we were debating last year.


Ross

-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf 
Of John C Klensin

Sent: Friday, September 02, 2011 4:20 PM
To: Jari Arkko
Cc: ietf@ietf.org
Subject: Re: Conclusion of the last call on draft-housley-two-maturity-levels



--On Tuesday, August 30, 2011 23:17 +0300 Jari Arkko
 wrote:

> I have reviewed the discussion from the last call on this
> document.
>
> My conclusion as the sponsoring AD is that we have consensus
> to move forward. There was clearly a constituency who believed
> this is a good (albeit small) step forward. A number of other
> people did not care so much; did not believe there was either
> harm or benefit. I also saw a couple of opposing opinions,
> though some of them were more about a desire to do something
> else than specific objections about this proposal. I will be
> recommending that the IESG approve the draft.

Jari,

Like Scott, I wonder if there is some misunderstanding here.
Part of the problem is the way that this draft was developed and
the discussion has been handled, despite your heroic efforts.
For example:

(1) If someone says "we should be looking in this different
direction instead", the response has been "irrelevant to
consideration to this proposal, so it should go forward".  The
irrelevancy is debatable, but that may be another issue.

(2) If someone says "the proposal claims to solve problem X, but
there is no evidence for that", the assertion about what
problems are being solved is removed, but there is no
substantive change to the draft.

(3) If someone says "this solves no problem", the response has
been that things have been broken for years and therefore this
proposal should be approved.   (The difficulty with that logic
should be clear.)  Sometimes that has been accompanied by a
claim that it is the only proposal on the table and should
therefore be adopted (even though that statement isn't true and,
true or not, would never even be considered if we were
considering a protocol specification).  One of the co-authors
has recently argued for a very high standard of compelling
necessity to make changes to important processes or related
documents, but that criterion obviously does not apply to this
document.

(4) There have been a few arguments made that making this sort
of change --without compelling justification and without
evidence that it would accomplish anything-- would actually be
harmful.  There has been no substantive response to those
arguments.   In normal Last Calls, such comments are known as
"unresolved issues" and the sponsoring AD does not move the
document forward until they are addressed (or even dismissed) in
some substantive way.

(5) This is probably off-topic unless someone decides to appeal,
but, to a certain extent, the processing of this document points
out a far more significant problem with the handling of process
change suggestions in the IETF.  The IESG holds a discussion.
An IESG member prepares a draft.

Re: Conclusion of the last call on draft-housley-two-maturity-levels

[Jari Arkko]

for the record in case Jari is confused - I have specific objection to this 
proposal



I might well be, it would not be a surprise :-) but let me just clarify that I 
said that there were objections, *some* of which were not specific. Not all.

Jari

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

RE: Conclusion of the last call on draft-housley-two-maturity-levels

[ned+ietf]

> In looking through this discussion, I see:

>  - People saying that moving from 3 steps to 2 steps is a small step in the
> right direction, lets do it. Many people who have said this (including I) have
> been silent for a while quite possibly because they have gotten frustrated 
> with
> the endless discussion.

Ross, I'm right there with you. I fully support this document at worse a small
incremental step that clears away the some brush (at best it may actually turn
out to be quite valuable) and I'm completely frustrated that this discussion is
continuing.

This really needs to stop now. And yes, some people aren't happy with the
outcome. Thems the breaks.

>  - People saying that there are other more important problems that we should
> be focusing on. Therefore, rather than either making this simple change or
> discussing other possible improvements in the process, instead let's debate
> this simple step forever and never get anything done.

At least part of the problem is lack of agreement on what the issues are. Even
if this step is a waste of time - I think that's unlikely but let's suppose - 
at least it will make it clear where the problems *aren't*. 

>  - People saying that this step won't do anything.

> Two things that I don't seem to have picked up on: (i) Any consensus that a 3
> step process is better than a 2 step process; (ii) Any hint of moving towards
> an agreement on other things that we might do to improve the process.

Well, that's the real problem, isn't it? Even if you believe this is a
distraction and even actively harmful, it's not like we've been able to move
past it either. The "running code" result here seems pretty clear, and it does
not argue in favor of another round of discussion.

> I think that we should go to a "two maturity level" process, be done with
> this little step, and also enthusiastically encourage people to write drafts
> that propose *other* changes to the process. Then at least we can be debating
> something different 6 months from now than we were debating last year.

+100

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

Re: Conclusion of the last call on draft-housley-two-maturity-levels

[Keith Moore]

On Sep 2, 2011, at 5:29 PM, Ross Callon wrote:

> Two things that I don't seem to have picked up on: (i) Any consensus that a 3 
> step process is better than a 2 step process; (ii) Any hint of moving towards 
> an agreement on other things that we might do to improve the process. 

(iii) Any consensus that a 2 step process is better than a 3 step process.


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

RE: Conclusion of the last call on draft-housley-two-maturity-levels

[Ross Callon]

In looking through this discussion, I see:

 - People saying that moving from 3 steps to 2 steps is a small step in the 
right direction, lets do it. Many people who have said this (including I) have 
been silent for a while quite possibly because they have gotten frustrated with 
the endless discussion. 

 - People saying that there are other more important problems that we should be 
focusing on. Therefore, rather than either making this simple change or 
discussing other possible improvements in the process, instead let's debate 
this simple step forever and never get anything done. 

 - People saying that this step won't do anything. 

Two things that I don't seem to have picked up on: (i) Any consensus that a 3 
step process is better than a 2 step process; (ii) Any hint of moving towards 
an agreement on other things that we might do to improve the process. 

I think that we should go to a "two maturity level" process, be done with this 
little step, and also enthusiastically encourage people to write drafts that 
propose *other* changes to the process. Then at least we can be debating 
something different 6 months from now than we were debating last year. 

Ross

-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John C 
Klensin
Sent: Friday, September 02, 2011 4:20 PM
To: Jari Arkko
Cc: ietf@ietf.org
Subject: Re: Conclusion of the last call on draft-housley-two-maturity-levels



--On Tuesday, August 30, 2011 23:17 +0300 Jari Arkko
 wrote:

> I have reviewed the discussion from the last call on this
> document.
> 
> My conclusion as the sponsoring AD is that we have consensus
> to move forward. There was clearly a constituency who believed
> this is a good (albeit small) step forward. A number of other
> people did not care so much; did not believe there was either
> harm or benefit. I also saw a couple of opposing opinions,
> though some of them were more about a desire to do something
> else than specific objections about this proposal. I will be
> recommending that the IESG approve the draft.

Jari,

Like Scott, I wonder if there is some misunderstanding here.
Part of the problem is the way that this draft was developed and
the discussion has been handled, despite your heroic efforts.
For example:

(1) If someone says "we should be looking in this different
direction instead", the response has been "irrelevant to
consideration to this proposal, so it should go forward".  The
irrelevancy is debatable, but that may be another issue.

(2) If someone says "the proposal claims to solve problem X, but
there is no evidence for that", the assertion about what
problems are being solved is removed, but there is no
substantive change to the draft.

(3) If someone says "this solves no problem", the response has
been that things have been broken for years and therefore this
proposal should be approved.   (The difficulty with that logic
should be clear.)  Sometimes that has been accompanied by a
claim that it is the only proposal on the table and should
therefore be adopted (even though that statement isn't true and,
true or not, would never even be considered if we were
considering a protocol specification).  One of the co-authors
has recently argued for a very high standard of compelling
necessity to make changes to important processes or related
documents, but that criterion obviously does not apply to this
document.

(4) There have been a few arguments made that making this sort
of change --without compelling justification and without
evidence that it would accomplish anything-- would actually be
harmful.  There has been no substantive response to those
arguments.   In normal Last Calls, such comments are known as
"unresolved issues" and the sponsoring AD does not move the
document forward until they are addressed (or even dismissed) in
some substantive way.

(5) This is probably off-topic unless someone decides to appeal,
but, to a certain extent, the processing of this document points
out a far more significant problem with the handling of process
change suggestions in the IETF.  The IESG holds a discussion.
An IESG member prepares a draft.  An IESG member (the same one
or a different one - it makes a difference, but not much)
decides what other process change proposals can be considered
(either at the same time or otherwise).  While the IESG would
normally decide that anything that has produced this much
controversy needs a Working Group to consider alternatives and
get a real consensus determination, the IESG decides that no WG
will be considered for this work (the claim that previous WGs
addressed to process issues have been a problem --one with which
I personally agree-- may not be relevant unless the IESG is
ready to consider other review and mechanisms).   The IESG gets
to pick and choose which arguments for and against the proposal
"count" -- normal, but see (4) above and the many "solves no
problem" comments.  And then the IESG decides to advance t

Re: [websec] Last Call: (The Web Origin Concept) to Proposed Standard

[Roy T. Fielding]

On Sep 2, 2011, at 1:19 PM, Frank Ellermann wrote:

> On 2 September 2011 21:38, Roy T. Fielding wrote:
> 
> [http-bis]
>>   OWS= *( HTAB / SP / obs-fold )
>>; "optional" whitespace
>>   obs-fold   = CRLF ( HTAB / SP )
>>; obsolete line folding
> 
> Clearer.  JFTR, this is still "avoid *any* folding", and not
> "avoid more than one folding".

That is the intention.  There is no reason to fold in HTTP
outside of the message/http media type.

>  And if you like...
> 
>>   origin  = "Origin:" [ SP ] origin-list-or-null
> 
> ...I wonder why you don't demote HTAB generally to "obsolete"
> in OWS.

We already state that a single SP is preferred.

> Or why you don't propose *WSP instead of [SP] in the
> Origin header field.

Because a single SP is preferred.  This is a new header field.

> It would be odd if the overall HTTPbis
> rules and the specific Origin header field have different
> ideas about "optional white space" (modulo , i.e.,
> eliminating  in a new header field Origin is fine).

The overall field parsing rules for HTTPbis are for recipients.
These things are parsed in general, and so it only matters that
the generative grammar for origin matches one of the choices
allowed by the parsing grammar in HTTPbis.

> One optional SP is not the same as zero or more ( HTAB / SP ).

It is if you only send the preferred format.  That said, I'd also
agree with Julian's suggestion that it is better to just define
the field-value in ABNF and leave the rest to HTTP.

Roy

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

Re: Conclusion of the last call on draft-housley-two-maturity-levels

[Frank Ellermann]

On 2 September 2011 22:20, John C Klensin wrote:

> I simply don't know how those who are not speaking up feel

https://profiles.google.com/103449397114700758824/posts/1KALM7oLKzi
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Conclusion of the last call on draft-housley-two-maturity-levels

[Keith Moore]

Honestly, the thing that is the most broken about this draft is the idea that 
there's something wrong with our process because few drafts make it to full 
standard, so the solution is to short-circuit the process.  The transition from 
Draft to Full Standard is the least of the problems with our process.  And the 
sooner we stop trying to fix irrelevancies, the better.

Keith

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

Re: Conclusion of the last call on draft-housley-two-maturity-levels

[John C Klensin]

--On Tuesday, August 30, 2011 23:17 +0300 Jari Arkko
 wrote:

> I have reviewed the discussion from the last call on this
> document.
> 
> My conclusion as the sponsoring AD is that we have consensus
> to move forward. There was clearly a constituency who believed
> this is a good (albeit small) step forward. A number of other
> people did not care so much; did not believe there was either
> harm or benefit. I also saw a couple of opposing opinions,
> though some of them were more about a desire to do something
> else than specific objections about this proposal. I will be
> recommending that the IESG approve the draft.

Jari,

Like Scott, I wonder if there is some misunderstanding here.
Part of the problem is the way that this draft was developed and
the discussion has been handled, despite your heroic efforts.
For example:

(1) If someone says "we should be looking in this different
direction instead", the response has been "irrelevant to
consideration to this proposal, so it should go forward".  The
irrelevancy is debatable, but that may be another issue.

(2) If someone says "the proposal claims to solve problem X, but
there is no evidence for that", the assertion about what
problems are being solved is removed, but there is no
substantive change to the draft.

(3) If someone says "this solves no problem", the response has
been that things have been broken for years and therefore this
proposal should be approved.   (The difficulty with that logic
should be clear.)  Sometimes that has been accompanied by a
claim that it is the only proposal on the table and should
therefore be adopted (even though that statement isn't true and,
true or not, would never even be considered if we were
considering a protocol specification).  One of the co-authors
has recently argued for a very high standard of compelling
necessity to make changes to important processes or related
documents, but that criterion obviously does not apply to this
document.

(4) There have been a few arguments made that making this sort
of change --without compelling justification and without
evidence that it would accomplish anything-- would actually be
harmful.  There has been no substantive response to those
arguments.   In normal Last Calls, such comments are known as
"unresolved issues" and the sponsoring AD does not move the
document forward until they are addressed (or even dismissed) in
some substantive way.

(5) This is probably off-topic unless someone decides to appeal,
but, to a certain extent, the processing of this document points
out a far more significant problem with the handling of process
change suggestions in the IETF.  The IESG holds a discussion.
An IESG member prepares a draft.  An IESG member (the same one
or a different one - it makes a difference, but not much)
decides what other process change proposals can be considered
(either at the same time or otherwise).  While the IESG would
normally decide that anything that has produced this much
controversy needs a Working Group to consider alternatives and
get a real consensus determination, the IESG decides that no WG
will be considered for this work (the claim that previous WGs
addressed to process issues have been a problem --one with which
I personally agree-- may not be relevant unless the IESG is
ready to consider other review and mechanisms).   The IESG gets
to pick and choose which arguments for and against the proposal
"count" -- normal, but see (4) above and the many "solves no
problem" comments.  And then the IESG decides to advance the
document.

(6) Unfortunately, although the document has improved
significantly since -00 --by removing material for which there
was little or no support and some question about relevance and
by removing unsupportable claims-- the basic pattern outlined in
(5) has been perceived as inevitable, i.e., that this
AD-produced draft, produces in response to a discussion and
conclusion already reached by the IESG, was going to go through
because the IESG had prejudged the ultimate outcome before the
draft was written.  Whether that perception is correct or not,
it leads all but the most persistent members of the community to
tune out and stop making comments, either early on or after
several rounds.   I am not going to take a position about
consensus among some silent majority because I simply don't know
how those who are not speaking up feel, but I think the
community should exercise caution about the possibility of
consensus-by-exhaustion in any discussion that has dragged on as
long as this document and its predecessors have been debated on
the IETF list.

regards,
john



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

Re: [websec] Last Call: (The Web Origin Concept) to Proposed Standard

[Frank Ellermann]

On 2 September 2011 21:38, Roy T. Fielding wrote:

 [http-bis]
>   OWS            = *( HTAB / SP / obs-fold )
>                    ; "optional" whitespace
>   obs-fold       = CRLF ( HTAB / SP )
>                    ; obsolete line folding

Clearer.  JFTR, this is still "avoid *any* folding", and not
"avoid more than one folding".  And if you like...

>   origin              = "Origin:" [ SP ] origin-list-or-null

...I wonder why you don't demote HTAB generally to "obsolete"
in OWS.  Or why you don't propose *WSP instead of [SP] in the
Origin header field.  It would be odd if the overall HTTPbis
rules and the specific Origin header field have different
ideas about "optional white space" (modulo , i.e.,
eliminating  in a new header field Origin is fine).

One optional SP is not the same as zero or more ( HTAB / SP ).

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

Re: [websec] Last Call: (The Web Origin Concept) to Proposed Standard

[Roy T. Fielding]

On Aug 23, 2011, at 2:19 PM, The IESG wrote:

> The IESG has received a request from the Web Security WG (websec) to
> consider the following document:
> - 'The Web Origin Concept'
>   as a Proposed Standard

Sec 2.2: the definition of OWS includes a mistake that I just fixed in httpbis.

   OWS= *( [ obs-fold ] WSP )
; "optional" whitespace
   obs-fold   = CRLF

should be

   OWS= *( HTAB / SP / obs-fold )
; "optional" whitespace
   obs-fold   = CRLF ( HTAB / SP )
; obsolete line folding

The problem isn't in OWS itself -- the above are equivalent.
It is the definition of obs-fold that is wrong because it stands
for the obsolete line folding allowed by RFC2616 (RFC822, etc.).
A CRLF alone is not an obs-fold, so optimizing the ABNF in that
way was wrong in httpbis.  Likewise, I recommend replacing WSP with
its equivalent ( HTAB / SP ) because the name is misleading and
is only used in this one section.

OTOH, perhaps a simpler change is in order.  The above definitions
are only used once in the document (Section 7.1).  Furthermore,
since we are defining a new header field (and not all header fields),
we can be more proscriptive in 7.1 and remove the section above.

In 7.1, instead of

   origin  = "Origin:" OWS origin-list-or-null OWS

define it as

   origin  = "Origin:" [ SP ] origin-list-or-null

and then most of 2.2 can be removed.


Sec 8: typo:  s/those model /those models /


Otherwise, the spec looks good.


Cheers,

Roy T. Fielding 
Principal Scientist, Adobe Systems  


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

Re: Conclusion of the last call on draft-housley-two-maturity-levels

[Scott O. Bradner]

Jari Arkko sed

> I also saw a couple of opposing opinions, though some of them were more about 
> a desire to do something else
> than specific objections about this proposal.


for the record in case Jari is confused - I have specific objection to this 
proposal

imo - it fixes no known problem - it only adds additional fuzz to a surface 
understanding of what 
causes few RFCs to be advanced on the standards track - I see no reason to 
think that
this proposal will have any significant effect on that problem (nor any 
insignificant effect)

Scott


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

Re: Conclusion of the last call on draft-housley-two-maturity-levels

[SM]

At 13:17 30-08-2011, Jari Arkko wrote:
There were a number of smaller details raised in the discussion. But 
I did not see an overwhelming consensus on any specific issue to 
make changes. But I will ask Russ to take a look at the issue raised 
by Scott, whether he wants to add an informative reference to RFC 5657.


I read draft-housley-two-maturity-levels-09.  I read the messages 
which might be interpreted as statements of support.  Mr Burger 
offered that we are moving a baby step forward.   Mr Resnick asked "A 
baby step toward what exactly" to which Mr Saint-Andre pointed out 
that "we are more closely aligning our documentation with our 
organizational running code".  The organizational running code 
actually sets a higher bar than what is documented in RFC 2026 for 
the publication of a Proposed Standard.  The draft does not even 
discuss about that.


Mr Carpenter believes that "the present situation is confusing both 
to IETF newcomers (who may falsely believe that the IETF actually 
follows the 3 stage process) and, worse, confusing to users of IETF 
standards (who may falsely believe that a document isn't useful until 
it's advanced). We, and those users, gain by reducing the 
confusion".  In terms of document clarity, RFC 2026 taken together 
with draft-housley-two-maturity-levels-09 only reinforces the 
confusion for anyone who takes the time to read BCP 9.


Mr Atkinson pointed out that a change in perception alone is 
sufficient to increase [his] own motivation.  Mr Burger confirmed 
that the intent of the proposal is to change the perception.


Mr Halpern mentioned that the draft tries to align what we document 
with what we do.  In a response, Mr Klensin mentioned that the draft 
addresses one provision of our processes in which documentation and 
practice don't align, a provision about which there is no subtlety or 
confusion within the community at all (even though new participants 
may be confused)".


Mr Housley in response to one of my comments mentioned that the 
argument I raised was for the status quo and added that "We have 
decades of experience with that not working.  That is essentially an 
argument for a single maturity level; that is how the process is 
really working today".  As a note to the reader, I may have quoted Mr 
Housley out of context.  I presume that members of the IESG have 
followed the discussions surrounding this draft to understand the context.


The Sponsoring Area Director mentioned that the opposing opinions 
were more about a desire to do something else than specific 
objections about this proposal.  An Area Director generally sponsors 
documents that he or she believes in.  I would like to point out that 
even if a desire to do something else was tabled as a proposal, my 
perception is that it would be difficult to have such a proposal 
sponsored by the relevant Area Director.


Mr Crocker and Mr Housley are listed as authors of STD 71 and STD 70 
respectively.  It would be informative if they could comment on the 
impediments they came across in advancing their documents to Full 
Standard.  Mr Gellens and Mr Klensin might also be able to comment on 
the impediments given that they are listed as the authors of a soon 
to be published STD.


Regards,
-sm 


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

Re: 2119bis

[Hector]

I take a offense to your blabbing which just puts people on the defensive.

The fact is, your are incorrect in your continue personalization. The 
topic includes examples of problems where this RFC2119Bis enforcement 
is being sort, which quite frankly, you have been very much been part 
of that push. I do understand why you want everyone to upgrade their 
software to meet your needs, but you seem to lack the understanding 
that you just can't do it the way you want to, hence why there are 
delays in your publication, and DKIM is still an accident waiting to 
happen.


Ciao

Murray S. Kucherawy wrote:

-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Hector
Sent: Thursday, September 01, 2011 5:56 PM
To: Michael StJohns
Cc: IETF Discussion
Subject: Re: 2119bis

Good points, but the subtleties are too wide spread to generalize,
especially dealing with integrated protocols and now there are
boundary layers related issues.

For example:

DKIM MUST|SHOULD|MAY validate its input stream for illegal
multiple 8222.From fields because this has been shown to cause
a potential security exploit.

[...]


So this protracted (and, in my view, hijacked) sound-and-fury thread about 
concerns with interpretation of RFC2119 and the rough consensus process, and 
hints about an activist Area Director, is really just a platform to vent your 
frustration with a decision made in a working group where you were in the 
minority?

The issue to which you're referring closed months ago.  After a long battle, 
some compromise text was reached that included some of what you advocated, 
which during IESG evaluation drew a DISCUSS and it was rolled back before being 
approved for publication.  This is all recorded in the archives.

It really is time to move on.

___
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: 2119bis

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Hector
> Sent: Thursday, September 01, 2011 5:56 PM
> To: Michael StJohns
> Cc: IETF Discussion
> Subject: Re: 2119bis
> 
> Good points, but the subtleties are too wide spread to generalize,
> especially dealing with integrated protocols and now there are
> boundary layers related issues.
> 
> For example:
> 
> DKIM MUST|SHOULD|MAY validate its input stream for illegal
> multiple 8222.From fields because this has been shown to cause
> a potential security exploit.
> 
> [...]

So this protracted (and, in my view, hijacked) sound-and-fury thread about 
concerns with interpretation of RFC2119 and the rough consensus process, and 
hints about an activist Area Director, is really just a platform to vent your 
frustration with a decision made in a working group where you were in the 
minority?

The issue to which you're referring closed months ago.  After a long battle, 
some compromise text was reached that included some of what you advocated, 
which during IESG evaluation drew a DISCUSS and it was rolled back before being 
approved for publication.  This is all recorded in the archives.

It really is time to move on.

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

RE: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

[Alexander Vainshtein]

Matthew,
Lots of thanks for a prompt response.

Please see a couple of comments inline below.

Regards,
 Sasha


From: Bocci, Matthew (Matthew) [matthew.bo...@alcatel-lucent.com]
Sent: Friday, September 02, 2011 1:06 PM
To: Alexander Vainshtein; Stewart Bryant
Cc: Yaakov Stein; m...@ietf.org; pwe3; i...@ietf.org; 
pwe3-cha...@tools.ietf.org; Luca Martini; IETF Discussion
Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

Sasha,

On your final comment on the concept of an MPLS-TP PW, RFC5586 has already made 
the distinction between the use of the GAL on PWs in MPLS-TP and in other MPLS 
environments. This draft aligns the two cases in terms of the applicability of 
the GAL, by updating RFC5586 to remove the restriction on its use and position 
in an MPLS-TP environment.

[[Sasha]] IMHO and FWIW this is one more indication that there is no such thing 
as an MPLS-TP PW as different from an MPLS TP. Did I miss something important?


The case of interconnecting PW segments on MPLS-TP to PW segments on general 
MPLS networks should be discussed elsewhere, IMHO, as the interaction between 
the GAL and hashing on some PW segments is most likely not the only issue.

[[Sasha]] Sounds OK with me.

RFC5921 rules out the use of ECMP in MPLS-TP networks, so one would not expect 
an MPLS-TP PSN to hash the flow label today.

[[Sasha]] I make a distinction between inserting a flow label at T-PE and 
hashing on the label stack (or lack thereof) in some of the network domains 
that are crossed by the MS-PW packet. The hashing is done (or not done) by P 
routers that do not specifically care about PWs.

If that is going to change or if there are other flow label applications in 
MPLS-TP, then IMHO drafts detailing those applications should discuss the 
interaction with the GAL.

[[Sasha]] Please see above. IMHO there is no need for a new application to 
study the interaction.

Regards,

Matthew

On 02/09/2011 06:05, "Alexander Vainshtein" 
mailto:alexander.vainsht...@ecitele.com>> 
wrote:

Stewart,
Lots of thanks for a prompt response.

My original email contained a typo (S-PE instead of T-PE  named as inserting ) 
which I've acknowledged and corrected in this thread (please see 
http://www.ietf.org/mail-archive/web/pwe3/current/msg12586.html).

With this correction in mind, the example I've presented (an MS-PW that 
originates in a T-PE in a MPLS-TP domain and them crosses - at S-PE - into an 
IP/MPLS domain) matches, IMHO, Yaakov's question. And if the operator wishes to 
improve traffic distribution in the IP/MPLS domain which employs ECMP, flow 
labels would be inserted by T-PE.

I believe that the change in draft-ietf-pwe3-gal-in-pw that you've proposed 
inhttp://www.ietf.org/mail-archive/web/pwe3/current/msg12613.html resolves the 
original issue I've raised of both GAL and flow label "competing" for the BoS 
position.

However, a conceptual question - can any MPLS-TP restrictions be placed on 
PWs?- remains open as noted in Greg's comment (please see 
http://www.ietf.org/mail-archive/web/pwe3/current/msg12620.html). IMHO and FWIW 
we should acknowledge the fact (implicitly recognized  already in RFC 5920) 
that there is simply no such thing as a MPLS-TP PW.

Hopefully this note clarifies my position on the subject.

Regards, and apologies for the original typo,
 Sasha


From: Stewart Bryant [stbry...@cisco.com]
Sent: Thursday, September 01, 2011 8:33 PM
To: Alexander Vainshtein
Cc: Yaakov Stein; m...@ietf.org; pwe3; 
i...@ietf.org; 
pwe3-cha...@tools.ietf.org; Luca Martini; 
IETF Discussion
Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw


On 01/09/2011 17:07, Alexander Vainshtein wrote:
Yaakov,
You've written
PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain
This is exactly the point that I've raised in my IETF LC comment on the draft 
(for MS-PW) - please see my email (to several lists) that explains that in some 
detail, at http://www.ietf.org/mail-archive/web/pwe3/current/msg12581.html.

Regards,
Sasha

The operator intends to improve traffic distribution in the IP/MPLS domain, 
hence he enables insertion and discard of "flow labels" at the two S-PEs.

Speaking as an author of the FAT-PW draft I do not recall any text that 
proposes that S-PEs insert FLs in the stack, and it never occurred to me that 
anyone anyone would try, since would require a change to the design of the 
S-PEs.

Stewart



This e-mail message is intended for the recipient only and contains information 
which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have 
received this transmission in error, please inform us by e-mail, phone or fax, 
and then delete the original and all copies thereof.


This e-mail message is intended for the recipient only and contains info

RE: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18

[gareth.richards]

> -Original Message-
> From: Sam Hartman [mailto:hartmans-i...@mit.edu]
> Sent: 29 August 2011 14:58
> To: Richards, Gareth
> Cc: Black, David; hartmans-i...@mit.edu; gen-...@ietf.org;
> ietf@ietf.org; ietf-krb...@lists.anl.gov; stephen.farr...@cs.tcd.ie
> Subject: Re: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
> 
> >writes:
> 
> >> > Why should we require that alg-ids be registered URIs?
> >>
> >> That's not my concern - the existing first paragraph of the IANA
> >> considerations section in the draft requires IANA registration
> >> (or at least tries to) by pointing to the PSKC registry.  My
> >> concern is that if this is going to be done, it needs to be done
> >> right (duh!), and the current text is insufficient. Please take
> >> the issue of whether to use IANA for this purpose up with Gareth
> >> and the WG.
> >>
> >> > I have no problem with the IETF registering its algorithms
> >> there, or us > encouraging people to register them there, but
> >> it's a URI. What purpose > is served by forcing registration?
> >>
> >> Hmm - more than one URI for the same algorithm might cause
> >> interoperability problems.
> >>
> 
> g>Some form of identifier will be required for the otp-algID in the PA-
> OTP-CHALLENGE and the PA-OTP-REQUEST and from what I remember about
> when this was first discussed, it was agreed that it would make sense
> to use the registry of identifiers already being established for PSKC
> rather than produce a duplicate one.  My assumption was that a registry
> would be required to ensure that the URIs were unique.
> 
> I don't really care so just fix the current text to resolve David's
> concern.  My point was simply that whatever spec tells you how to use
> some algorithm with Kerberos can provide a unique URI and I'm
> unconvinced that it matters where that URI is drawn so long as everyone
> agrees on the URI.  Having a registry for everything the IETF does is
> fine; reusing an existing registry is better.  Constraining what
> non-IETF people do seems kind of silly but they will not listen to us
> anyway, so no harm is done.

How about the following text?  I am not sure whether to make these SHOULDs 
rather than MUSTs to allow the option of other algorithm identifiers to be used.

a) Section 4.1:

  otp-algID
 Use of this field is OPTIONAL, but MAY be used by the KDC to
 identify the algorithm to use when generating the OTP.  URIs
 used in this section SHOULD be obtained from the PSKC algorithm
 registry [RFC6030].

b) Section 4.2

   otp-algID
  This field MAY be used by the client to send the identifier of the
  OTP algorithm used, as reported by the OTP token.  Use of this
  element is OPTIONAL but it MAY be used by the client to simplify
  the OTP calculations carried out by the KDC.  It is RECOMMENDED
  that the KDC act upon this value if it is present in the request
  and it is capable of using it in the generation of the OTP value.
  URIs used in this section SHOULD be obtained from the PSKC algorithm
  registry [RFC6030].

c) Section 5

   The OTP algorithm identifiers used as otp-algID values in 
   the PA-OTP-CHALLENGE described in section 4.1 and the PA-OTP-REQUEST 
   described in section 4.2 SHOULD be registered in the PSKC algorithm
   registry [RFC6030].

--Gareth





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

Re: [websec] Last Call: (The Web Origin Concept) to Proposed Standard

[Adam Barth]

I replied to Julian's message on a W3C list.  Julian, is there more
discussion you'd like to have about these points?

Adam


On Thu, Aug 25, 2011 at 9:32 AM, Julian Reschke  wrote:
> Below a few late comments..
>
> 6. Serializing Origins
>
> - It really really seems that the two algorithms need to be swapped (the
> first one converts to ASCII, but the second does not).
>
> - Also, I'd prefer a declarative definition.
>
> 7. The HTTP Origin header
>
> - header *field*
>
> - the syntax doesn't allow multiple header fields, and the prose says
> clients MUST NOT generate them; what is the recipient supposed to do when it
> get's multiple instances anyway? Is the default approach (ignoring them all)
> good enough? Do we need to warn recipients so that they check?
>
> 11. References
>
> - the WEBSOCKETS reference should be updated (if a new draft is produced)
>
> Best regards, Julian
> ___
> websec mailing list
> web...@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [hybi] Last Call: (The WebSocket protocol) to Proposed Standard

[Iñaki Baz Castillo]

2011/9/2 Hector :
> Doesn't a WEBSOCKET client required a backend WEBSOCKET server to do
> handshaking and authentication to even allow it in the first so?  If so,
> whose network management constraint is it bypassing?

I suppose Roy talks about company firewalls or HTTP proxies inspecting
HTTP traffic nature.

-- 
Iñaki Baz Castillo

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

RE: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

[Alexander Vainshtein]

Stewart,
Lots of thanks for a prompt response.

My original email contained a typo (S-PE instead of T-PE  named as inserting ) 
which I've acknowledged and corrected in this thread (please see 
http://www.ietf.org/mail-archive/web/pwe3/current/msg12586.html).

With this correction in mind, the example I've presented (an MS-PW that 
originates in a T-PE in a MPLS-TP domain and them crosses - at S-PE - into an 
IP/MPLS domain) matches, IMHO, Yaakov's question. And if the operator wishes to 
improve traffic distribution in the IP/MPLS domain which employs ECMP, flow 
labels would be inserted by T-PE.

I believe that the change in draft-ietf-pwe3-gal-in-pw that you've proposed in 
http://www.ietf.org/mail-archive/web/pwe3/current/msg12613.html resolves the 
original issue I've raised of both GAL and flow label "competing" for the BoS 
position.

However, a conceptual question - can any MPLS-TP restrictions be placed on 
PWs?- remains open as noted in Greg's comment (please see 
http://www.ietf.org/mail-archive/web/pwe3/current/msg12620.html). IMHO and FWIW 
we should acknowledge the fact (implicitly recognized  already in RFC 5920) 
that there is simply no such thing as a MPLS-TP PW.

Hopefully this note clarifies my position on the subject.

Regards, and apologies for the original typo,
 Sasha


From: Stewart Bryant [stbry...@cisco.com]
Sent: Thursday, September 01, 2011 8:33 PM
To: Alexander Vainshtein
Cc: Yaakov Stein; m...@ietf.org; pwe3; i...@ietf.org; 
pwe3-cha...@tools.ietf.org; Luca Martini; IETF Discussion
Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw


On 01/09/2011 17:07, Alexander Vainshtein wrote:
Yaakov,
You've written
PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain
This is exactly the point that I've raised in my IETF LC comment on the draft 
(for MS-PW) - please see my email (to several lists) that explains that in some 
detail, at http://www.ietf.org/mail-archive/web/pwe3/current/msg12581.html.

Regards,
Sasha

The operator intends to improve traffic distribution in the IP/MPLS domain, 
hence he enables insertion and discard of "flow labels" at the two S-PEs.

Speaking as an author of the FAT-PW draft I do not recall any text that 
proposes that S-PEs insert FLs in the stack, and it never occurred to me that 
anyone anyone would try, since would require a change to the design of the 
S-PEs.

Stewart




This e-mail message is intended for the recipient only and contains information 
which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have 
received this transmission in error, please inform us by e-mail, phone or fax, 
and then delete the original and all copies thereof.

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

Re: 2119bis

[t.petch]

- Original Message -
From: "George Willingmyre" 
To: "Mykyta Yevstifeyev" ; 
Sent: Thursday, September 01, 2011 4:00 PM
Subject: Re: 2119bis


While we are on the topic of definitions I  hoped to stimulate thinking and we
can reach the conclusion that best meets our needs.

The source parent  document is at the URL on the ANSI web site
http://publicaa.ansi.org/sites/apdl/Documents/Standards%20Activities/Internation
al%20Standardization/ISO/ISO_IEC_Directives_Part2.pdf
ISO/IEC Directives, Part 2  Rules for the structure and drafting of
International Standards


And ..

They have their terms in Appendix H, and while we agree on MUST/SHALL, we
disagree on SHOULD; ISO IEC have a much weaker interpretation of 'should' than
the IETF.  No doubt it works for them as ours does for us.

Tom Petch



George T. Willingmyre, P.E.
President, GTW Associates
Spencerville, MD USA 20868
301.421.4138
www.gtwassociates.com
  - Original Message -
  From: Mykyta Yevstifeyev
  To: ietf@ietf.org
  Sent: Thursday, September 01, 2011 9:48 AM
  Subject: Re: 2119bis


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

Re: [websec] Last Call: (The Web Origin Concept) to Proposed Standard

[Julian Reschke]

On 2011-09-02 12:20, Adam Barth wrote:

I replied to Julian's message on a W3C list.  Julian, is there more
discussion you'd like to have about these points?
...


Well, as discussed, the syntax of the Origin header makes it hard to 
detect errors which happen when multiple instances get folded into one; 
see 
 
-- but I fear it's too late to fix this?


Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Minimum Implementation Requirements (Was: 2119bis)

[t.petch]

- Original Message -
From: "Spencer Dawkins" 
To: "Melinda Shore" ; 
Sent: Thursday, September 01, 2011 10:11 PM
> Hi, Melinda,
>
> > Can anybody point to an incident in which lack of clarity around
> > 2119 language caused problems, and it was determined that 2119
> > itself was the problem and not authors or editors being careless?
> >
> > Melinda
>
> My recollection is that, at least since the early 2000s, most "problems"
> were encountered with Last Call/Gen-ART (and probably other review team)
> comments taking forms like
>
> "Why is this SHOULD not a MUST?", or the ever-popular
> "Why is this Informational draft using 2119 language??

This sounds like RFC2119 working perfectly.  The WG is saying that this element
of the protocol SHOULD (as defined in RFC2119) be ...
whereas the reviewer is saying that the protocol would be improved if this
element of the protocol MUST (as defined in RFC2119) be 

No evidence of a problem with RFC2119 there.

Tom Petch
>
> There are probably variants I don't remember (I stopped being an active
> Gen-ART reviewer when I began serving on the IAB, and I've slept since
> then).
>
> In my comments on 2119bis
> (http://www.ietf.org/mail-archive/web/ietf/current/msg68885.html), I was
> suggesting that clarifications might head off some of these recurring
> conversations.
>
> At this point, I would be fine with a draft (of any flavor - obsoleting,
> updating, or just an IESG statement) that addresses whether these questions
> are reasonable questions. I don't have a deep need to add the (mostly
> reasonable) suggestions that have been made for new terms.
>
> If the IESG thinks that's a reasonable thing to do, they can make a call
> about the particular flavor, just fine ...
>
> Spencer
>
> ___
> 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: Pachyderm

[t.petch]

 Original Message -
From: 
To: "Yaron Sheffer" 
Cc: 
Sent: Thursday, September 01, 2011 11:54 PM
> > can you please explain *why* publishing conformance statements would be
> > such a bad idea? I am not being cynical, I really want to understand the
> > reasoning.
>
> (I don't know Pete's reasons, but I suspect they're not dissimilar from my
> own. Which are ...)
>
> The main problem with conformance languge is that conformance has a nasty way
> of becoming an end unto itself, and the *reasons* why conformance is desired
> get lost along the way. The result is technical compliance to a bunch of words
> on paper that don't provide an actual, useful, result like, say, insisting on
> interoperability does.

There is a part of our repertoire that demands compliance, which I equate with
conformance, and that is an SNMP MIB module.  RFC4181 requires every standard
MIB module to contain a compliance statement (as defined in RFC2580) which nails
down a minimum interoperable set of objects and access thereto, from the
sometimes vast range defined in the MIB module.

I see no reason why this principle should not be applied to a protocol, to its
fields, its range of values and the ability to send or receive it.

Tom Petch
>
> For example, the X.400 email standards are all about conformance. Incredibly
> elaborate and picky conformance test suites can be, and have been, written for
> this stuff. So how is it that, after passing a truly massive test suite that
> checked every last little conformance detail in the specifications (and paying
> lots of $$$ for the privilege), our software then failed to interoperate in at
> least half a dozen different ways with another piece of software that as it
> happened had also just passed the exact same test suite?
>
> Heck, we couldn't even get the thing to properly negotiate a session to
> transfer messages. And once we got that working (in the process we ended up
> having to violate a couple of those test suite requirements) we were
> immediately lost in a thicket of differing interpretations of not just
protocol
> fields but even the basic elements that comprise X.400 addresses.
>
> And this is supposed to be useful? As a moneymaker for software developers,
> maybe - you may rest assured the cost of all of this nonsense were passed on
to
> our customers, many of whom were bound by various regulations and had no
choice
> but to buy this crap - but as a way to get things to work, most assuredly not.
>
> And this trap is a lot easier to fall into than you might think. I've fallen
> into it myself - I once spent entirely too much time dithering about getting
> severe error handling "right" in a particular programming language
> implementation, completely losing sight of the fact that once an error this
> severe occurs the options are limited and the outcomes are so poor it just
> isn't that important that the rules are followed to the letter. It made a lot
> more sense on getting rid of the conditions that could cause an error.
>
> > And, for extra credit, what do you make of
> > http://tools.ietf.org/html/rfc5996#section-4 (in my own backyard)?
>
> Well, the section may be titled "Conformance Requirements" but the section
> is all about interoperability, not conformance. So that's fine in my book.
>
> Ned
> ___
> 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: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

[Bocci, Matthew (Matthew)]

Sasha,

On your final comment on the concept of an MPLS-TP PW, RFC5586 has already made 
the distinction between the use of the GAL on PWs in MPLS-TP and in other MPLS 
environments. This draft aligns the two cases in terms of the applicability of 
the GAL, by updating RFC5586 to remove the restriction on its use and position 
in an MPLS-TP environment.

The case of interconnecting PW segments on MPLS-TP to PW segments on general 
MPLS networks should be discussed elsewhere, IMHO, as the interaction between 
the GAL and hashing on some PW segments is most likely not the only issue. 
RFC5921 rules out the use of ECMP in MPLS-TP networks, so one would not expect 
an MPLS-TP PSN to hash the flow label today. If that is going to change or if 
there are other flow label applications in MPLS-TP, then IMHO drafts detailing 
those applications should discuss the interaction with the GAL.

Regards,

Matthew

On 02/09/2011 06:05, "Alexander Vainshtein" 
mailto:alexander.vainsht...@ecitele.com>> 
wrote:

Stewart,
Lots of thanks for a prompt response.

My original email contained a typo (S-PE instead of T-PE  named as inserting ) 
which I've acknowledged and corrected in this thread (please see 
http://www.ietf.org/mail-archive/web/pwe3/current/msg12586.html).

With this correction in mind, the example I've presented (an MS-PW that 
originates in a T-PE in a MPLS-TP domain and them crosses - at S-PE - into an 
IP/MPLS domain) matches, IMHO, Yaakov's question. And if the operator wishes to 
improve traffic distribution in the IP/MPLS domain which employs ECMP, flow 
labels would be inserted by T-PE.

I believe that the change in draft-ietf-pwe3-gal-in-pw that you've proposed 
inhttp://www.ietf.org/mail-archive/web/pwe3/current/msg12613.html resolves the 
original issue I've raised of both GAL and flow label "competing" for the BoS 
position.

However, a conceptual question - can any MPLS-TP restrictions be placed on 
PWs?- remains open as noted in Greg's comment (please see 
http://www.ietf.org/mail-archive/web/pwe3/current/msg12620.html). IMHO and FWIW 
we should acknowledge the fact (implicitly recognized  already in RFC 5920) 
that there is simply no such thing as a MPLS-TP PW.

Hopefully this note clarifies my position on the subject.

Regards, and apologies for the original typo,
 Sasha


From: Stewart Bryant [stbry...@cisco.com]
Sent: Thursday, September 01, 2011 8:33 PM
To: Alexander Vainshtein
Cc: Yaakov Stein; m...@ietf.org; pwe3; 
i...@ietf.org; 
pwe3-cha...@tools.ietf.org; Luca Martini; 
IETF Discussion
Subject: Re: [mpls] [PWE3] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw


On 01/09/2011 17:07, Alexander Vainshtein wrote:
Yaakov,
You've written
PW that starts in an MPLS-TP domain, can easily leak into a non-TP domain
This is exactly the point that I've raised in my IETF LC comment on the draft 
(for MS-PW) - please see my email (to several lists) that explains that in some 
detail, at http://www.ietf.org/mail-archive/web/pwe3/current/msg12581.html.

Regards,
Sasha

The operator intends to improve traffic distribution in the IP/MPLS domain, 
hence he enables insertion and discard of "flow labels" at the two S-PEs.

Speaking as an author of the FAT-PW draft I do not recall any text that 
proposes that S-PEs insert FLs in the stack, and it never occurred to me that 
anyone anyone would try, since would require a change to the design of the 
S-PEs.

Stewart



This e-mail message is intended for the recipient only and contains information 
which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have 
received this transmission in error, please inform us by e-mail, phone or fax, 
and then delete the original and all copies thereof.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [hybi] Last Call: (The WebSocket protocol) to Proposed Standard

[Hector]

Doesn't a WEBSOCKET client required a backend WEBSOCKET server to do 
handshaking and authentication to even allow it in the first so?  If 
so, whose network management constraint is it bypassing?


Roy T. Fielding wrote:

I sent this originally in March, before the last call, but I see
that it still applies for draft-ietf-hybi-thewebsocketprotocol-13.

If draft-ietf-hybi-thewebsocketprotocol-13 is approved, please
add an IESG note to the effect of:
=
   The WebSocket protocol is designed with an assumption that
   TCP port 80 or 443 will be used for the sake of tunneling raw
   socket exchanges over HTTP.  The result is a convoluted and
   inefficient exchange of hashed data for the sake of bypassing
   intermediaries that may be routing, authenticating, filtering,
   or verifying traffic on those ports.  The sole reason for using
   ports 80 and 443, and hence requiring the hashed data exchange,
   is because many organizations use TCP port blocking at firewalls
   to prevent unexpected network traffic, but allow the HTTP ports
   to remain open because they are expected to be used for normal
   Web request traffic.  WebSocket deliberately bypasses network
   management constraints in order to enable Web application
   developers to send arbitrary data though a trusted port.

   Naturally, the WebSocket protocol does not have the same network
   characteristics as HTTP.  The messages exchanged are likely to
   be smaller, more interactive, and delivered asynchronously over
   a long-lived connection.  Unfortunately, those are the same
   characteristics of typical denial-of-service attacks over HTTP.
   Organizations deploying WebSockets should be aware that existing
   network equipment or software monitoring on those ports may need
   to be updated or replaced.
=

Cheers,

Roy T. Fielding 

Begin forwarded message:


From: "Roy T. Fielding" 
Date: March 29, 2011 5:23:33 AM PDT
To: Server-Initiated HTTP 
Cc: i...@iesg.org
Subject: reuse of port 80/443 in hybi

I am finding it difficult to participate in hybi in any meaningful
way due to the very poor assumption that websockets traffic should
use the same ports as Web traffic.  Apparently, this "decision" was
made on the basis of hums at an in-person WG meeting and the chairs
believe it to be consensus (and thus quash any discussion that has
apparent consensus due to the extent to which people keep bringing
up old issues).  It might even make some sense, given the name of
this working group.

Unfortunately, it is a fatal error.  The rest of the protocol
discussion is predicated on it, and enormously complex, for the
sole reason of that initial error in design.  More the pity.
It assumes that the network infrastructure that currently
monitors and balances traffic over 80/443 is going to instantly
adapt to TCP-over-HTTP, as opposed to treating it like a denial
of service attack.

Browsers are fully capable of opening up new ports in firewalls
simply by concerted use of open standards.  Many other applications
do so without this painful corruption of existing protocols. Yes,
it takes time (but not as much time as one would think).  Yes,
there will be some companies that forcibly block some ports,
just like there are some companies that forcibly block HTTP
sites like facebook.com.  That is their right.  If the protocol
is safe to use, it will be deployable over time.  If not, then
it shouldn't make the Web situation worse by increasing the
amount of packet filtering at firewalls.

So, I don't think the hybi work is worth continuing.  The rest of
the protocol decisions simply don't matter -- any of the already
deployed proprietary hacks are better by default because they
are no worse than hybi and don't have the imprimatur of the IETF.
I'd rather develop a protocol that works with network administration
rather than against it.

I only ask that an IESG note be added to the final specification
to the effect that this protocol knowingly misuses the Internet
for the sake of bypassing organizational security.  Be honest and
let the admins make their own decisions.


Cheers,

Roy T. Fielding 


___
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