RE: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]

[Nicholas Staff]

> What fascinates me about p2p is that it was clearly the
> next Big Thing, but there seems to be no feedback loop
> operating whatsoever.

At the risk of birthing a much unwanted tangent, I think it would have been
somewhat egocentric for the IETF to do anything that lent legitimacy to the
p2p movement.  At least until some of the bigger issues surrounding it start
to find resolutions.

> > But we can't prevent people from deploying solutions that we
> > didn't develop, and we shouldn't even try to IMHO.
> 
> I wasn't suggesting control, but much more that the cross
> pollination of clue isn't happening and whether we should be
> alarmed about that. In particular, what does that say about
> ietf? Some have suggested that it means that we've done our
> job, but that strikes me as a wee bit too self-satisifed
> for my taste.

While it may be self-satisfied I still very much agree with Brian (though
having had nothing to do with the design of IP or the Internet I can't
possibly be self-satisfied, so let's just say I'm very satisfied with all of
you ;)).  I'd even go so far as to say it's none of our business (please
don't bikeshed this).  In a properly architected alphabet the letters have
no fear of the words because the words never lack for a letter.

While there are people who don't like corporate involvement in the IETF
(again no intention of spawning a tangent), I think it's that involvement
that insures a long-lasting future,  whether or not we are omnipresent on
the bleeding edge.  Truth is this is a dream come true for entrenched
corporations a. because they are somewhat assured they won't come out with
an 8-track while someone else comes out with a CD-ROM and b. once you have
your huge customer base you don't really need exclusivity to a technology,
you just need to make sure you're not excluded from it (i.e. we're a Cisco
shop and so long as Cisco can do what the others can we'll probably stay a
Cisco shop).  Anyway I guess what I'm saying is so long as 95% of the market
share continues to participate in the IETF, our opinions will continue to
matter.  I would however be alarmed if Cisco, IBM, Sun, and Microsoft
unsubscribed from this list in favor of the BitTorrent Engineering Task
Force.

Nick


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

RE: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]

[Hallam-Baker, Phillip]

> Behalf Of Michael Thomas
> This is more or less what I had in mind. Correct me if
> I'm wrong, but http 1.0 wasn't the invention of the ietf,
> but sprang forth outside of its purview. Http 1.1 was a 
> response to the many difficulties placed on the net because 
> of http 1.0, and there was an active feedback loop between 
> the http world and the net (ietf) world to adapt both at 
> layer 7 as well as below. Http, after all, was The Big Thing 
> for all parties, so it's not surprising that there was active 
> cross interest.

True enough, the 1.0 draft was mostly developed before it was submitted
to the IETF.

But the differences between 1.0 and 1.1 are hardly save the net stuff.
The only change that has been made that is really significant is the
introduction of the host address header, and that was a unilateral
action by Netscape without any external discussion of any kind. 

The rest of the 1.1 changes are mostly incremental. The chunking
mechanism is an improvement and it makes keep-alive possible but that is
an incremental improvement that was proposed independently of the IETF.

The majority of the WG effort was spent perfecting the cache mechanism
to work with proxies. Only these days we do not use client side proxies
to any real extent - the exception being transparent firewall proxies.
Most Web content is active with very short expiry times.

So yes the WG effort was useful but it certainly did not 'save the
Internet'. Nor was that ever going to be possible, Netscape made it
clear that it would act unilaterally to introduce its own standards from
day one. It was only after they ceased to be the dominant browser that
they discussed proposed changes to their version of the spec before
releasing code.


It is arguable that things could have been improved if we started
earlier. The digest authentication mechanism only exists because of the
IETF attempt to eliminate en-clair transmission of passwords.
Unfortunately very few web sites use it, almost all use the HTML form
field instead.


> What facinates me about p2p is that it was clearly the
> next Big Thing, but there seems to be no feedback loop 
> operating whatsoever. I guess that surprises me. Thomas 
> brought up qos/diffserv and operator business models which is 
> certainly something ietf clue level could assist on, but it 
> seems that we neither know them, nor do they know us and that 
> both sets of people seem satisfied with that. I'm not saying 
> that it's bad -- it's just a very surprising outcome. Ought 
> both sides be that confident that the net as engineered today 
> is what it needs to be for this Big Thing and the Big Thing 
> after that? Or that our fertilization is really the correct 
> mix to prepare the ground for the next Big Thing?

I think the problem you identify here is that the focus of the IAB is
inward, looking at what the IETF is doing. It does not look outward to
look at what the Internet community is doing. It is just assumed that
they are the same thing.

* We did not have a note from the IAB in 2000 saying 'hey this spam
thing that was predicted as a possibility in 1982 is beginning to get
really out of hand and become a criminal nuisance'

* We have not had architectural guidance of the form 'stop pushing BEEP
onto IETF working groups, the Web Services platforms have unanimously
adopted SOAP and the WS-* stack'

* We have not had information of the form 'phishing and social
engineering are becoming major engines for Internet crime'

* We have not had any real analysis of the botnet problem.





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

Re: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]

[Michael Thomas]

Brian E Carpenter wrote:

Michael Thomas wrote:

I know that we aren't the net.cops, but are we not
net.stewards either?



Up to a point, but there are limits to what we can do.

We can request that the RFC Editor not publish things we think
are damaging. The IESG does this a few times a year. Similarly,
we can request that IANA not register things we think are
damaging, or at least to label them as potentially dangerous.

We can publish screeds about damaging practices. The IAB does this
a few times a year.

We can try to develop non-damaging solutions for requirements where
the easy solutions are damaging, and we can try to repair our own
damage (as HTTP 1.1 repairs HTTP 1.0)


This is more or less what I had in mind. Correct me if
I'm wrong, but http 1.0 wasn't the invention of the ietf,
but sprang forth outside of its purview. Http 1.1 was a
response to the many difficulties placed on the net because
of http 1.0, and there was an active feedback loop between
the http world and the net (ietf) world to adapt both at
layer 7 as well as below. Http, after all, was The Big
Thing for all parties, so it's not surprising that there
was active cross interest.

What facinates me about p2p is that it was clearly the
next Big Thing, but there seems to be no feedback loop
operating whatsoever. I guess that surprises me. Thomas
brought up qos/diffserv and operator business models which
is certainly something ietf clue level could assist on, but
it seems that we neither know them, nor do they know us and
that both sets of people seem satisfied with that. I'm not
saying that it's bad -- it's just a very surprising outcome.
Ought both sides be that confident that the net as engineered
today is what it needs to be for this Big Thing and the
Big Thing after that? Or that our fertilization is really
the correct mix to prepare the ground for the next Big Thing?


But we can't prevent people from deploying solutions that we
didn't develop, and we shouldn't even try to IMHO.


I wasn't suggesting control, but much more that the cross
pollination of clue isn't happening and whether we should be
alarmed about that. In particular, what does that say about
ietf? Some have suggested that it means that we've done our
job, but that strikes me as a wee bit too self-satisifed
for my taste.

Mike

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

Re: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]

[Spencer Dawkins]

Generally, the existence of an assignment authority does encourage
its (proper) use - mostly for the reason you state above. Just as 
"nobody will want to accept an official registration polluted by 
prior use", "nobody" (deliberately in quotes) will want to attempt 
to establish an unofficial registration using the approach you've

described.  Doing so is - at the very least - going to adversely
affect popularity and is very likely to result in interference and
potentially even litigation.


"litigation"?

Do we have prior art that this is a likely result?

Spencer, honestly confused (for once)...

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

Control RE: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]

[Hallam-Baker, Phillip]

> From: Gray, Eric [mailto:[EMAIL PROTECTED] 

> Philip,
> 
>   Apology in advance if this seems to be removed from 
> context, but your statement (below) seems to have been made 
> generally and is 
> not self consistent.  Perhaps you could clarify it somewhat?
> 
> --- [ SNIP ] ---
> --> 
> --> Sure the IETF can pursuade IANA not to register a code 
> point. But if 
> --> that happens it only makes things worse. There is nothing 
> that can 
> --> be done to prevent unregistered use and no real disadvantage to 
> --> doing so as as nobody will want to accept an official 
> registration 
> --> polluted by prior use.
> --> 
> --- [ SNIP ] --- 
> 
> Generally, the existence of an assignment authority does 
> encourage its (proper) use - mostly for the reason you state 
> above. Just as 
> "nobody will want to accept an official registration polluted by 
> prior use", "nobody" (deliberately in quotes) will want to attempt 
> to establish an unofficial registration using the approach 
> you've described.  Doing so is - at the very least - going to 
> adversely affect popularity and is very likely to result in 
> interference and potentially even litigation.

That is only the case up to the point that an attempt is made to use the
registry as a means of political control.

For example if the US congress was to decide to 'require' ICANN to drop
Cuba, North Korea, Palestine etc. out of the DNS master zone file the
result would be an immediate end to the authority of ICANN beyond the
borders of the US. It would not result in the zones disappearing.

Similar issues crop up all the time in radio frequency spectrum
allocations. 


People will not want to use an unofficial registration unless the
registration process is unacceptable, either because the process itself
is too tedious or there are unacceptable costs such as politically
driven side constraints.

The DNS extensions draft proposed by some members of the IAB suffers
from this falacy. They essentially conclude that the only legitimate way
to extend the DNS is by registering a new RR with IANA. The only
'benefit' of this approach is that it gives political control over use
of the DNS to the DNSEXT working group. 

This is not considered a benefit by any of the groups looking to create
DNS policy extensions and in each case the group has essentially decided
to reuse TXT records, either with or without prefixes. Nobody has the
slightest intention of ever using the proposed 'proper' DNS record, as
has been demonstrated at some length publishing the same information
through different mechanisms leads to inconsistency. But this approach
is inisted on because 1) the fear of losing control and 2) in order to
force the pace of DNS server upgrades that allow use of new resource
records.

What has happened here is that the result is very much worse for all
parties than could be achieved if the insistence on control was dropped
- control that is in any case illusory. Forcing IETF-firendly
initiatives such as SPF and DKIM to accept IETF control does nothing to
prevent the introduction of 'dangerous' records that might actually
cause severe problems. 


If the insistence on cutting new RRs is dropped it is entirely possible
to define a method of applying prefixed records that provides all the
wildcard administrative functionality that is possible with a new RR.
This means that the protocols can be supported by the existing DNS
rather than only 50% of deployments according to empirical measurement.

It also means that we can get more protocols that make use of DNS based
policy statements which in turn means that the security of the DNS
becomes a much more important issue which in turn means that DNSSEC
becomes a much more important issue which in turn means that there is a
real incentive to deploy the DNS extensions to support deployment of new
RRs.

If you run the numbers through a spreadsheet simulation you will soon
discover that making new protocols *dependent* on an infrastructure
deployment is a much less effective deployment strategy than designing
the new protocols to be independent of the infrastructure deployment but
capable of taking advantage of the infrastructure where it exists.

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

Re: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]

[Marc Manthey]

On Sep 16, 2005, at 3:29 PM, Steven M. Bellovin wrote:

In message <[EMAIL PROTECTED]>, Brian E Carpenter  
writes:



Michael Thomas wrote:




Perfect. And then someone with less clue decided to
plant Kudzu. We have nothing to say about that?



I just read today that kudzu extract may reduce the desire
for alcohol (Scientific American, 8/2005, p 17). What seems
evil may not always be evil.



Have you ever lived in the southern U.S.?  It's amazing driving  
through
some areas, where you see kudzu covering trees, barns, telephone  
polls,

and some slow-moving cows...


wow, i never heard of it but it looks very nice

http://www.jjanthony.com/kudzu/

greetings






I know that we aren't the net.cops, but are we not
net.stewards either?



Up to a point, but there are limits to what we can do.

We can request that the RFC Editor not publish things we think
are damaging. The IESG does this a few times a year. Similarly,
we can request that IANA not register things we think are
damaging, or at least to label them as potentially dangerous.

We can publish screeds about damaging practices. The IAB does this
a few times a year.

We can try to develop non-damaging solutions for requirements where
the easy solutions are damaging, and we can try to repair our own
damage (as HTTP 1.1 repairs HTTP 1.0).

We can try to ensure that the Internet can 'route around damage' -
that's one of the main reasons for defending the e2e principle,
for example.

But we can't prevent people from deploying solutions that we
didn't develop, and we shouldn't even try to IMHO.




Agreed.  Sometimes the IETF does the initial engineering, sometimes it
has to do garbage collection and repair, and hope that the operators
can cope in the meantime.

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



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




--
" Sic transit gloria mundi"
Les Enfants Terribles
www.let.de




smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Brian E Carpenter writes:
>Michael Thomas wrote:
>> 
>> 
>> Perfect. And then someone with less clue decided to
>> plant Kudzu. We have nothing to say about that?
>
>I just read today that kudzu extract may reduce the desire
>for alcohol (Scientific American, 8/2005, p 17). What seems
>evil may not always be evil.

Have you ever lived in the southern U.S.?  It's amazing driving through 
some areas, where you see kudzu covering trees, barns, telephone polls, 
and some slow-moving cows...

>> 
>> I know that we aren't the net.cops, but are we not
>> net.stewards either?
>
>Up to a point, but there are limits to what we can do.
>
>We can request that the RFC Editor not publish things we think
>are damaging. The IESG does this a few times a year. Similarly,
>we can request that IANA not register things we think are
>damaging, or at least to label them as potentially dangerous.
>
>We can publish screeds about damaging practices. The IAB does this
>a few times a year.
>
>We can try to develop non-damaging solutions for requirements where
>the easy solutions are damaging, and we can try to repair our own
>damage (as HTTP 1.1 repairs HTTP 1.0).
>
>We can try to ensure that the Internet can 'route around damage' -
>that's one of the main reasons for defending the e2e principle,
>for example.
>
>But we can't prevent people from deploying solutions that we
>didn't develop, and we shouldn't even try to IMHO.
>

Agreed.  Sometimes the IETF does the initial engineering, sometimes it 
has to do garbage collection and repair, and hope that the operators 
can cope in the meantime.

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



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

RE: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]

[Hallam-Baker, Phillip]

Brian writes

> Sigh. That's exactly my point; our stewardship role is really 
> limited to advocacy and to providing better altermatives. I 
> don't see where you can find "special pleading", "vast 
> political influence", "force" or "anointed" in what I wrote. 
> I think we would do well to avoid polemic language on this list.

I was replying to the wider debate identified in the original subject
line there. I was not disagreeing with your points. I thought that was
clear.

I disagree with your point about advocacy, I think the IETF can do a bit
more than that.

There is a common assumption that the role of the IETF standards process
is to decide what is used on the net. The idea being that once something
is agreed as a standard it will automatically be implemented and used.
This way of thinking is likely to lead to disappointment.

A much more useful way to think about the IETF (or OASIS or W3C) is that
it is one place where you can meet others to build the necessary support
constituency to achieve deployment.

Most folk get it, a few don't. 


BitTorrent has succeeded (so far) without IETF involvement. There might
well be a point in the future where an IETF group could help further
deployment.





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

Re: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]

[Brian E Carpenter]

Hallam-Baker, Phillip wrote:

Behalf Of Brian E Carpenter




Up to a point, but there are limits to what we can do.

We can request that the RFC Editor not publish things we 
think are damaging. The IESG does this a few times a year. 
Similarly, we can request that IANA not register things we 
think are damaging, or at least to label them as potentially 
dangerous.


We can publish screeds about damaging practices. The IAB does 
this a few times a year.


We can try to develop non-damaging solutions for requirements 
where the easy solutions are damaging, and we can try to 
repair our own damage (as HTTP 1.1 repairs HTTP 1.0).


We can try to ensure that the Internet can 'route around 
damage' - that's one of the main reasons for defending the 
e2e principle, for example.


But we can't prevent people from deploying solutions that we 
didn't develop, and we shouldn't even try to IMHO.



Mao was wrong, the root of power is not coercion, it is persuasion.

Sure the IETF can pursuade IANA not to register a code point. But if
that happens it only makes things worse. There is nothing that can be
done to prevent unregistered use and no real disadvantage to doing so as
nobody will want to accept an official registration polluted by prior
use.


All true. That's why I wrote "or at least to label them as potentially
dangerous."


I do not see an argument being made that  is worse than the
alternatives that can be used. Instead there is a NIH argument that
 is in competition with .


I am not making any comment about specific technologies.



I think it is important to distinguish net.stewardship from special
pleading trying to use the vast political influence of the IETF as
described by Brian to force consumers to adopt the anointed solution
over the deployed.


Sigh. That's exactly my point; our stewardship role is really limited
to advocacy and to providing better altermatives. I don't see where you
can find "special pleading", "vast political influence", "force"
or "anointed" in what I wrote. I think we would do well to avoid
polemic language on this list.

   Brian


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

Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)

[Thomas Narten]

Scott W Brim  writes:

> The metaphor I'm trying to use this week is that the IETF is
> landscapers and we provide a fertile, beautiful area for people to go
> wild and create excellent gardens.

Exactly. The beauty of TCP/IP (and indeed many protocols when done
well) is that they are generic enablers for additional higher-level
uses.

TCP/IP creates opportunity for innovation, and does so in a way that
is generally safe for the network.

In the case of BitTorrent, it runs on top of TCP. It is silly to
assume/expect all application protocols to be developed in the IETF.

It is true that BitTorrent (or more precisely its heavy use) creates
interesting dynamics that have implications for the net and maybe even
the IETF.

For example, BitTorrent creates an environment in which end users
start running "background" jobs that run for hours and suck up idle
background network capacity. I've heard ISPs use figures of 30% or
more of their capacity This is Just Fine at one level, but also
upsets some business models.  Wouldn't it be nice if BitTorrent
traffic (at least in some cases) could be labeled as "background"
traffic so that ISPs had the ability to better prioritize or
figure out when it is critical to add more bandwidth vs. "just nice to
have"? Maybe more work here for diffserv?

Thomas

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

RE: net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]

[Hallam-Baker, Phillip]

> Behalf Of Brian E Carpenter

> Up to a point, but there are limits to what we can do.
> 
> We can request that the RFC Editor not publish things we 
> think are damaging. The IESG does this a few times a year. 
> Similarly, we can request that IANA not register things we 
> think are damaging, or at least to label them as potentially 
> dangerous.
> 
> We can publish screeds about damaging practices. The IAB does 
> this a few times a year.
> 
> We can try to develop non-damaging solutions for requirements 
> where the easy solutions are damaging, and we can try to 
> repair our own damage (as HTTP 1.1 repairs HTTP 1.0).
> 
> We can try to ensure that the Internet can 'route around 
> damage' - that's one of the main reasons for defending the 
> e2e principle, for example.
> 
> But we can't prevent people from deploying solutions that we 
> didn't develop, and we shouldn't even try to IMHO.

Mao was wrong, the root of power is not coercion, it is persuasion.

Sure the IETF can pursuade IANA not to register a code point. But if
that happens it only makes things worse. There is nothing that can be
done to prevent unregistered use and no real disadvantage to doing so as
nobody will want to accept an official registration polluted by prior
use.

I do not see an argument being made that BitTorrent is worse than the
alternatives that can be used. Instead there is a NIH argument that
BitTorrent is in competition with multicast.

I think it is important to distinguish net.stewardship from special
pleading trying to use the vast political influence of the IETF as
described by Brian to force consumers to adopt the anointed solution
over the deployed.


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

net.stewards [Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)]

[Brian E Carpenter]

Michael Thomas wrote:

Scott W Brim wrote:


On 09/15/2005 17:09 PM, Paul Hoffman allegedly wrote:


At 1:50 PM -0700 9/15/05, Michael Thomas wrote:


Which is pretty much the elephant in the room, I'd say. How
much of the net traffic these days is, essentially, not in
any way standardized, and in fact probably considers ietf
old and in the way?



Not sure why this is an elephant; who cares? I have seen numbers that
show that a huge percentage of traffic is P2P of various flavors, but I
haven't seen anyone saying that this is having any negative effects.




The metaphor I'm trying to use this week is that the IETF is
landscapers and we provide a fertile, beautiful area for people to go
wild and create excellent gardens.  What you're describing is not a
bug, it's feature.  It means the IETF have done their job.  If there
were interoperability problems in the fundamental and/or widespread
technologies being used in the Internet, then there would be a problem
(we're working on those).  Congratulations.



Perfect. And then someone with less clue decided to
plant Kudzu. We have nothing to say about that?


I just read today that kudzu extract may reduce the desire
for alcohol (Scientific American, 8/2005, p 17). What seems
evil may not always be evil.


I know that we aren't the net.cops, but are we not
net.stewards either?


Up to a point, but there are limits to what we can do.

We can request that the RFC Editor not publish things we think
are damaging. The IESG does this a few times a year. Similarly,
we can request that IANA not register things we think are
damaging, or at least to label them as potentially dangerous.

We can publish screeds about damaging practices. The IAB does this
a few times a year.

We can try to develop non-damaging solutions for requirements where
the easy solutions are damaging, and we can try to repair our own
damage (as HTTP 1.1 repairs HTTP 1.0).

We can try to ensure that the Internet can 'route around damage' -
that's one of the main reasons for defending the e2e principle,
for example.

But we can't prevent people from deploying solutions that we
didn't develop, and we shouldn't even try to IMHO.

   Brian


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

Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)

[Iljitsch van Beijnum]

On 16-sep-2005, at 1:00, Michael Thomas wrote:


  I'm not sure; maybe it's really a mutual non-admiration
  society, and everybody's happy? But it's an elephant
  insofar as it's pretty darn big trafficwise, and the
  fact that ietf doesn't seem concerned?


Why should the IETF be concerned about traffic?

Now of course that doesn't mean our amateur protocol designers get it  
right every time... For instance, when you become a Gnutella  
"ultrapeer" you'll very likely create some nasty congestion in the  
outgoing direction of your ADSL or cable connection because when you  
receive one request, the program wakes up and sends out copies of  
that request over several dozen TCP sessions at the same time, which  
will invariably overload the buffers at some point between the host  
and the DSL/cable connection.



we're layering
  more and more stuff onto the net too -- like voip -- that
  are pretty sensitive to average expectations (I'm thinking
  about things like Vonage, not managed services). Is that
  a danger for the overall internet architecture?


Anyone who thinks he or she is going to meet real time constraints  
over a random path across the internet that spans multiple ASes has  
more problems than the IETF can possibly fix.


And no, I don't think it's reasonable to restrict p2p bulk data  
transfer to accommodate voice over the public internet.


(Maybe at some point people from Apple would like to share the  
results of them setting a DSCP code point / type of service in the IP  
header of voice packets.)


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

Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)

[Michael Thomas]

Scott W Brim wrote:

On 09/15/2005 17:09 PM, Paul Hoffman allegedly wrote:


At 1:50 PM -0700 9/15/05, Michael Thomas wrote:


Which is pretty much the elephant in the room, I'd say. How
much of the net traffic these days is, essentially, not in
any way standardized, and in fact probably considers ietf
old and in the way?


Not sure why this is an elephant; who cares? I have seen numbers that
show that a huge percentage of traffic is P2P of various flavors, but I
haven't seen anyone saying that this is having any negative effects.



The metaphor I'm trying to use this week is that the IETF is
landscapers and we provide a fertile, beautiful area for people to go
wild and create excellent gardens.  What you're describing is not a
bug, it's feature.  It means the IETF have done their job.  If there
were interoperability problems in the fundamental and/or widespread
technologies being used in the Internet, then there would be a problem
(we're working on those).  Congratulations.


Perfect. And then someone with less clue decided to
plant Kudzu. We have nothing to say about that?

I know that we aren't the net.cops, but are we not
net.stewards either?

Mike, asking.

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

Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)

[Michael Thomas]

Paul Hoffman wrote:

At 1:50 PM -0700 9/15/05, Michael Thomas wrote:

Which is pretty much the elephant in the room, I'd say. How
much of the net traffic these days is, essentially, not in
any way standardized, and in fact probably considers ietf
old and in the way?



Not sure why this is an elephant; who cares? 


  I'm not sure; maybe it's really a mutual non-admiration
  society, and everybody's happy? But it's an elephant
  insofar as it's pretty darn big trafficwise, and the
  fact that ietf doesn't seem concerned?

I have seen numbers that 
show that a huge percentage of traffic is P2P of various flavors, but I 
haven't seen anyone saying that this is having any negative effects. 


  I don't think this is _entirely_ true: p2p stuff definitely
  has, um, interesting effects on, say, voip at home, and some
  of the p2p apps -- especially the earlier ones if I recall
  correctly -- had some pretty nasty effects on various networks.

  Are we to believe that they are largely self-healing problems
  as bad p2p apps will eventually correct themselves since it's
  in their interest? Is it reasonable to believe that there is
  enough general clue that they could be expected to do that?
  And the collective clue of the ietf is not really needed to
  help this along?


I'll note that many protocols -- good and bad -- spring from
somebody's head. Some of them become successful too. Very
successful. And ietf has no say about them at all. Is this
the new reality?



But for layer 7 protocols, file sharing 
may be the only major market that has wholly ignored the IETF.


  This isn't that unusual really, but what facinates me
  is that the reverse seems true as well.

Yes, if one that has bad congestion control becomes popular. But, given 
the mindshare of BitTorrent these past few years, that seems pretty 
unlikely.


  But surely BitTorrent isn't the last one that will come
  along. I guess the base question is this: is the net robust
  enough to really allow experimentation with flash crowds of
  millions of alpha testers? So far it has, but we're layering
  more and more stuff onto the net too -- like voip -- that
  are pretty sensitive to average expectations (I'm thinking
  about things like Vonage, not managed services). Is that
  a danger for the overall internet architecture? That is, is
  there a price for this benign neglect that has yet to surface?

Mike

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

Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)

[Scott W Brim]

On 09/15/2005 17:09 PM, Paul Hoffman allegedly wrote:
> At 1:50 PM -0700 9/15/05, Michael Thomas wrote:
>> Which is pretty much the elephant in the room, I'd say. How
>> much of the net traffic these days is, essentially, not in
>> any way standardized, and in fact probably considers ietf
>> old and in the way?
> 
> Not sure why this is an elephant; who cares? I have seen numbers that
> show that a huge percentage of traffic is P2P of various flavors, but I
> haven't seen anyone saying that this is having any negative effects.

The metaphor I'm trying to use this week is that the IETF is
landscapers and we provide a fertile, beautiful area for people to go
wild and create excellent gardens.  What you're describing is not a
bug, it's feature.  It means the IETF have done their job.  If there
were interoperability problems in the fundamental and/or widespread
technologies being used in the Internet, then there would be a problem
(we're working on those).  Congratulations.

swb

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

Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)

[Paul Hoffman]

At 1:50 PM -0700 9/15/05, Michael Thomas wrote:

Always the risk when one is being flippant, but I only
meant that the world outside of ietf seems to be taking
on a lot of these issues without ietf's advice and consent.


Fully agree.

In this case, there is no advantage to the developer of the 
protocol to have it worked on in the IETF, nor even published as an 
RFC. It came out of one person's head, he was able to experiment 
with it live on the net, and he retains the ability to tweak the 
specs whenever he feels like it. It has worked remarkably well, 
given the variety of clients and servers available for the 
protocol, and the huge amount of traffic that is moved daily over 
it.


Which is pretty much the elephant in the room, I'd say. How
much of the net traffic these days is, essentially, not in
any way standardized, and in fact probably considers ietf
old and in the way?


Not sure why this is an elephant; who cares? I have seen numbers that 
show that a huge percentage of traffic is P2P of various flavors, but 
I haven't seen anyone saying that this is having any negative 
effects. BitTorrent in specific spreads out the traffic by making 
many receivers senders as well, so the traffic isn't all concentrated 
on one point. Many music traders (such as myself) leave the torrent 
running after we have gotten all the content because that helps 
reduce the load on the originator so he/she can originate more music, 
and because we have spare bandwidth. The fact that this helps spread 
the load on the Internet is nice, but probably not important to 99% 
of traders.


(Right about now, someone from Japan or Korea should hop in and talk 
about the rampant television show trading that I have heard so much 
about there.)



I'll note that many protocols -- good and bad -- spring from
somebody's head. Some of them become successful too. Very
successful. And ietf has no say about them at all. Is this
the new reality?


It is a new reality, not the new reality. We still create lots of 
important new things here, and lots of folks still come to us to ask 
us to do more. New data formats (or rehashed old data formats) seem 
to be happening more outside the IETF, although Atom 1.0 has 
certainly garnered its share of publicity. But for layer 7 protocols, 
file sharing may be the only major market that has wholly ignored the 
IETF.



Sure seems like it to me. Should we be
concerned?


Nope.


Might there be film at 11 at some point because
of it?


Yes, if one that has bad congestion control becomes popular. But, 
given the mindshare of BitTorrent these past few years, that seems 
pretty unlikely.


--Paul Hoffman, Director
--VPN Consortium

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

Re: BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)

[Michael Thomas]

Paul Hoffman wrote:

At 5:32 PM -0700 9/14/05, Michael Thomas wrote:

You mean we could invent Bitorrent? :)



BitTorrent (note the spelling) does a lot of very nice things, but not 
those. For those interested, the BitTorrent protocol is described at 
.


Always the risk when one is being flippant, but I only
meant that the world outside of ietf seems to be taking
on a lot of these issues without ietf's advice and consent.




Mike, doesn't it strike others as odd
 that ietf is completely outside of the
 p2p bizness?



In this case, there is no advantage to the developer of the protocol to 
have it worked on in the IETF, nor even published as an RFC. It came out 
of one person's head, he was able to experiment with it live on the net, 
and he retains the ability to tweak the specs whenever he feels like it. 
It has worked remarkably well, given the variety of clients and servers 
available for the protocol, and the huge amount of traffic that is moved 
daily over it.


Which is pretty much the elephant in the room, I'd say. How
much of the net traffic these days is, essentially, not in
any way standardized, and in fact probably considers ietf
old and in the way?

I'll note that many protocols -- good and bad -- spring from
somebody's head. Some of them become successful too. Very
successful. And ietf has no say about them at all. Is this
the new reality? Sure seems like it to me. Should we be
concerned? Might there be film at 11 at some point because
of it?

Mike, or is it too soon for another
 ietf ossification thread?

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

CH and p2p [Re: [Isms] ISMS charter broken- onus should be on WG to fix it]

[Brian E Carpenter]

If you want to discuss this as a generic issue, please do so
with an appropriate subject and without cross posting. Thanks.

BTW I agree that there is a generic architectural issue here
that merits discussion.

   Brian


Michael Thomas wrote:

Ned Freed wrote:


Ned Freed wrote:
> If I were to object to Eliot's proposal (I don't - in fact I strongly
> support
> it), it would be on the grounds that the IETF should be taking a long
> hard look
> at the issues surrounding call home in general, not just in the 
special

> case of
> SNMP.





I'll bite: what could the IETF do if it looked
long and hard?




Well, the one approach that immediately comes to mind is that the 
introduction
of a third party might provide a means of getting timely information 
about

software updates without sacrificing user privacy.

Such a third party would act as a repository for update information 
provided by

vendors. Applications would then "call home" to one of these repositories
rather than directly to the vendor. Various anonymyzing tricks could be
employed to minimize information leakage even if the third party was
compromised.



You mean we could invent Bitorrent? :)

Mike, doesn't it strike others as odd
 that ietf is completely outside of the
 p2p bizness?




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

BitTorrent (Was: Re: [Isms] ISMS charter broken- onus should be on WG to fix it)

[Paul Hoffman]

At 5:32 PM -0700 9/14/05, Michael Thomas wrote:

Ned Freed wrote:
Such a third party would act as a repository for update information 
provided by

vendors. Applications would then "call home" to one of these repositories
rather than directly to the vendor. Various anonymyzing tricks could be
employed to minimize information leakage even if the third party was
compromised.


You mean we could invent Bitorrent? :)


BitTorrent (note the spelling) does a lot of very nice things, but 
not those. For those interested, the BitTorrent protocol is described 
at .



Mike, doesn't it strike others as odd
 that ietf is completely outside of the
 p2p bizness?


In this case, there is no advantage to the developer of the protocol 
to have it worked on in the IETF, nor even published as an RFC. It 
came out of one person's head, he was able to experiment with it live 
on the net, and he retains the ability to tweak the specs whenever he 
feels like it. It has worked remarkably well, given the variety of 
clients and servers available for the protocol, and the huge amount 
of traffic that is moved daily over it.


--Paul Hoffman, who shares a lot of legal music and OSs with BitTorrent

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

Re: [Isms] ISMS charter broken- onus should be on WG to fix it

[Michael Thomas]

Ned Freed wrote:

Ned Freed wrote:
> If I were to object to Eliot's proposal (I don't - in fact I strongly
> support
> it), it would be on the grounds that the IETF should be taking a long
> hard look
> at the issues surrounding call home in general, not just in the special
> case of
> SNMP.




I'll bite: what could the IETF do if it looked
long and hard?



Well, the one approach that immediately comes to mind is that the 
introduction

of a third party might provide a means of getting timely information about
software updates without sacrificing user privacy.

Such a third party would act as a repository for update information 
provided by

vendors. Applications would then "call home" to one of these repositories
rather than directly to the vendor. Various anonymyzing tricks could be
employed to minimize information leakage even if the third party was
compromised.


You mean we could invent Bitorrent? :)

Mike, doesn't it strike others as odd
 that ietf is completely outside of the
 p2p bizness?

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

Re: [Isms] ISMS charter broken- onus should be on WG to fix it

[Ned Freed]

Ned Freed wrote:
> If I were to object to Eliot's proposal (I don't - in fact I strongly
> support
> it), it would be on the grounds that the IETF should be taking a long
> hard look
> at the issues surrounding call home in general, not just in the special
> case of
> SNMP.



I'll bite: what could the IETF do if it looked
long and hard?


Well, the one approach that immediately comes to mind is that the introduction
of a third party might provide a means of getting timely information about
software updates without sacrificing user privacy.

Such a third party would act as a repository for update information provided by
vendors. Applications would then "call home" to one of these repositories
rather than directly to the vendor. Various anonymyzing tricks could be
employed to minimize information leakage even if the third party was
compromised.

Mind you, thiis all off the top of my head. This may not work for some reason
I haven't considered, or there may be other, better approaches.

Ned

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

Re: [Isms] ISMS charter broken- onus should be on WG to fix it

[Michael Thomas]

Ned Freed wrote:
If I were to object to Eliot's proposal (I don't - in fact I strongly 
support
it), it would be on the grounds that the IETF should be taking a long 
hard look
at the issues surrounding call home in general, not just in the special 
case of

SNMP.


I'll bite: what could the IETF do if it looked
long and hard?

Mike

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

Re: [Isms] ISMS charter broken- onus should be on WG to fix it

[Wes Hardaker]

Eliot> Wes received the obvious feedback that operators find SNMP
Eliot> unusable with the USM model because they cannot integrate it
Eliot> with their existing security infrastructures and there is no
Eliot> denying that this is a real problem.  But this is NOT the only
Eliot> problem operators face with SNMP.

FYI, there was a "other comments" field in the survey that the
operators filled out.  I just went back and reviewed everything
entered into that space and no one asked for anything like the CH
functionality, nor did they even mention NATs or firewalls at all.

That being said, that wasn't the point of the survey and I do think
the problem shouldn't be forgotten.  I think we'd be stupid to let the
work go forward and do something that deliberately prevented CH
functionality from being usable in the ISMS/SSH draft.  However,
everything needs to be weighed and I do think we should make sure it's
possible till we run into a problem.  At that time we'd have to
evaluate the choices to decide which was more important (the potential
problem being unknown at this time of course).

I'm not sure the charter needs to explicitly state that we must
consider call home support.  It sounds like there is enough energy to
make sure we don't blow it.  I would strongly object to anything that
says we must support it, because as has been stated many times "that's
not the point of the WG".  At the same time, I think we'd be idiots
not to at the very least leave room for it (but then, I think we're
not being wise for dropping the consideration of a UDP solution too, so...)

-- 
Wes Hardaker
Sparta, Inc.

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

Re: [Isms] ISMS charter broken- onus should be on WG to fix it

[Jeffrey Hutzelman]

On Tuesday, September 13, 2005 05:23:26 PM -0700 Ned Freed 
<[EMAIL PROTECTED]> wrote:



> I suspect that the ssh community would decline to extend ssh in this
> direction; I certainly know I would not support it.



I'm not entirely sure _how_ I'd extend SSH in this direction, or how much
utility it would have.  I don't think I would object to it, especially
since I suspect it might make some of the ISMS cases easier even if you
don't care about the firewall problem.


Well, the ssh client I use has the ability to do port forwarding in both
directions already. The only thing that has stopped me from using this
feature
to do SNMP monitoring of various mobile agents is that it doesn't work
with
UDP, and the SNMP stuff I use is UDP only.


Aha!  Another use case for UDP tunnelling in SSH, which is a topic that was 
recently brought up in that WG.


In any event, the problem isn't carrying the SNMP traffic over an ssh 
connedction -- we're fairly confident we know how to do that, though the 
document isn't done yet.  The problems are in determining when to establish 
an SSH connection for the purpose of _receiving_ traffic, and in making 
authentication work in cases where a managed device wants to authenticate 
to something that is essentially a user.  With some authentication 
infrastructures the latter is easy; with others it is not.  The former I 
think is always hard, but has nothing to do with SSH per se.


I think that we can easily avoid making call-home harder than it needs to 
be, and that we should.  I would not object to a change in ISMS's charter 
requiring that it consider the potential effects of any security solution 
it adopts on the ability to add a call-home mechanism, but I also don't 
think such a provision is necessary to achieve the desired result.


I don't think extending the SNMP architecture to add call-home is within 
the scope of ISMS's charter, and I don't think it would be appropriate to 
add it at this time.  I'm not quite as concerned as Margaret is about the 
"wrong area" problem, provided the right people are active in the WG and 
reviewing its output, which I believe is necessary in any event.


However, I do believe the problems are separable, nearly orthogonal, and 
require somewhat different expertise.  Provided that the ISMS work does not 
preclude call-home or some other solution to the problem, I think a 
narrowly-scoped working group is appropriate here.


-- Jeff

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

Re: [Isms] ISMS charter broken- onus should be on WG to fix it

[Ned Freed]

On Tuesday, September 13, 2005 05:06:40 PM -0400 Sam Hartman
<[EMAIL PROTECTED]> wrote:



>> "Juergen" == Juergen Schoenwaelder <[EMAIL PROTECTED]>
>> writes:
>
> Juergen> Sam,
>
> Juergen> this is not about blocking port 22 as far as I understand
> Juergen> things. I think the issue here is that TCP connection
> Juergen> establishment determines ssh client/server roles.  If
> Juergen> there would be a way to initiate the connection but
> Juergen> subsequently taking over the server role, protocols like
> Juergen> netconf and presumably isms would find it much easier to
> Juergen> provide CH functionality.
>
> Right.  But for the ssh-connect application I don't think you would
> want that unless you were trying to get around firewall policy.



I don't think that's necessarily the case. Sure, you might be trying to do
that, but you also might be trying to get around the fact that the machines
at your house are behind a NAT and thus lack routable addresses.


Or consider the case of a firewall whose policy is simply one where incoming
connections are not allowed for fear of worms infecting vulnerable systems. The
only way to monitor systems behind such a firewall is to have them establish
outgoing connections. Such behavior is in no way, shape or form a violation of
that firewall's policy, yet it is necessary to work properly in such a (very
common) firewalled environment.

More generally, every protocol we define, every enhancement to a protocol we
specify, and every operational policy we advocate has the potential of being
used to "get around firewall policy" in some situation or other.  And this is
especially true when we're defining protocols that provide some form of
confidentiality, which of course we do more and more frequently. This is the
nature of the beast, like it or not. Were we to use this as a criteria not to
proceed with our work we might as well all go home.

Furthermore, the fact of the matter is that specifying how something is
supposed to be done tends to aid in establishing useful firewall policies far
more than it hurts. People are going to use the "call home" approach for
monitoring whether we like it or not - it is just too useful for them not to.
And absent a specification it will be done in a zillion incompatible ways and
without any real understanding of the security issues. And unless firewall
operators are prepared to block absolutely everything (which of course they
cannot) they don't stand a chance in hell of controlling such services. A
timely specification, on the other hand, could simultaneously raise awareness
of the security issues as well as provide some measure of consistency in such
traffic, in turn allowing some measure of control.

And make no mistake about it: When it comes to call home services, the
situation is already dire. Only yesterday I observed a popup from a piece of
video processing software I use informing me that a new version is now
available. Obviously this application had just "called home" and found out
about the new version. Hopefully that's all it did - nowhere in the product
documentation does it mention it would do this, nor is there any preferences
setting I can find to tell it not to. 


If I were to object to Eliot's proposal (I don't - in fact I strongly support
it), it would be on the grounds that the IETF should be taking a long hard look
at the issues surrounding call home in general, not just in the special case of
SNMP.


> I suspect that the ssh community would decline to extend ssh in this
> direction; I certainly know I would not support it.



I'm not entirely sure _how_ I'd extend SSH in this direction, or how much
utility it would have.  I don't think I would object to it, especially
since I suspect it might make some of the ISMS cases easier even if you
don't care about the firewall problem.


Well, the ssh client I use has the ability to do port forwarding in both
directions already. The only thing that has stopped me from using this feature
to do SNMP monitoring of various mobile agents is that it doesn't work with
UDP, and the SNMP stuff I use is UDP only.

Ned

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

Re: [Isms] ISMS charter broken- onus should be on WG to fix it

[Juergen Schoenwaelder]

On Tue, Sep 13, 2005 at 05:06:40PM -0400, Sam Hartman wrote:

> I would support setting up port forwarding as a way to get a back
> channel; I would also support a facility to run an ssh protocol over
> ssh channel.
> 
> One advantage of both port forwarding and ssh over ssh is that they
> provide a much more consistent model for authentication and
> authorization of the request to "turn" than an explicit turn facility.

Can you please elaborate a bit? I am not sure I understand the idea
you seem to have in your mind...

/js

-- 
Juergen Schoenwaelder   International University Bremen
 P.O. Box 750 561, 28725 Bremen, Germany

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

Re: [Isms] ISMS charter broken- onus should be on WG to fix it

[Jeffrey Hutzelman]

On Tuesday, September 13, 2005 05:06:40 PM -0400 Sam Hartman 
<[EMAIL PROTECTED]> wrote:



"Juergen" == Juergen Schoenwaelder <[EMAIL PROTECTED]>
writes:


Juergen> Sam,

Juergen> this is not about blocking port 22 as far as I understand
Juergen> things. I think the issue here is that TCP connection
Juergen> establishment determines ssh client/server roles.  If
Juergen> there would be a way to initiate the connection but
Juergen> subsequently taking over the server role, protocols like
Juergen> netconf and presumably isms would find it much easier to
Juergen> provide CH functionality.

Right.  But for the ssh-connect application I don't think you would
want that unless you were trying to get around firewall policy.


I don't think that's necessarily the case.  Sure, you might be trying to do 
that, but you also might be trying to get around the fact that the machines 
at your house are behind a NAT and thus lack routable addresses.



I suspect that the ssh community would decline to extend ssh in this
direction; I certainly know I would not support it.


I'm not entirely sure _how_ I'd extend SSH in this direction, or how much 
utility it would have.  I don't think I would object to it, especially 
since I suspect it might make some of the ISMS cases easier even if you 
don't care about the firewall problem.


-- Jeff

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

Re: [Isms] ISMS charter broken- onus should be on WG to fix it

[Sam Hartman]

> "Juergen" == Juergen Schoenwaelder <[EMAIL PROTECTED]> writes:

Juergen> Sam,

Juergen> this is not about blocking port 22 as far as I understand
Juergen> things. I think the issue here is that TCP connection
Juergen> establishment determines ssh client/server roles.  If
Juergen> there would be a way to initiate the connection but
Juergen> subsequently taking over the server role, protocols like
Juergen> netconf and presumably isms would find it much easier to
Juergen> provide CH functionality.

Right.  But for the ssh-connect application I don't think you would
want that unless you were trying to get around firewall policy.

I suspect that the ssh community would decline to extend ssh in this
direction; I certainly know I would not support it.

I would support setting up port forwarding as a way to get a back
channel; I would also support a facility to run an ssh protocol over
ssh channel.

One advantage of both port forwarding and ssh over ssh is that they
provide a much more consistent model for authentication and
authorization of the request to "turn" than an explicit turn facility.

--Sam


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

Re: [Isms] ISMS charter broken- onus should be on WG to fix it

[Juergen Schoenwaelder]

On Tue, Sep 13, 2005 at 02:31:54PM -0400, Sam Hartman wrote:
> > "David" == David B Harrington <[EMAIL PROTECTED]> writes:
> 
> David> Hi, Personally, I'd rather see the issue of working through
> David> NATs and firewalls solved at the SSH level, and then SNMP
> David> and other SSH-using applications, such as Netconf and CLI,
> David> could use the solution in a consistent manner.
> 
> I think that the ssh connection application already has a fairly
> reasonable story for NATs and firewalls, so I don't see much of a need
> for ssh itself to advance in this area.  
> 
> For the most part people who block port 22 really do intend to block
> ssh and so having standard facilities to get around that would not be
> appropriate.  The port forwarding support in ssh seems to be an
> adequate solution for NATs.

Sam, 

this is not about blocking port 22 as far as I understand things. I
think the issue here is that TCP connection establishment determines
ssh client/server roles.  If there would be a way to initiate the
connection but subsequently taking over the server role, protocols
like netconf and presumably isms would find it much easier to provide
CH functionality.

/js

-- 
Juergen Schoenwaelder   International University Bremen
 P.O. Box 750 561, 28725 Bremen, Germany

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

RE: [Isms] ISMS charter broken- onus should be on WG to fix it

[Nelson, David]

Juergen Quittek writes...

> It [call home] looks like a good topic for a BoF session in the 
> OaM area.
> There we could find out the relevance of the problem and discuss
> requirements for potential solutions.  Also there we can identify
> which working group would be the right one to deal with the issue.
> 
> But until then, I propose that we let the ISMS group work on solving
> its original problem.

I agree that specifying Call Home functionality in SNMP should be out of
scope for ISMS, which is attempting to solve a different, well-defined
problem.

I also agree with Dave Harrington's suggestion that the SSH transport
mechanism for ISMS should be designed such that the initiation and
termination of SSH sessions, and the use of such sessions by the command
generator and command responder, would not preclude another WG from
specifying Call Home functionality using the ISMS work, unless that
requirement overly complicated the ISMS design work.  I would call this
division of labor an appropriate "separation of concerns". 


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

Re: [Isms] ISMS charter broken- onus should be on WG to fix it

[Sam Hartman]

> "David" == David B Harrington <[EMAIL PROTECTED]> writes:

David> Hi, As primary editor of the SSH draft (SSHSM), I spoke
David> with Eliot last week. I agree that it is difficult for him
David> to develop a reasonable proposal that piggybacks on the SSH
David> draft, because the SSH draft is so incomplete.

David> I am not convinced that SNMP needs to add a new call-home
David> (CH) functionality, nor that this feature is needed in SNMP
David> now, but there is a danger that CH might never be possible
David> if we don't consider its impact on the SSHSM model before
David> SSHSM is cast in stone. If it complicates the SSHSM model,
David> I would prefer to not include it; a new model could be
David> developed to replace or supplement the SSHSM model if
David> demand increases for this functionality.

David> I recommended to Eliot that he contribute some text for the
David> SSH document, describing the CH functionality and proposed
David> elements of procedure, that I could include as an appendix
David> to the SSHSM document so the WG could review his proposal,
David> and then the WG could decide whether it should remain as an
David> appendix, be incorporated into the SSH document, be split
David> out as a separate document, or be abandoned altogether. I
David> felt this was a reasonable alternative to making the
David> decision whether CH is or is not in scope at this time. He
David> has not yet had a chance to develop the text and send it to
David> me.


I completely agree that having Eliot and other interested parties work
on how technical details of CH would work for ssh is a good idea.

I also agree that having it be an appendix in the document is fine for
now.


I was hoping that Eliot would go forward in this direction; in my
original message ruling CH out of scope I aske Eliot to work with the
ssh document editor to see how CH might work.

--Sam



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

Re: [Isms] ISMS charter broken- onus should be on WG to fix it

[Sam Hartman]

> "David" == David B Harrington <[EMAIL PROTECTED]> writes:

David> Hi, Personally, I'd rather see the issue of working through
David> NATs and firewalls solved at the SSH level, and then SNMP
David> and other SSH-using applications, such as Netconf and CLI,
David> could use the solution in a consistent manner.


I think that the ssh connection application already has a fairly
reasonable story for NATs and firewalls, so I don't see much of a need
for ssh itself to advance in this area.  

For the most part people who block port 22 really do intend to block
ssh and so having standard facilities to get around that would not be
appropriate.  The port forwarding support in ssh seems to be an
adequate solution for NATs.

SNMP can use these facilities certainly.  However you may want/need a
more automated solution.

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

Re: [Isms] ISMS charter broken- onus should be on WG to fix it

[Eliot Lear]

Juergen,

Wes received the obvious feedback that operators find SNMP unusable with
the USM model because they cannot integrate it with their existing
security infrastructures and there is no denying that this is a real
problem.  But this is NOT the only problem operators face with SNMP.

While the group focused on UDP-based solutions it made no sense to raise
concerns about firewall and NAT traversal, because in my opinion UDP
traversal would likely be no different for ISMS or non-ISMS.  With TCP
and SSH in particular, the group can reasonably deal with the problem
with very little additional work, as I described.  Because it can, it
should.

In other words, firewall/NAT traversal has always been a problem, but
the choice of either SSH or BEEP could easily provide a means to address it.

People have suggested a BoF on this subject.  I am perfectly happy to
hold a BoF in November on this subject if the WG and IESG are adamant
that this work be done elsewhere.  I suggest that it occur adjacent to
the ISMS working group, so that people understand just the sort of
changes that will be required between ISMS and this other thing.

I would also agree with Dave that if the necessary work for CH turns out
to be onerous in ISMS the the WG should reconsider.  I just don't
envision the premise of that statement being true.

Eliot

Juergen Quittek wrote:
> Eliot,
> 
> At the SBSM and ISMS BoF sessions at IETF 58 and 60 the need for
> integrating SNMP into existing security frameworks was extensively
> discussed.  Wes presented the issue at NANOG and performed a survey
> among operators.  The output of all this work is the idenitfication
> of a well founded general requirement for working on the integration
> of SNMP into existing security frameworks in an IETF working group.
> 
> Now you claim that solving this issue is technically wrong without
> considering a different problem that you call "call home".  Rather
> you request adding the issue of solving the "call home" to the ISMS
> charter.
> 
> However, nobody raised this issue at the ISMS BoFs nor has the
> issue been discussed in depth in the OaM area.  But we should have
> such a discussion before adding the issue to any IETF WG charter.
> It looks like a good topic for a BoF session in the OaM area.
> There we could find out the relevance of the problem and discuss
> requirements for potential solutions.  Also there we can identify
> which working group would be the right one to deal with the issue.
> 
> But until then, I propose that we let the ISMS group work on solving
> its original problem.
> 
> Thanks,
> 
>Juergen
> 
> 
> --On 9/12/2005 9:53 PM +0200 Eliot Lear wrote:
> 
>> Sam,
>>
>> I believe the approach you have proposed is quite simply wrong.  As an
>> AD you're supposed to provide technical oversight and not simply hold a
>> popularity contest.  If you have technical questions or wish to
>> challenge me on a technical point, I think that's fair game.
>>
>> As I've written, the path we are headed down technically will not work
>> in the face of firewalls and NATs, and nobody has refuted this.
>>
>> Furthermore you've heard from a reasonably large customer (Boeing) as
>> well as your predecessor on the prevalence of such middle boxes that
>> demonstrates the complexity of today's environment and the need for this
>> sort of functionality as part of the solution.
>>
>> You've heard from an author of SNMP that the major architectural change
>> is the use of session based security and NOT CH, the same from the
>> former O&M AD and IETF chair.  You've heard from a service provider as
>> well as numerous members of the community who see the problem.
>>
>> You may or may not have yet heard from other standards bodies but if you
>> were to delay it is quite possible they will chime in since one was
>> specifically interested in this sort of function.
>>
>> The amount of changes required to support CH cannot fully be ascertained
>> until more of the the [Todo]s are filled in with Dave's draft, but I
>> don't imagine the work would be much more than:
>>
>>  - specifying how to initiate the connection and if necessary turn it
>>  - the identity used for requests received from command generators that
>>did not initiate the connection along with potential prepopulating
>>of various tables
>>  - an appendix of how the SNMP-TARGET-MIB would be populated
>>  - a discussion on when to initiate connections and what to do when
>>they fail (mind you this is needed anyway regardless of CH)
>>  - security considerations involving firewalls, blocking, etc.
>>  - possibly one additional table describing the state of SSH peer
>>connectivity (which probably wouldn't be bad to have anyway).
>>
>> Decide for yourself if you think this is a substantial amount of text,
>> but I won't leave it to your imagination for long.  I will attempt this
>> week to post a derivative of the draft that Dave is working on to give
>> people an idea of what the changes would be

Re: [Isms] ISMS charter broken- onus should be on WG to fix it

[Keith McCloghrie]

Dave,

I support the "alternative" you are recommending.

Thanks,
Keith.

> As primary editor of the SSH draft (SSHSM), I spoke with Eliot last
> week. I agree that it is difficult for him to develop a reasonable
> proposal that piggybacks on the SSH draft, because the SSH draft is so
> incomplete.
> 
> I am not convinced that SNMP needs to add a new call-home (CH)
> functionality, nor that this feature is needed in SNMP now, but there
> is a danger that CH might never be possible if we don't consider its
> impact on the SSHSM model before SSHSM is cast in stone. If it
> complicates the SSHSM model, I would prefer to not include it; a new
> model could be developed to replace or supplement the SSHSM model if
> demand increases for this functionality.
> 
> I recommended to Eliot that he contribute some text for the SSH
> document, describing the CH functionality and proposed elements of
> procedure, that I could include as an appendix to the SSHSM document
> so the WG could review his proposal, and then the WG could decide
> whether it should remain as an appendix, be incorporated into the SSH
> document, be split out as a separate document, or be abandoned
> altogether. I felt this was a reasonable alternative to making the
> decision whether CH is or is not in scope at this time. He has not yet
> had a chance to develop the text and send it to me. 
> 
> David Harrington
> [EMAIL PROTECTED]
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] 
> > [mailto:[EMAIL PROTECTED] On Behalf Of Eliot Lear
> > Sent: Monday, September 12, 2005 3:53 PM
> > To: Sam Hartman
> > Cc: IETF Discussion; iesg@ietf.org; [EMAIL PROTECTED]
> > Subject: [Isms] ISMS charter broken- onus should be on WG to fix it
> > 
> > Sam,
> > 
> > I believe the approach you have proposed is quite simply wrong.  As
> an
> > AD you're supposed to provide technical oversight and not 
> > simply hold a
> > popularity contest.  If you have technical questions or wish to
> > challenge me on a technical point, I think that's fair game.
> > 
> > As I've written, the path we are headed down technically will not
> work
> > in the face of firewalls and NATs, and nobody has refuted this.
> > 
> > Furthermore you've heard from a reasonably large customer (Boeing)
> as
> > well as your predecessor on the prevalence of such middle boxes that
> > demonstrates the complexity of today's environment and the 
> > need for this
> > sort of functionality as part of the solution.
> > 
> > You've heard from an author of SNMP that the major 
> > architectural change
> > is the use of session based security and NOT CH, the same from the
> > former O&M AD and IETF chair.  You've heard from a service provider
> as
> > well as numerous members of the community who see the problem.
> > 
> > You may or may not have yet heard from other standards bodies 
> > but if you
> > were to delay it is quite possible they will chime in since one was
> > specifically interested in this sort of function.
> > 
> > The amount of changes required to support CH cannot fully be 
> > ascertained
> > until more of the the [Todo]s are filled in with Dave's draft, but I
> > don't imagine the work would be much more than:
> > 
> >  - specifying how to initiate the connection and if necessary turn
> it
> >  - the identity used for requests received from command 
> > generators that
> >did not initiate the connection along with potential
> prepopulating
> >of various tables
> >  - an appendix of how the SNMP-TARGET-MIB would be populated
> >  - a discussion on when to initiate connections and what to do when
> >they fail (mind you this is needed anyway regardless of CH)
> >  - security considerations involving firewalls, blocking, etc.
> >  - possibly one additional table describing the state of SSH peer
> >connectivity (which probably wouldn't be bad to have anyway).
> > 
> > Decide for yourself if you think this is a substantial amount of
> text,
> > but I won't leave it to your imagination for long.  I will 
> > attempt this
> > week to post a derivative of the draft that Dave is working on to
> give
> > people an idea of what the changes would be.
> > 
> > Again it's difficult to diff an incomplete specification.
> > 
> > Eliot
> > 
> > >>>>>>>>>>> "Eliot" == Eliot Lear <[EMAIL PROTECTED]> writes:
> > > 
> > > 
> > > Eliot> I r

RE: [Isms] ISMS charter broken- onus should be on WG to fix it

[David B Harrington]

Hi,

As primary editor of the SSH draft (SSHSM), I spoke with Eliot last
week. I agree that it is difficult for him to develop a reasonable
proposal that piggybacks on the SSH draft, because the SSH draft is so
incomplete.

I am not convinced that SNMP needs to add a new call-home (CH)
functionality, nor that this feature is needed in SNMP now, but there
is a danger that CH might never be possible if we don't consider its
impact on the SSHSM model before SSHSM is cast in stone. If it
complicates the SSHSM model, I would prefer to not include it; a new
model could be developed to replace or supplement the SSHSM model if
demand increases for this functionality.

I recommended to Eliot that he contribute some text for the SSH
document, describing the CH functionality and proposed elements of
procedure, that I could include as an appendix to the SSHSM document
so the WG could review his proposal, and then the WG could decide
whether it should remain as an appendix, be incorporated into the SSH
document, be split out as a separate document, or be abandoned
altogether. I felt this was a reasonable alternative to making the
decision whether CH is or is not in scope at this time. He has not yet
had a chance to develop the text and send it to me. 

David Harrington
[EMAIL PROTECTED]


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Eliot Lear
> Sent: Monday, September 12, 2005 3:53 PM
> To: Sam Hartman
> Cc: IETF Discussion; iesg@ietf.org; [EMAIL PROTECTED]
> Subject: [Isms] ISMS charter broken- onus should be on WG to fix it
> 
> Sam,
> 
> I believe the approach you have proposed is quite simply wrong.  As
an
> AD you're supposed to provide technical oversight and not 
> simply hold a
> popularity contest.  If you have technical questions or wish to
> challenge me on a technical point, I think that's fair game.
> 
> As I've written, the path we are headed down technically will not
work
> in the face of firewalls and NATs, and nobody has refuted this.
> 
> Furthermore you've heard from a reasonably large customer (Boeing)
as
> well as your predecessor on the prevalence of such middle boxes that
> demonstrates the complexity of today's environment and the 
> need for this
> sort of functionality as part of the solution.
> 
> You've heard from an author of SNMP that the major 
> architectural change
> is the use of session based security and NOT CH, the same from the
> former O&M AD and IETF chair.  You've heard from a service provider
as
> well as numerous members of the community who see the problem.
> 
> You may or may not have yet heard from other standards bodies 
> but if you
> were to delay it is quite possible they will chime in since one was
> specifically interested in this sort of function.
> 
> The amount of changes required to support CH cannot fully be 
> ascertained
> until more of the the [Todo]s are filled in with Dave's draft, but I
> don't imagine the work would be much more than:
> 
>  - specifying how to initiate the connection and if necessary turn
it
>  - the identity used for requests received from command 
> generators that
>did not initiate the connection along with potential
prepopulating
>of various tables
>  - an appendix of how the SNMP-TARGET-MIB would be populated
>  - a discussion on when to initiate connections and what to do when
>they fail (mind you this is needed anyway regardless of CH)
>  - security considerations involving firewalls, blocking, etc.
>  - possibly one additional table describing the state of SSH peer
>connectivity (which probably wouldn't be bad to have anyway).
> 
> Decide for yourself if you think this is a substantial amount of
text,
> but I won't leave it to your imagination for long.  I will 
> attempt this
> week to post a derivative of the draft that Dave is working on to
give
> people an idea of what the changes would be.
> 
> Again it's difficult to diff an incomplete specification.
> 
> Eliot
> 
> >>>>>>>>>>> "Eliot" == Eliot Lear <[EMAIL PROTECTED]> writes:
> > 
> > 
> > Eliot> I request an extension of the deadline for comments to
> > Eliot> September 21st on the following basis:
> > 
> > Eliot>  - the period of comment has been less than a week, far
> > Eliot> shorter than the normal period of IETF-wide review.  -
of
> > Eliot> the time allotted, the principle instigator of 
> this review
> > Eliot> has been absent from debate for five days due to prior
> > Eliot> commitments.  That was me.
> > 
> > Hi, Eliot.  I have not made any determination as yet ab

RE: [Isms] ISMS charter broken- onus should be on WG to fix it

[David B Harrington]

Hi,

Personally, I'd rather see the issue of working through NATs and
firewalls solved at the SSH level, and then SNMP and other SSH-using
applications, such as Netconf and CLI, could use the solution in a
consistent manner. 

The O&M community has gone through a multi-year effort to better
understand operators' needs in network management. That effort started
years ago at an Open O&M meeting. 

Bert and David are tentatively planning another Open O&M meeting at
IETF64. Since the O-side draws more operators than the M-side of O&M,
it might be worthwhile asking the operators that are present at that
meeting if they believe this is an important problem to solve at the
SNMP level, and whether they would prefer it be solved at the SSH
level.

David Harrington
[EMAIL PROTECTED]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Juergen Quittek
> Sent: Monday, September 12, 2005 8:36 PM
> To: Eliot Lear; Sam Hartman
> Cc: [EMAIL PROTECTED]; IETF Discussion; iesg@ietf.org
> Subject: Re: [Isms] ISMS charter broken- onus should be on WG 
> to fix it
> 
> Eliot,
> 
> At the SBSM and ISMS BoF sessions at IETF 58 and 60 the need for
> integrating SNMP into existing security frameworks was extensively
> discussed.  Wes presented the issue at NANOG and performed a survey
> among operators.  The output of all this work is the idenitfication
> of a well founded general requirement for working on the integration
> of SNMP into existing security frameworks in an IETF working group.
> 
> Now you claim that solving this issue is technically wrong without
> considering a different problem that you call "call home".  Rather
> you request adding the issue of solving the "call home" to the ISMS
> charter.
> 
> However, nobody raised this issue at the ISMS BoFs nor has the
> issue been discussed in depth in the OaM area.  But we should have
> such a discussion before adding the issue to any IETF WG charter.
> It looks like a good topic for a BoF session in the OaM area.
> There we could find out the relevance of the problem and discuss
> requirements for potential solutions.  Also there we can identify
> which working group would be the right one to deal with the issue.
> 
> But until then, I propose that we let the ISMS group work on solving
> its original problem.
> 
> Thanks,
> 
> Juergen
> 
> 
> --On 9/12/2005 9:53 PM +0200 Eliot Lear wrote:
> 
> > Sam,
> >
> > I believe the approach you have proposed is quite simply 
> wrong.  As an
> > AD you're supposed to provide technical oversight and not 
> simply hold a
> > popularity contest.  If you have technical questions or wish to
> > challenge me on a technical point, I think that's fair game.
> >
> > As I've written, the path we are headed down technically 
> will not work
> > in the face of firewalls and NATs, and nobody has refuted this.
> >
> > Furthermore you've heard from a reasonably large customer 
> (Boeing) as
> > well as your predecessor on the prevalence of such middle boxes
that
> > demonstrates the complexity of today's environment and the 
> need for this
> > sort of functionality as part of the solution.
> >
> > You've heard from an author of SNMP that the major 
> architectural change
> > is the use of session based security and NOT CH, the same from the
> > former O&M AD and IETF chair.  You've heard from a service 
> provider as
> > well as numerous members of the community who see the problem.
> >
> > You may or may not have yet heard from other standards 
> bodies but if you
> > were to delay it is quite possible they will chime in since one
was
> > specifically interested in this sort of function.
> >
> > The amount of changes required to support CH cannot fully 
> be ascertained
> > until more of the the [Todo]s are filled in with Dave's draft, but
I
> > don't imagine the work would be much more than:
> >
> >  - specifying how to initiate the connection and if 
> necessary turn it
> >  - the identity used for requests received from command 
> generators that
> >did not initiate the connection along with potential 
> prepopulating
> >of various tables
> >  - an appendix of how the SNMP-TARGET-MIB would be populated
> >  - a discussion on when to initiate connections and what to do
when
> >they fail (mind you this is needed anyway regardless of CH)
> >  - security considerations involving firewalls, blocking, etc.
> >  - possibly one additional table describing the state of SSH peer
> >connectivity (w

Re: [Isms] ISMS charter broken- onus should be on WG to fix it

[Juergen Quittek]

Eliot,

At the SBSM and ISMS BoF sessions at IETF 58 and 60 the need for
integrating SNMP into existing security frameworks was extensively
discussed.  Wes presented the issue at NANOG and performed a survey
among operators.  The output of all this work is the idenitfication
of a well founded general requirement for working on the integration
of SNMP into existing security frameworks in an IETF working group.

Now you claim that solving this issue is technically wrong without
considering a different problem that you call "call home".  Rather
you request adding the issue of solving the "call home" to the ISMS
charter.

However, nobody raised this issue at the ISMS BoFs nor has the
issue been discussed in depth in the OaM area.  But we should have
such a discussion before adding the issue to any IETF WG charter.
It looks like a good topic for a BoF session in the OaM area.
There we could find out the relevance of the problem and discuss
requirements for potential solutions.  Also there we can identify
which working group would be the right one to deal with the issue.

But until then, I propose that we let the ISMS group work on solving
its original problem.

Thanks,

   Juergen


--On 9/12/2005 9:53 PM +0200 Eliot Lear wrote:


Sam,

I believe the approach you have proposed is quite simply wrong.  As an
AD you're supposed to provide technical oversight and not simply hold a
popularity contest.  If you have technical questions or wish to
challenge me on a technical point, I think that's fair game.

As I've written, the path we are headed down technically will not work
in the face of firewalls and NATs, and nobody has refuted this.

Furthermore you've heard from a reasonably large customer (Boeing) as
well as your predecessor on the prevalence of such middle boxes that
demonstrates the complexity of today's environment and the need for this
sort of functionality as part of the solution.

You've heard from an author of SNMP that the major architectural change
is the use of session based security and NOT CH, the same from the
former O&M AD and IETF chair.  You've heard from a service provider as
well as numerous members of the community who see the problem.

You may or may not have yet heard from other standards bodies but if you
were to delay it is quite possible they will chime in since one was
specifically interested in this sort of function.

The amount of changes required to support CH cannot fully be ascertained
until more of the the [Todo]s are filled in with Dave's draft, but I
don't imagine the work would be much more than:

 - specifying how to initiate the connection and if necessary turn it
 - the identity used for requests received from command generators that
   did not initiate the connection along with potential prepopulating
   of various tables
 - an appendix of how the SNMP-TARGET-MIB would be populated
 - a discussion on when to initiate connections and what to do when
   they fail (mind you this is needed anyway regardless of CH)
 - security considerations involving firewalls, blocking, etc.
 - possibly one additional table describing the state of SSH peer
   connectivity (which probably wouldn't be bad to have anyway).

Decide for yourself if you think this is a substantial amount of text,
but I won't leave it to your imagination for long.  I will attempt this
week to post a derivative of the draft that Dave is working on to give
people an idea of what the changes would be.

Again it's difficult to diff an incomplete specification.

Eliot


"Eliot" == Eliot Lear <[EMAIL PROTECTED]> writes:



Eliot> I request an extension of the deadline for comments to
Eliot> September 21st on the following basis:

Eliot>  - the period of comment has been less than a week, far
Eliot> shorter than the normal period of IETF-wide review.  - of
Eliot> the time allotted, the principle instigator of this review
Eliot> has been absent from debate for five days due to prior
Eliot> commitments.  That was me.

Hi, Eliot.  I have not made any determination as yet about whether I
will pull ISMS from the Thursday telechat and am unlikely to make a
final determination until the time of that telechat.


When I originally ruled call home out of scope I gave you some
suggestions for how to approach things from a process standpoint.  In
evaluating your request I will consider how much progress has been
made on these issues so far and on whether it is likely that you could
make additional progress on these issues by September 21.

Let us go back and consider my original advice to you:

  When the charter is sent to me for IESG review, ask me to send it out
  for external review (IETF wide) rather than just approving it; I will
  honor such a request.  You will need a proposal ready to present to
  the community when the charter comes out for review.  The proposal
  should include proposed modifications to the charter to make call home
  in scope.  In addition you probably want to answer the follo