Re: Blue Sheet Change Proposal

[john . loughney]

Surely there must be easier ways to get email addresses.

John

Sent from my Nokia N96.

-original message-
Subject: Re: Blue Sheet Change Proposal 
> We are considering changing the meeting Blue Sheet by eliminating the 
> need to enter an email address to avoid spam concerns.
> 
> Is there any good reason to retain that info bit?
> 
> Ray

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

Re: Scheduling unpleasantness

[John Loughney]

Harald,

Even a simpler solution.  If you (meaning Iljitsch) had serious conflicts,
then let the WG chairs know about these conficts.  They may may not on the
WG Chairs' radars.  That has happened to me, where WG members were
overlapping with groups that I was unaware of.

John

On Mon, Mar 24, 2008 at 8:58 PM, Harald Tveit Alvestrand <
[EMAIL PROTECTED]> wrote:

> Diving into solutions space
>
> The WG scheduling tool has 3 lists of "groups to avoid conflicts with",
> 1st, 2nd and 3rd priority.
>
> I don't know if these are visible to anyone but the requesting WG Chair,
> but they're listed on the confirmation notice from the tool; I've made
> it a practice to copy them to the WG I schedule, and modify the list
> according to comments.
>
> So I'd ask:
>
> Were the meetings you had problems with listed in each others' conflicts
> list?
>  - If not, it's a problem at the "data input" level.
>  - If yes, it's a problem at the "conflicts resolutions" level.
>
> The solution to the problem depends on where the problem is, of course.
>
> (Note: Conflicts at some level are unavoidable. Even bad conflicts. But
> if we can give the secretariat good data to figure out what those
> conflicts are, we're one step ahead.)
>
>  Harald
>
>
>
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

are we the ISDTF? was: Let's look at it from an IETF oldie's perspective... Re: IPv4 Outage Planned for IETF 71 Plenary

[john . loughney]

Are we the Internet Standardization Development Task Force? It seems by this 
thread, many of us are afraid to do any engineering and just work on emails and 
paper.   
I don't know about others, but I always liked testing some new technology at 
IETF meetings, but that seems less common these days.
John


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

Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity

[john . loughney]

+1

-original message-
Subject: Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity
From: Keith Moore <[EMAIL PROTECTED]>
Date: 07/05/2007 11:59 AM


> There are basically two types of applications/protocols: the simple
> client/server ones (that work through NAT without changes) and
> anything else that's more complex. In my opinion, it would be a huge
> win to allow the former to work through some kind of IPv6-IPv4
> translation because then all the hosts that only use these types of
> applications don't need IPv4 anymore and life becomes simple for the
> people who need to manage these hosts. 
that's the kind of thinking that polluted the IPv4 network with NATs. 
the problem is that those simple applications share the same hosts and
network that the other applications do.  if you put devices in the
network that only solve problems for the simple applications, then you
get a network that can only run simple applications.


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


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

Re: Fwd: Pingsta Invitation

[john . loughney]

Not that I am advocating this particular site, but I would suggest that we are 
fairly poor engineers if we don't at least try some new forms of networking.

I don't care what that  Alexander Graham Bell says, I'm sticking to the 
telegraph and Morse Code :)

Sent from my Nokia E90.

-original message-
Subject: Re: Fwd: Pingsta Invitation
From: John Levine <[EMAIL PROTECTED]>
Date: 03/24/2007 8:54 am

>It does appear to be a legitimate attempt at a niche social networking 
>site targeting networking engineers, but I'm not sure we need one.

If we can't do social networking via existing communication channels
like, you know, e-mail, we're pretty lousy networking engineers.

Regards,
John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for 
Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

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


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

Re: Warning - risk of duty free stuff being confiscated on the way to Prague

[john . loughney]

It varies from place to place. I've seen people have their duty free bags 
confiscated at Frankfurt for purely internal European flights. It seems that 
the rules change weekly. Like Harald says, last hop is the only sure thing. No 
transitive trust in airport  security these days.

John

-original message-
Subject: Re: Warning - risk of duty free stuff being confiscated on the way to 
Prague
From: Harald Alvestrand <[EMAIL PROTECTED]>
Date: 03/12/2007 7:37 am

I've seen people get through security with duty free bottles.
But that requires that the bottles are sealed in a clear plastic bag, 
and that you can plainly see the receipt from the duty free store you 
bought them at through the plastic (the receipt has to be INSIDE the bag).

Last hop does it. Or, in the ultimate acknowledgement of the silliniess 
of "duty free alcohol", your destination may do like Norway does, and 
let you buy your "duty free export" *after landing*.

Harald

Brian E Carpenter wrote:
> It is reported by The Economist dated March 10 that if you buy duty 
> free liquids outside Europe, carry them on the plane with you, and 
> have to go through airport security while changing planes in Europe, 
> your liquids will be confiscated, assuming they exceed 100 ccs.
>
> Europe in this case means the EU plus Norway, Iceland and Switzerland. 
> If you are flying from anywhere else to Prague and changing planes in 
> Europe, this will certainly apply at major airports such as London 
> Heathrow, Paris CDG, etc., and wherever international transit 
> passengers must go through security checkpoints.
>
> To avoid losing your alcohol or perfume, they need to be in your 
> checked baggage.
>
> Brian
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>


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


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

lost SecureID card

[john . loughney]

If anyone found a SecureID card last night, in Grande B (or elsewhere) please 
let me know.

thanks,
John

sent from my Nokia 61.


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

Re: RFC Author Count and IPR

[John Loughney]

Andy,

For what it's worth, I agree with you. Having a single editor simplifies many 
things, but having a authors list allows full credit to all parties.

John 

- original message -
Subject:Re: RFC Author Count and IPR
From:   Andy Bierman <[EMAIL PROTECTED]>
Date:   05/24/2006 7:19 pm

David Harrington wrote:
> If I remember correctly, we only limit the number of suthors on the
> first page of the document. 
> 
> It is perfectly acceptable to list a longer set of names inside the
> document in an contributors section.

It's not just the first page.
It also affects the reference citation used in
the RFC Index and all other RFCs.

I believe the 5 author rule was used as justification to remove
most of the original SNMPv2 authors from the author list and all
further reference citations, when the RFC 1901-1909 series was
advanced.  I don't really understand what purpose this serves.


> 
> I also have concerns about who should be listed as an "author" and
> have copyrights when a work is developed by a WG. The demand to do
> things with IETF documents beyond IETF standards work seems to be
> growing, so it will be an increasingly difficult problem if we do not
> identify all the people who contributed significant portions of a
> document (where significant is of course open to debate).

There is a problem with companies piling on the authors
for I-D proposals to make it look like lots of people
worked really hard on it and all agree on the contents.
(This is hardly ever the case.)

Then when you go to WG draft, there are already 5 or 7 names
as authors, and the WG wants to add more.  I think then, you
have to pick a real Editor (responsible for all edits all
the way through AUTH48) and just list that person as Editor
on the first page and citations, and put everybody in
the Authors section in the back.

IMO, this is different than removing the author(s) of a previous
version of an RFC.  I object to that practice.


> 
> dbh

Andy

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


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

Re: IPv6 Subsets?

[john . loughney]

I agree with Jari, having subsets doesn't seem like a good idea. Most use cases 
for specific deployments seem to be very limited, and arguments can be made as 
to why a more general purpose IPv6 would be a better choice.
John

- original message -
Subject:Re: IPv6 Subsets?
From:   Jari Arkko <[EMAIL PROTECTED]>
Date:   04/19/2006 8:15 am

RFC 4294 contains the most recent summary information
on what nodes should support from IPv6. The detailed
MUST/SHOULD/MAY requirements are in the IPv6
specifications themselves.

(RFC 3316 that Juha pointed to is a discussion of issues
related to running IPv6 over cellular interfaces. The
type of the interface that you are using does impact what
you need to support, at least in terms of what IPv6 over
Foo you need to support, what configuration options
make sense, etc.)

--Jari


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


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

Re: RE: Stupid NAT tricks and how to stop them.

[John Loughney]

Lars-Erik,

> > From: Michel Py [mailto:[EMAIL PROTECTED]
> > Unfortunately some protocol purity zealots still have to realize
> > that Linksys, Netgear, Belkin and consorts don't sell NAT boxes
> > because they think NAT is good, they sell NAT boxes because
> > consumers want to buy them. 
> 
> I do not think consumers in general want to buy NAT boxes, but
> they are forced to do so by ISP's who do not give them a choice.

We're over-analyzing things. The last 3 WLAN APs I bought had NAT on by 
default; 2 of them it was impossible to turn this off.  I got into long 
discussions with tech support who were telling me it is impossible to design a 
WLAN AP-router combo that didn't NAT.  

My DSL provier offers me 5 DHCP address for free (consumer grade connection) 
and my mobile carrier is now using real IP address for GPRS (they had too many 
problems caused by NATed IP addresses).  

In practice, I've needed to power-cycle these NAT boxes every few weeks, to 
clear out the garbage.  The most common things most ISP tech support lines are 
"unplug your router/AP/box", count to 60 and plug it back in.  

However, if I am just a normal user, go to Best Buy and pickup a home WLAN 
Access Point, I'll have a NAT by default.  There is no "NAT inside" logo on the 
box, nor are there clear instructions on how to turn this off.  Vendors have 
turned NAT on by default because it is easier for them; not because the market 
has asked them to.

As for reference, my local paper started, computer stores started advertising 
"NAT firewalls" around 1998-99.  When NATs first came to a the market, the 
marketing message was that NATs provided a security feature.  Still, I have far 
too many tech support discussions where there is common confusion between NAT & 
firewall features.  I don't think it is really intellectually honest to say the 
market has chosen NATs because it is what they wanted - it is a band-aid fix 
for a couple of different problems, which it kind of solved, but creates some 
ugly side effects.  

To get around these side effects, people are deploying ALRs, B2BUA and SBCs to 
help fix the side-effects (and to do other things).  Human nature being what it 
is, we'll probably keep applying these quick fixes, until it gets far to messy 
and someone comes in and wipes these away with a new solution.  Circuit 
switching, ATM, ISDN, etc. all have been useful for some solutions - but when 
you try to go beyond what they have been designed for, you tend to have to 
apply patches and hacks to get things working.

John


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

Re: Jabber chats (was: 2 hour meetings)

[john . loughney]

Maybe we should leave the Jabber meeting rooms up all the time, and use them 
for more dynamic discussions.
John

- original message -
Subject:Re: Jabber chats (was: 2 hour meetings)
From:   Stig Venaas <[EMAIL PROTECTED]>
Date:   03/24/2006 5:01 pm

Hallam-Baker, Phillip wrote:
>> From: Tim Chown [mailto:[EMAIL PROTECTED] 
> 
>> Well, if we make remote participation too good, we may end up 
>> with rather empty meeting rooms and a bankrupt IETF ;)
>>  
>> What we should do, given the rush of work that happens pre-ID 
>> cutoff, is maybe look at such technology for interim 
>> meetings, and have the IETF support some infrastructure to 
>> help interim meetings run more
>> effectively, maybe even without a physical meeting venue.   Some WGs
>> might then run more interim virtual meetings and help 
>> distribute the workload over the year more smoothly.
> 
> You mean like holding a bi-weekly teleconference?
> 
> VOIP is getting to the point where this is practical. 

Personally I find jabber (and similar technologies) much more convenient
than voice. I've used that a few times with a small group of people to
discuss and solve technical problems. I feel it allows more interactive
discussions and is also easier non-native English speakers,

I think using the wg jabber rooms we got for regular discussions of
specific issues is a great idea.

Stig

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


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


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

RE: Venue requirements - canoe?

[john . loughney]

Transport over flooded routes. Sounds like a plenary topic to me.
John

- original message -
Subject:RE: Venue requirements - canoe?
From:   "Gray, Eric" <[EMAIL PROTECTED]>
Date:   03/20/2006 4:14 pm

Sounds to me like this comes under the Transport Area - at least
as far as flooding control is concerned.  Avoidance of flooded
paths, on the other hand, might be a routing Area problem.

--> -Original Message-
--> From: Steven M. Bellovin [mailto:[EMAIL PROTECTED] 
--> Sent: Monday, March 20, 2006 11:09 AM
--> To: Tim Chown
--> Cc: ietf@ietf.org
--> Subject: Re: Venue requirements - canoe?
--> 
--> We clearly need to tell the Routing Area to work on better flooding
--> algorithms.
--> 
--> --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
--> 
--> ___
--> Ietf mailing list
--> Ietf@ietf.org
--> https://www1.ietf.org/mailman/listinfo/ietf
--> 

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


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

GenArt LC review of DHCP Server Identifier Override Suboption

[john . loughney]

I was selected as General Area Review Team reviewer for this
specification (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-override-03.tx
t

My feeling is that this document needs some revision, at least to cover
the IANA section, and perhaps my point raised about the introduction.

1) Intro says:

   There are many situations where the DHCP relay is involved and can
   insert a relay agent option with appropriate suboptions easily into
   DHCP DISCOVER messages.  

Of course, this begs the question - what are those situations?  Anyhow,
I think the intro is a bit short on motivation for this suboption.

2) IANA Section says:

5.  IANA Considerations

   IANA is requested to assign a suboption number for the Server
   Identifier Override Suboption from the DHCP Relay Agent Information
   Option [3] suboption number space.  None.


I don't understand what the 'None.' refers to.

John

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

Re: Re: how to declare consensus when someone ignores consensus

[John Loughney]

> On 01/22/2006 22:27 PM, John Loughney allegedly wrote:
> > Look at various peer-to-peer protocols as a good
> > examples of things that people use everyday, but wouldn't stand a
> > chance of getting an RFC.
> 
> Why not?

Now we're close to side veering off into process issues, but rather than going 
into that rat-hole, I'll just pose a question: do you think p2p protocol 
authors would have any motiviation to create a Security Considerations section 
that would pass IESG review?

John


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

how to declare consensus when someone ignores consensus

[John Loughney]

I am growing tired of this meta-discussion, but I just needed to add my 2 
cents, then I'll be quiet.

As someone who really wants to get work done, I find it very hard to get the 
work done when someone posts seemingly random comments, or at least is using 
argumentation that doesn't seem to have any other support in the working group. 
 I cannot say if this is what Jefsey is doing, as I am not active in any of the 
WGs in question.

What I do know, is that from time to time, on most working groups, someone pops 
in and derails forward progress. In my mind, we do need a mechanism to prevent 
this from happening.  Perfection is the enemy of the good in many, many cases.  
We are the Internet 'Engineering' Task Force, we don't promise that we are 
always right - that's why we have three levels of standards.

People who suggest ignoring or hitting delete don't seem to really get it - as 
a working chair, I need to continually try to maintain forward motion on 
technical issues, sometimes someone shows up with what seems like an axe to 
grind or is trolling for attention.  I think we need mechanisms to be able to 
divert people who continuously disrespect rough consensus from continuing to 
disrupt the on-going work. 

The IETF doesn't have a strangle-hold on the Internet - there are other 
standardization bodies out there, and noone is preventing people from going out 
and designing their own solutions, outside of the IETF.  Look at various 
peer-to-peer protocols as a good examples of things that people use everyday, 
but wouldn't stand a chance of getting an RFC.

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

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

Re: Question about the Neustar logo on www.ietf.org

[john . loughney]

Brian,

I have no problem with it being there. I just thought the scale was a bit off 
... The main page is a bit spartan by design, so I think we should keep it 
simple.

John

- original message -
Subject:Re: Question about the Neustar logo on www.ietf.org
From:   Brian E Carpenter <[EMAIL PROTECTED]>
Date:   01/02/2006 4:07 pm

Harald Tveit Alvestrand wrote:
> 
> 
> --On mandag, januar 02, 2006 16:25:59 +0200 John Loughney 
> <[EMAIL PROTECTED]> wrote:
> 
>> Hi all,
>>
>> Just out of curiosity, when browsing www.ietf.org, I noticed that the
>> Neustar logo on www.ietf.org is larger than the ISOC logo.  Any
>> particular reason why?  It just kind of jumps out at you 
> 
> 
> They seem to have it in place of the word "Neustar" CNRI used to 
> have their name there, and no logo. CNRI's had its name there at least 
> since 1996, so it's kind of traditional to name the operator.
> 

It's traditional, and I think fair. I'll ask the IAD to see if we can get the 
scale
adjusted.

 Brian



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

Re: Question about the Neustar logo on www.ietf.org

[john . loughney]

Brian,

I have no problem with it being there. I just thought the scale was a bit off 
... The main page is a bit spartan by design, so I think we should keep it 
simple.

John

- original message -
Subject:Re: Question about the Neustar logo on www.ietf.org
From:   Brian E Carpenter <[EMAIL PROTECTED]>
Date:   01/02/2006 4:07 pm

Harald Tveit Alvestrand wrote:
> 
> 
> --On mandag, januar 02, 2006 16:25:59 +0200 John Loughney 
> <[EMAIL PROTECTED]> wrote:
> 
>> Hi all,
>>
>> Just out of curiosity, when browsing www.ietf.org, I noticed that the
>> Neustar logo on www.ietf.org is larger than the ISOC logo.  Any
>> particular reason why?  It just kind of jumps out at you 
> 
> 
> They seem to have it in place of the word "Neustar" CNRI used to 
> have their name there, and no logo. CNRI's had its name there at least 
> since 1996, so it's kind of traditional to name the operator.
> 

It's traditional, and I think fair. I'll ask the IAD to see if we can get the 
scale
adjusted.

 Brian



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

Question about the Neustar logo on www.ietf.org

[John Loughney]

Hi all,

Just out of curiosity, when browsing www.ietf.org, I noticed that the Neustar 
logo on www.ietf.org is larger than the ISOC logo.  Any particular reason why?  
It just kind of jumps out at you 

John


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

Re: Re: Please make sure that you do not run your WLAN in ad hoc mode

[John Loughney]

Joel,

> You can,(we've done it in the past) but since they're not actually 
> connected to the network when they're misbehaving it doesn't buy you much 
> until they fix their card, sleep their laptop, or reboot.
> 
> Having done some testing with various Operating systems wireless 
> implmentations, I think we can say with some degree of confidence the 
> instigating hosts are generally windows 2000 machines, it could be time to 
> upgrade because the winxp ndis wireless drivers won't do this without some 
> coaxing. Or, I'd be happy to hand out knoppix cd's to anyone who wants 
> one.

Do you have a sense if it is Win 2000 or if it is related to any specific wlan 
driver software?  I'd think a basic list of cards / sw that often misbehave 
would be a good thing.  That way, when we see a few adhoc devices in a meeting, 
the chairs could more specifically tell people running OS X / card Y to check 
their devices. 

John


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

Re: RE: IETF Meeting Venue Selection Criteria - Other health risks

[John Loughney]

Eric,

Things vary country to country. You can get contradictory information based 
upon what country you are currently in & what one you are traveling to.  Having 
lived abroad a number of years, I have gotten 'official' but contradictory 
information about vacinations, etc. depending upon the source.  This is not 
something we need to cover in any kind of RFC, IMO.

John
> 
> From: "Gray, Eric" <[EMAIL PROTECTED]>
> Date: 2005/10/24 Mon PM 06:50:09 EEST
> To: "'John Loughney'" <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED],  "'ietf@ietf.org'" 
> Subject: RE: IETF Meeting Venue Selection Criteria - Other health risks
> 
> John,
> 
>   Cover it or not, I certainly hope that meeting organizers
> take these things into account.  Visiting some countries can
> make it impossible to visit others, at least for a certain time.
> For example, many Asian countries will not grant a visa to any
> body who has been in Africa recently.  Or at least this used to
> be the case...
> 
>   Also, it is irresponsible for anyone to organize a meeting
> in a country where innoculation is required for entry without
> making an announcement - or including that information in other
> announcements - to that effect.  I can well imagine that such an
> announcement can be expected to prevent some people from going 
> to such a meeting.
> 
> --
> Eric Gray
> 
> --> -Original Message-
> --> From: [EMAIL PROTECTED] 
> --> [mailto:[EMAIL PROTECTED] Behalf Of
> --> John Loughney
> --> Sent: Sunday, October 23, 2005 1:42 AM
> --> To: [EMAIL PROTECTED]; ietf@ietf.org
> --> Subject: Re: IETF Meeting Venue Selection Criteria - Other 
> --> health risks
> --> 
> --> 
> --> I believe this to be over specification, I don't think we 
> --> should cover this.
> --> > 
> --> > From: JORDI PALET MARTINEZ <[EMAIL PROTECTED]>
> --> > Date: 2005/10/22 Sat AM 03:16:37 EEST
> --> > To: "ietf@ietf.org" 
> --> > Subject: IETF Meeting Venue Selection Criteria - Other 
> --> health risks
> --> > 
> --> > Elwyn raised an interesting point in my opinion:
> --> > 
> --> > Even if visas are not required, are there any health 
> --> checks at immigration ?
> --> > Would participants need vaccinations before attending ?
> --> > 
> --> > My conclusion is:
> --> > 
> --> > It should be considered as a handicap if there is any 
> --> high risk of health
> --> > impact for the participants (such as malaria or other 
> --> infections or
> --> > mandatory health checks at immigration). This would be 
> --> acceptable if the
> --> > vaccination of the participants is not going to impact 
> --> the attendance and in
> --> > any case, appropriate recommendations about vaccinations 
> --> and mandatory
> --> > health checks should be provided ahead the meeting, in 
> --> advance enough for
> --> > all the participants to take appropriate measures.
> --> > 
> --> > Comments ?
> --> > 
> --> > Regards,
> --> > Jordi
> --> > 
> --> > 
> --> > 
> --> > 
> --> > 
> --> > 
> --> > 
> --> > The IPv6 Portal: http://www.ipv6tf.org
> --> > 
> --> > Barcelona 2005 Global IPv6 Summit
> --> > Information available at:
> --> > http://www.ipv6-es.com
> --> > 
> --> > This electronic message contains information which may be 
> --> privileged or confidential. The information is intended to 
> --> be for the use of the individual(s) named above. If you are 
> --> not the intended recipient be aware that any disclosure, 
> --> copying, distribution or use of the contents of this 
> --> information, including attached files, is prohibited.
> --> > 
> --> > 
> --> > 
> --> > 
> --> > ___
> --> > Ietf mailing list
> --> > Ietf@ietf.org
> --> > https://www1.ietf.org/mailman/listinfo/ietf
> --> > 
> --> 
> --> 
> --> ___
> --> Ietf mailing list
> --> Ietf@ietf.org
> --> https://www1.ietf.org/mailman/listinfo/ietf
> --> 
> 


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

Re: Re: IETF Meeting Venue Selection Criteria

[John Loughney]

Dave,

> Is that hope for future participation by new attendees an acceptable 
> basis for making venue choices that hurt current participation by 
> primary contributors? 
> 
> What is the evidence that we will not gain that new participation 
> without hurting current participation by primary contributors?

The working groups I chair have particpants from Asia, Europe & North America.  
I don't see many places, outside of Antarctica, that would cause all of the 
active contributors an equal amount of travel pain.  I really think this is a 
non-issue for the IETF as a whole.

John


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

Re: Re: IETF Meeting Venue Selection Criteria - weather conditions

[John Loughney]

Jordi,

All of the points, IMO, are over specifying the issues.  I wouldn't really care 
to see any of these points documented.

John
> 
> From: JORDI PALET MARTINEZ <[EMAIL PROTECTED]>
> Date: 2005/10/22 Sat AM 03:05:59 EEST
> To: "ietf@ietf.org" 
> Subject: Re: IETF Meeting Venue Selection Criteria - weather conditions
>  and related
> 
> Hi all,
> 
> I'm trying to summarize and comment the different threads that have received
> some input on this document during the last days.
> 
> This is the 1st thread (others to follow), related to weather conditions for
> the venue.
> 
> I think, reading the different comments, the conclusion is that:
> 
> 1) Outdoor temperature during the meeting above 0 degrees Centigrade and
> below 40.
> 
> 2) Expected weather is not going to produce a high risk of transport
> disruption (for example hurricanes, typhoons, etc.).
> 
> 3) The venue must be able to maintain a sensible temperature/humidity in the
> conference rooms and meeting areas in general (20-23 deg. C, 50% relative
> humidity). Specially important for the venue cooling system to consider the
> side effect of 80% of people plugging-in their laptops dissipating an extra
> 150-200 watts of heat into the room over and above what the human body does.
> 
> My personal view is that 2 and 3 are very important, but I'm not so sure
> about 1. Other comments ?
> 
> Regards,
> Jordi
> 
> 
> 
> 
> > De: "Hallam-Baker, Phillip" <[EMAIL PROTECTED]>
> > Responder a: <[EMAIL PROTECTED]>
> > Fecha: Thu, 13 Oct 2005 17:35:59 -0700
> > Para: <[EMAIL PROTECTED]>, 
> > Conversación: IETF Meeting Venue Selection Criteria
> > Asunto: RE: IETF Meeting Venue Selection Criteria
> > 
> > How about adding that the mean outdoor temperature at the time of the
> > year the meeting is being held should be above 0 degrees Centigrade?
> > 
> >> -Original Message-
> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> >> Behalf Of JORDI PALET MARTINEZ
> >> Sent: Thursday, October 13, 2005 6:30 PM
> >> To: ietf@ietf.org
> >> Subject: IETF Meeting Venue Selection Criteria
> >> 
> >> Hi all,
> >> 
> >> I've not seen the announcement yet, but it has been published:
> >> 
> >> http://www.ietf.org/internet-drafts/draft-palet-ietf-meeting-v
> >> enue-selection
> >> -criteria-00.txt
> >> 
> >> I hope we have a lot of comments and constructive inputs !
> >> 
> >> Remember, this document defines WHERE our next meeting will
> >> happen and under what conditions those venues are selected,
> >> so is important for all of us, right ?
> >> 
> >> Regards,
> >> Jordi
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> The IPv6 Portal: http://www.ipv6tf.org
> >> 
> >> Barcelona 2005 Global IPv6 Summit
> >> Information available at:
> >> http://www.ipv6-es.com
> >> 
> >> This electronic message contains information which may be
> >> privileged or confidential. The information is intended to be
> >> for the use of the individual(s) named above. If you are not
> >> the intended recipient be aware that any disclosure, copying,
> >> distribution or use of the contents of this information,
> >> including attached files, is prohibited.
> >> 
> >> 
> >> 
> >> 
> >> ___
> >> Ietf mailing list
> >> Ietf@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/ietf
> >> 
> >> 
> > 
> > ___
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ietf
> 
> 
> 
> 
> 
> The IPv6 Portal: http://www.ipv6tf.org
> 
> Barcelona 2005 Global IPv6 Summit
> Information available at:
> http://www.ipv6-es.com
> 
> This electronic message contains information which may be privileged or 
> confidential. The information is intended to be for the use of the 
> individual(s) named above. If you are not the intended recipient be aware 
> that any disclosure, copying, distribution or use of the contents of this 
> information, including attached files, is prohibited.
> 
> 
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 


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

Re: IETF Meeting Venue Selection Criteria - Other health risks

[John Loughney]

I believe this to be over specification, I don't think we should cover this.
> 
> From: JORDI PALET MARTINEZ <[EMAIL PROTECTED]>
> Date: 2005/10/22 Sat AM 03:16:37 EEST
> To: "ietf@ietf.org" 
> Subject: IETF Meeting Venue Selection Criteria - Other health risks
> 
> Elwyn raised an interesting point in my opinion:
> 
> Even if visas are not required, are there any health checks at immigration ?
> Would participants need vaccinations before attending ?
> 
> My conclusion is:
> 
> It should be considered as a handicap if there is any high risk of health
> impact for the participants (such as malaria or other infections or
> mandatory health checks at immigration). This would be acceptable if the
> vaccination of the participants is not going to impact the attendance and in
> any case, appropriate recommendations about vaccinations and mandatory
> health checks should be provided ahead the meeting, in advance enough for
> all the participants to take appropriate measures.
> 
> Comments ?
> 
> Regards,
> Jordi
> 
> 
> 
> 
> 
> 
> 
> The IPv6 Portal: http://www.ipv6tf.org
> 
> Barcelona 2005 Global IPv6 Summit
> Information available at:
> http://www.ipv6-es.com
> 
> This electronic message contains information which may be privileged or 
> confidential. The information is intended to be for the use of the 
> individual(s) named above. If you are not the intended recipient be aware 
> that any disclosure, copying, distribution or use of the contents of this 
> information, including attached files, is prohibited.
> 
> 
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 


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

Re: Re: IETF Meeting Venue Selection Criteria

[John Loughney]

Dave, Jordi,

I think this is a non-issue.  If participants are motivated, they will show-up. 
If their employer values their work, they will cover the meeting costs.  Other 
SDOs have more extensive travel destinations than the IETF, and participants in 
those organizations cope.  The IETF is an global body we just have to deal with 
that.

I dislike the 'primary contributors' concept very, very much.  What it is 
saying is that there are participants, but only a few of them really matter, 
and that it is possible to measure this.  In working groups I have chaired, 
we've had a pretty good dispersal of active contributors, but the active 
contributors have come and gone & sometimes come back again.  

If some active contributors can't make an IETF meeting because of location, and 
forward progress is needed, have an interim meeting at a more agreeable 
location.
John
> 
> From: JORDI PALET MARTINEZ <[EMAIL PROTECTED]>
> Date: 2005/10/22 Sat AM 04:43:48 EEST
> To: "ietf@ietf.org" 
> Subject: Re: IETF Meeting Venue Selection Criteria
> 
> Hi Dave,
> 
> While I see your point, and certainly agree in some degree, I also think
> that any of the measures to look into who are "primary contributors" will
> turn to be unfair and subjective.
> 
> In a so big community this kind of measurement will never work well, unless
> everyone has the right to speak up for the venue selection, which will turn
> to be absolutely impractical.
> 
> Just one example from your own one, not to be taken as any personal issue.
> Why you have been queried for a schedule conflict (by the way "secretly")
> while others have not had the opportunity for that (including myself) ?.
> Clearly is not fair and is not consensus based, good or not, it may turn in
> being the only realistic way and always could mean people being limited to
> attend for this. How you know if there is much more people not being able to
> attend because those who had been surveyed are able to attend and how you
> measure how many of them are "more" primary contributors ?
> 
> Regards,
> Jordi
> 
> 
> 
> 
> > De: Dave Crocker <[EMAIL PROTECTED]>
> > Organización: Brandenburg InternetWorking
> > Responder a: <[EMAIL PROTECTED]>
> > Fecha: Thu, 20 Oct 2005 08:43:33 -0700
> > Para: Brian E Carpenter <[EMAIL PROTECTED]>
> > CC: "ietf@ietf.org" 
> > Asunto: Re: IETF Meeting Venue Selection Criteria
> > 
> > Brian,
> > 
>  What is the evidence that we will not gain that new
>  participation without hurting current participation
>  by primary contributors?
> >> It's very hard to get those data... There is no objective way to
> >> identify 'primary
> >> contributors' other than by assuming the regular attendees are
> >> also contributors.
> >> ...
> >> Which, BTW, means income that we badly need.
> >> ...
> >> We also badly need hosts for financial reasons.
> > 
> > Unfortunately, the ultimate and practical meaning, of these kinds of
> > conclusions about venue selection, is that we do not place productivity
> > as a high priority.  We have a collection of other priorities that take
> > precedence, for a collection of reasons. This means that the impact of
> > face-to-face meetings, on productivity and quality, is almost entirely a
> > matter of luck.
> > 
> > I should note that this is a similar problem with respect to Nomcom
> > member selection:  We use highly indirect criteria, because they are
> > easy to administer, but which are certain to have poor correlation with
> > member expertise about IETF management -- although IETF management is
> > what is being chosen -- and then we hope for the best.
> > 
> > It is interesting that essentially all public discussion of these sorts
> > of stategic issues and the criteria for pursuing them almost always
> > focuses on what is easy or already established, rather than what will
> > work best for achieving the desired result.  In particular, negative
> > implications appear to be entirely ignored, such as the one Eric Rosen
> > just pointed out, about encouraging participation by professional
> > standards goers.
> > 
> > For an organization that claims to care about the quality of its work
> > product, this all seems a rather strange approach to its management.
> > 
> > I suspect that organizations rarely achieve their primary goals by
> > making strategic and tactical decisions that ignore those goals.
> > 
> > d/
> > 
> > p.s.  "Primary contributors" could be operationally defined as previous
> > IETF attendees who are authors or chairs of current work.  One might
> > always want to factor in mailing list activity levels for some
> > individuals, but that's also an indirect measure.  However, all involve
> > objective data that are available.  An additional approach is a
> > variation on something that is already done:  Currently, some
> > participants are queried for schedule conflicts within the IETF week.
> > That could be extended to "venue conflicts" which would prevent them
> > from attending at all.And 

Re: IETF Meeting Venue Selection Criteria - transport

[John Loughney]

Jordi,

This is over specifying, IMO.  I'd simply say that:

Locations should be near a major airport with sufficient local transportation.

John
> 
> From: JORDI PALET MARTINEZ <[EMAIL PROTECTED]>
> Date: 2005/10/22 Sat PM 06:16:44 EEST
> To: "ietf@ietf.org" 
> Subject: IETF Meeting Venue Selection Criteria - transport
> 
> According to the inputs received on the airport, I think we should say
> something such as:
> 
> The airport and/or other wide area transport means need to have adequate
> capacity and decent connections.
> 
> It is expected that there's easy and inexpensive transportation from the
> nearby airports to the meeting site. Typically this implies an airport under
> 50 kilometer's distance and the availability of public transportation and/or
> affordable taxi services.
> 
> The airport should have adequate capacity considering the number of expected
> attendees arriving and departing, for example with sufficient number of
> scheduled flights and avoiding bottlenecks due to local immigration
> practices.
> 
> The traveling to the venue location should be possible with a maximum of one
> flight hop from a major hub. The airport must have a diversity of
> international carriers.
> 
> Comments ?
> 
> Regards,
> Jordi
> 
> 
> 
> 
> 
> 
> 
> The IPv6 Portal: http://www.ipv6tf.org
> 
> Barcelona 2005 Global IPv6 Summit
> Information available at:
> http://www.ipv6-es.com
> 
> This electronic message contains information which may be privileged or 
> confidential. The information is intended to be for the use of the 
> individual(s) named above. If you are not the intended recipient be aware 
> that any disclosure, copying, distribution or use of the contents of this 
> information, including attached files, is prohibited.
> 
> 
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 


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

Question about Real-time Applications and Infrastructure (RAI) Area

[john . loughney]

Brian,

Just wondering - is there any changes in the Transport Area, other
than the movement of the existing WGs (listed below) from the Transport
area?

It might be good to have this information posted somewhere on the the
IETF page.

thanks,
John

---

Creation of the Real-time Applications and Infrastructure (RAI) Area

The IESG is grateful for the useful comments received on
the proposal to create an RAI Area (see
http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01566.htm
l
for the original proposal).

After integrating those comments and carefully considering the
arguments both in favour and against, the IESG has decided to
create the new area starting in March 2006 and has duly informed
the NomCom Chair. The revised area description is attached below.

One concern expressed was about the impact of increasing
the number of Area Directors on the IESG's efficiency. The IESG takes
this concern seriously and we intend soon to discuss operational and
organisational changes to deal with it.

   Brian Carpenter for the IESG

---
Real-time Applications and Infrastructure Area:

The Real-Time Applications and Infrastructure Area develops protocols
and architectures for delay-sensitive interpersonal communications
Work in this area serves an industry whose  applications and services
include
voice and video over IP, instant messaging  and presence.  These
applications
and services are "real-time" in the sense set out first in RFC 1889.

The RAI Area is seeded with existing working groups from the Transport
and Applications Areas: AVT, ECRIT, ENUM, GEOPRIV, IEPREP, IPTEL,
MEGACO, MMUSIC, SIGTRAN, SIMPLE, SIP, SIPPING, SPEECHSC, and XCON.
A good rule of thumb for the incorporation of new work into RAI, as
opposed to
Transport or Applications, is that the work in question is needed to
support
real-time interpersonal communication.  The infrastructure applications
needed
to support such communications are explicitly in scope, as are
discussions of
operational concerns specific to this area.  For example, work might
relate to
presence services, to session signaling protocols and emergency call
routing
solutions, or to work on the "layer five" issues for Internet telephony.

Like all areas of the IETF, the RAI Area draws on the work of numerous
other areas, and as such there can be no neat mathematical boundaries
delineating RAI's work from the rest of the IETF. The new area will
allow an existing community within the IETF to solidify its vision and
to benefit from increased institutional support.

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

Re: IETF Meeting Venue Selection Criteria

[john . loughney]

Eliot,

I've talked to quite a few folks that have been unable to attend meetings in 
the US because of visa issues. Some consideration is needed for these reasons. 
Also, the delay in getting future meetings listed has just made the situation 
worse. I do think some of this discussion has been overkill, but a general 
document on selection criteria for future IETF meetings, without RFC 2026 
language could be a good thing.

John

--- original message ---
Subject:Re: IETF Meeting Venue Selection Criteria
Sender: Eliot Lear <[EMAIL PROTECTED]>
Date:   10/18/2005 4:27 AM

Avri Doria wrote:
> Hi,
> 
Forgive me Avri and Jordi, but why?

I've been going to IETF meetings since 1988 and I really can't remember 
the Secretariat fouling it up.  Did I miss a problem?  Could people not 
get to France or Minnesota?  Is this something we really need to do?

Eliot

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


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

RE: A New BoF [16ng BoF: IPv6 over IEEE 802.16(e) Networks]

[john . loughney]

General question - I know that the WiMax forum is working on more things
than just IP over 802-16e (etc.).  You mention, for example, AAA, in the
description.  Are you looking at more than just running IP over 802.16e
or something more?

John 

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
>Behalf Of ext Soohong Daniel Park
>Sent: 27 September, 2005 02:09
>To: IPv6 WG; IPv6-Ops Area; Int-area ML; IETF ML; MIPSHOP WG; MIP6 WG
>Cc: [EMAIL PROTECTED]
>Subject: A New BoF [16ng BoF: IPv6 over IEEE 802.16(e) Networks]
>
>Folks,
>
>We would like to announce a BoF at the upcoming IETF, leading 
>to identify what limitations and considerations apply to IPv6 
>adoption over IEEE 802.16(e), and to propose available 
>solutions. A mailing list is set up at 
>[EMAIL PROTECTED] and a proposed description is below.
>
>==
>
>IPv6 over IEEE 802.16(e) Networks BoF (16ng)
>
>
>CHAIRS:
>
>Soohong Daniel Park<[EMAIL PROTECTED]> Gabriel 
>Montenegro<[EMAIL PROTECTED]>
>
>
>DESCRIPTION:
>
>Broadband Wireless Access Network addresses the inadequacies 
>of low bandwidth wireless communication for user requirements 
>such as high quality data/voice service, fast mobility, wide 
>coverage, etc. The IEEE 802.16 Working Group on Broadband 
>Wireless Access Standards develops standards and recommended 
>practices to support the development and deployment of 
>broadband Wireless Metropolitan Area Networks. In addition, 
>IEEE 802.16e supports mobility over IEEE 802.16 as an 
>amendment to the IEEE 802.16 specification. 
>
>Recently, much work is in progress by the WiMAX Forum. In 
>particular, its NWG (Network Working Group) is responsible for 
>the IEEE 802.16(e) network architecture (e.g., IPv4, IPv6, 
>Mobility, Interworking with different networks, AAA, etc). The 
>NWG is thus taking on work at layers above those defined by 
>the IEEE 802 standards (typically limited to the physical and 
>link layers only). Similarly, WiBro (Wireless Broadband) is a 
>Korean effort based on the IEEE 802.16e specification which 
>focuses on the 2.3 GHz spectrum band.
>
>IEEE 802.16(e) is different from existing wireless access 
>technologies such as  IEEE 802.11 or 3G. Accordingly, the use 
>of IP over an IEEE 802.16(e) link is currently undefined, and 
>will benefit from IETF input and specification. For example, 
>even though Neighbor Discovery has been specified to work over 
>point-to-point type links (e.g., as available in 3G), it 
>applies most naturally to link technologies capable of native 
>multicasing. Thus, it is not yet clear how it would work over 
>IEEE 802.16(e) networks. Even though these supports a PMP 
>(Point-to-Multipoint) mode, there is no provision for 
>multicasting IP packets, hindering the basic standard IPv6 
>operation. An IEEE 802.16(e) connection for IP packet transfer 
>is a point-to-point unidirectional mapping between medium 
>access control layers at the ubscriber station and the base 
>station. This eventually requires convergence protocols to 
>emulate the desired service on network entities such as base 
>stations, which may limit IPv6 features. As for fast mobility, 
>the characteristics of IEEE 802.16e link-layer operation may 
>require an amendment to the Fast Handover Mobile IPv6 scheme 
>(RFC 4068), something which may be pursued in the MIPSHOP WG.
>
>The principal objective of the 16ng BoF is to identify what 
>limitations and considerations apply to IPv6 adoption over 
>IEEE 802.16(e), and to propose available solutions. The 
>working group may issue recommendations to IEEE 802.16(e) 
>suggesting protocol modifications for better IP support. 
>
>In 2006, WiBro deployment will begin, and the WiMAX Forum is 
>slated to specify IPv6 operation over IEEE 802.16(e) in 2006. 
>Accordingly, the working group will work and coordinate with 
>the WiMAX Forum and with the WiBro efforts.
>
> 
>MAILING LIST: 
>
>General Discussion: [EMAIL PROTECTED] To Subscribe: 
>http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
>Archive: http://eeca16.sogang.ac.kr/pipermail/16ng 
>
>
>REFERENCES:
>
>http://www.ietf.org/internet-drafts/draft-jang-mipshop-fh80216e-00.txt
>http://www.watersprings.org/pub/id/draft-jin-ipv6-over-ieee802.
>16-00.txt
>http://www.ietf.org/internet-drafts/draft-jee-mip4-fh80216e-00.txt 
>IPv6 over IEEE 802.16(e) Networks Problem Statements (coming soon) 
>
>
>Regards,
>
>Gabriel & Daniel 
>16ng BoF co-chairs
>

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

RE: Possible new Real-Time Applications and Infrastucture (RAI)Area

[john . loughney]

Bill,

>On Fri, 2005-09-16 at 14:36, [EMAIL PROTECTED] wrote:
>> If there was a way to lighten-up the IESG review process, then this 
>> would be a good idea. For example, having a single DISCUSS per Area 
>> would be one way to reduce this could be one solution.
>
>Why do you think this would make any difference in practice?  
>chances are that an AD-pair would agree to hold a DISCUSS if 
>either felt that an issue should block publication.

What I meant was that the IESG spends a lot of time on document review.
I don't think anyone has complained that there is not enough document
review.  If we add more ADs, then we will be increasing the amount
of document review.  Is this something we should need?  I think David
put it quite well that scheduling IESG calls, meetings and retreats
is already problematic - adding more ADs will not improve things.

Would a re-organization of the current set of areas solve the same
thing?
If the problem is that certain WGs are not getting enough management
time, then would increased usage of Technical Advisors (which is already
done) improve things?  

My read of most of the current responses on this thread is that the SIP
& related working groups are feeling pressure in the current Transport
Area, so some re-arrangement is needed.  What I haven't seen is how
having more ADs involved would actually improve things.

John

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

Re: Re: OFF TOPIC - Bail money for IETF 64?

[John Loughney]

> Even though I benefit from this change, I disagree with it in principle 
> because there are too many people out there running around calling 
> themselves "engineers" who don't have a clue.  If/when there are a 
> non-trivial number of schools offerring degrees in network engineering, 
> systems engineering, software engineering, etc. I (and many others) will be 
> lobbying to have the exemption repealed.

Probably less harm comes from this than if people were running around calling 
themselves Doctors - or Federal Emergency Managers - without proper 
qualifications ...

John


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

RE: Possible new Real-Time Applications and Infrastucture (RAI) Area

[john . loughney]

I'm of conflicting thoughts about this. On one hand, more Ads could
have more opportunity to do more hands-on work with working groups, etc.
This would be a good thing, and could potentially help WGs to progress
drafts through WGs faster.

On the other hand, 2 more ADs means two more potential DISCUSSes and
more Ads spending time on document reviews.  I'm not sure if what the
IETF needs is more Ads to review the documents and file DISCUSSes.

If there was a way to lighten-up the IESG review process, then this
would be
a good idea. For example, having a single DISCUSS per Area would be one
way
to reduce this could be one solution. 

In summary, I think that expanding the IESG would only be a good idea
only 
if we could adjust the IESG review load / process so that we are not
just
expanding the number of potential DISCUSSes.

thanks,
John

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On Behalf Of ext IETF Chair
>Sent: 16 September, 2005 16:14
>To: IETF Announcement list
>Subject: Possible new Real-Time Applications and Infrastucture 
>(RAI) Area 
>
>As mentioned in the recent call for NomCom volunteers, the 
>IESG is considering the creation of a new area, as set out 
>below.  We solicit feedback from the community on the scope of 
>this potential new area as well as the impact on the IETF's 
>infrastructure and efficiency of setting up this new area. We 
>need to decide quite quickly, to fit the NomCom schedule.
>
>Please write to iesg@ietf.org, or to ietf@ietf.org if you want 
>community discussion of your comment. (There's no need to 
>write to both!)
>
>   Brian Carpenter
>
>-
>
>Real-Time Applications and Infrastucture (RAI) Area Description
>
>The Real-Time Applications and Infrastructure Area develops 
>protocols and architectures for delay-sensitive interpersonal 
>communications. Work in this area serves an emerging industry 
>whose applications and services include voice and video over 
>IP, instant messaging and presence. These applications and 
>services are "real-time" in the sense that delay impedes human 
>participation in the associated systems.
>
>The RAI Area is seeded with existing working groups from the 
>Transport and Applications Area: SIP, SIPPING, XCON, SIMPLE, 
>GEOPRIV, ECRIT, ENUM, IPTEL, MEGACO, MMUSIC, IEPREP, SPEECHSC, 
>and SIGTRAN.  A good rule of thumb for the incorporation of 
>new work into RAI, as opposed to Transport or Applications, is 
>that the work in question has major goals supporting instant 
>interpersonal communication or its infrastructure.
>For example, they can range from applications to help users 
>make decisions about how best to communicate using presence 
>services, to session signaling protocols and emergency call 
>routing solutions, to work on the "layer five" issues for 
>Internet telephony.
>
>Like all areas of the IETF, the RAI Area draws on the work of 
>numerous other areas, and as such there can be no neat 
>mathematical boundaries delineating RAI's work from the rest 
>of the IETF. The new area will allow an existing community 
>within the IETF to solidify its vision and to benefit from 
>increased institutional support.
>
>___
>IETF-Announce mailing list
>IETF-Announce@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf-announce
>

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

Re: IETF 63 On-line Survey

[john . loughney]

That question stymied me, so I just selected "No change."

John

-- original message --
Subject:Re: IETF 63 On-line Survey
From:   Jari Arkko <[EMAIL PROTECTED]>
Date:   08/17/2005 3:26 pm

Spencer Dawkins wrote:

> Would you prefer longer meetings or shorter meetings?
> Shorter meetings with more overlaps
> No change
> Longer meetings with fewer overlaps
>
> means! I'm answering it, assuming that it refers to the one-hour 
> sessions that sometimes get doubled-up into two-hour sessions, but if 
> you mean something else, please let us know.

I interpreted it as having a short IETF meeting (e.g. mon-thu) but with lots
of parallel WG meetings vs. longer IETF meeting (e.g. sun-fri) but with less
parallel WG meetings.

So I guess that just shows how people have a different understanding
of what was being asked.

--Jari


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


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

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

[John Loughney]

my 2 cents as well:

> And whether or not people mention their affiliate at the mic is a
> much smaller issue IMO to whether they use their company email
> account. That is a much more visible and relevant label in IETF work
> that mostly happens on mailing lists anyway.

I believe that its good to avoid conflicts of interest, or the perceptions of 
it.  Note that I am using a personal address on this, so I'm happy to speak 
freely, and this following this list is really not related to my day-job.  
However, on mailing lists / WGs where my employer is interested in my work on 
the subject, I use the email address provided by my employer, just so that 
folks know that my responses might be 'colored' somewhat ...

John



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

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

[John Loughney]

Spencer,

However, many people here are not using their 'individual money' to get here in 
Paris. Our name badges list our employers (in most cases).  I think its a 
different issue if I come to the mic and say, 'We at the ACME company would 
like to state, for the record, that we support the foo bar proposal and hope it 
becomes an official RFC as soon as possible.  It doesn't bug me one-way or 
another if folks state their name & who pays the bills.

John
> From: "Spencer Dawkins" <[EMAIL PROTECTED]>
> Date: 2005/08/01 Mon PM 05:44:54 EEST
> To: "IETF General Discussion Mailing List" 
> Subject: I'm not the microphone police, but ...
> 
> >From RFC 2418 section 1
>...
>Participation is by individual technical contributors, rather than 
> by
>formal representatives of organizations.
> 
> It seems like we're being especially casual about saying, "I'm Waldo 
> from Walden Pond Networks, and ..." or even "I'm giving you the 
> requirements from the Grand Order of Network Water Buffaloes, and 
> ...".
> 
> I'm still telling people in the Newcomer's Orientation that we attend 
> as individuals. Could we be a little more careful about saying things 
> that make us sound like other standards organizations?
> 
> Thanks!
> 
> Spencer 
> 
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 


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

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

[John Loughney]

Scott,

I dunno.  I thought that some of the discussion has been about circulation of 
folks in leadership positions. Some feel its good, some feel its bad.  Its not 
strictly term-limits as in goverment posts, as quite many former IAB & IESG 
members are extremely active in technical discussions, writing drafts, chairing 
bofs & working groups.  In my experience, this is a really good thing.

I'm not entirely convinced that its important for IESG members to stay in a 
position for a long time. I don't have a strong opinion, so I'm definately open 
for discussion on this.

John L.
> 
> From: Scott W Brim 
> Date: 2005/08/01 Mon AM 11:50:31 EEST
> To: ietf@ietf.org
> Subject: Re: draft-klensin-nomcom-term-00.txt
> 
> Discussion has been couched in terms of whether term limits are a good
> thing.  Really, what the discussion should be about is whether limits
> on the NomCom are a good thing.
> 
> It's one thing to give the NomCom guidelines, it's another to
> constrict them.  The NomCom is pivotal in IETF "governance" and is
> also vulnerable to attacks.  The NomCom should be defended strongly
> against people who don't like the way things are going in IETF
> management.
> 
> Ideally, "term limits" should be ad hoc, per person, as needed.  If
> you don't like the fact that some AD has been around forever, tell the
> NomCom.  If you believe that competency in the job is just one
> criterion, and that potential competency should be considered
> important ... tell the NomCom.  That's what they are there for.  I'm
> assuming you're already volunteering to be on it.
> 
> If there is justification for the "firing" of a long-time AD, well,
> the AD probably should feel embarrassed.  Forcing *all* IESG or IAB
> members out, even if doing so hurts the IETF and the Internet, to
> avoid embarrassment of someone who shouldn't be there is just too
> "politically correct".
> 
> Those who have left IESG/IAB positions and taken up others have done
> so because they are capable and want to contribute.  The fact that
> they can do so does not mean it is all right to force them out of
> positions where they might be even better for the IETF.
> 
> As for learning the trade, I don't know.  IESG/IAB members could have
> an "apprentice" program from their directorates etc., but as has been
> said, there is nothing like actually being in it.  Certainly, forcing
> people out at inappropriate times is way off the path of wisdom.
> 
> In summary, give guidelines and opinions to the NomCom but don't
> restrict them unless they have too much power.
> 
> swb
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 


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

IETF network problems

[John Loughney]

Hi all,

I was looking for Terminal Room info, but I can't find one.  I was wondering if 
anyone is seeing problems with changes with IP addresses.  It seems, when 
running VPN software, my IP address changes every 2 minutes.  Since mobike 
isn't yet an RFC, it makes it hard to keep my VPN up.  If there's a noc mailing 
list, I'll be happy sending logs there.

thanks,
John



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

Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt

[john . loughney]

Paul,

That seems like the most resonable approach to me. Are current requests 
archived now?

John

-- original message --
Subject:Re: I-D 
ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
From:   Paul Hoffman <[EMAIL PROTECTED]>
Date:   07/22/2005 11:03 pm

At 3:51 PM -0400 7/22/05, Bill Sommerfeld wrote:
>On Fri, 2005-07-22 at 07:35, Sam Hartman wrote:
>>  BTW, this conversation and a side conversation with John has convinced
>>  me that IESG review should involve a call for comments phase.
>
>A call for comments requires having something for the community to
>comment on.
>
>Will an internet draft will be required from folks seeking IESG review
>of a proposed assignment, or will we invent yet another mechanism for
>circulating a description of the proposal to the community?

It would make sense for the IESG to send to the community what was 
sent to them; that way, we can judge what they are judging. If it was 
a pointer to an Internet Draft, great; a pointer to some other 
document(s) works just as well.

--Paul Hoffman, Director
--VPN Consortium

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


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

Re: Re: ietf mailing list Acceptable Use Policy

[John Loughney]

> We were faced with this question some time ago, and the result was the 
> creation of the "IETF Non-WG mailing lists" page, 
> 
> 
> The theory being that if something is listed there, the IETF definitely 
> considers it an IETF list; if it is not listed, it's either not an IETF 
> list, or someone needs to take an action to get it listed (which is simple).
> 
> I think defining rules about what is or is not an IETF list is tricky; it's 
> simpler to list the ones that are.

I think that is a reasonable approach.  Hopefully some of this info is sent in 
the welcome to the list mail someone gets when subscribing to the non-WG lists.

John


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

RE: [newtrk] Re: Question about Obsoleted vs. Historic

[john . loughney]

Brian,

> Sure, but the logic is nevertheless a bit contorted - but rather than
> debating what the current system *means* could be concentrate
> on what we should do in future?
> 
> Incidentally 3596 (a DS) obsoletes 3152 (a BCP). That's unusual,
> but it isn't illogical. However, 3152 isn't shown as Obsolete
> in http://www.rfc-editor.org/rfcxx00.html#BCPbyBCP.
> 
>  Brian
> 
> Eliot Lear wrote:
> > I would point out that it is historically useful to be able to track
> > changes between draft and full or proposed and draft and we don't list
> > status information in the RFCs...

What I would like is that the RFC Index would accurately convey the current
status of any RFC.  So, if I needed to check the status of a protocol which
I am not intimately familiar with, I would not need to subscribe to a WG
mailing list or ask an IESG/IAB/WG chair to interpret the RFC List for me.

Its past the new draft cut-off, but if the RFC Editor was willing & a Tools
Team member was willing (& at least a few people thought it was useful) perhaps
we (together) could mock-up an improved RFC Index.

John

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

RE: Question about Obsoleted vs. Historic

[john . loughney]

Bob,

A question for you:

> >What is the reason for continuing to list something obsolete as a Draft 
> >Standard?
> 
> Because Jon Postel always did it that way?  Seriously, the idea is that the 
> document was a Draft Standard when it was published.  You can obsolete 
> it, but you cannot change its publication status.  Should its status change 
> to 
> Historic when it is obsoleted? Maybe, although we have never done it that way 
> (and we do have 20+ years of history).


First off, 2026 says:

4.2.4  Historic

   A specification that has been superseded by a more recent
   specification or is for any other reason considered to be obsolete is
   assigned to the "Historic" level. 

So, it would appear, to me, that anything that has been obsoleted is, in fact,
Historic.  But perhaps I am nit-picking.

My question is - what do we mean by an Obsoleted Proposed Standard?  Does this
have any relevance?  What I am still confused about is that, for a particular
technology, what does the IETF 'recommend' or would want to see implemented
for a particular standard?  Obviously, Historic carries the connotation that
the IETF doesn't suggest to be implemented.  Does the IETF think that Standards
that have been Obsoleted SHOULD be implemented or SHOULD NOT be implemented?
If I wanted to do something and had 2 protocols to choose from, one that was
Proposed Standard and one that was Obsolete but Full Standard, which one 
would the IETF like that I implement?  

Perhaps I am asking to much from the RFC Index 
(http://www.ietf.org/iesg/1rfc_index.txt)
but one would think that we could provide a meaningful way to convey what
we think of our own technology?

 
>  (Note that in fact the RFC Editor added "publication status" to its 
> index
>  database last year; the new field is included in rfc-index.xml.  This
>  shows the status upon publication, in cases where the status is
>  changed later.)
> 
> There are quite a few twisty little passages lurking here, and they mostly 
> stem from
> a basic semantic confusion between a document (RFC) number and the protocol
> that is specified in that document (or maybe not).  The RFC number is in fact 
> a
> document number, but we have chosen to overload it as a protocol designator.
> We say "RFC 793" or "TCP" more or less interchangeably, but 793 is really
> only a document.
> 
> In my view, a result of the ISD proposal in newtrk should be to cleanly 
> remove this
> semantic overloading of RFC numbers. An ISD would define a protocol 
> independent of
> a document identifier (RFC number).  I believe that we should move with all
> deliberate speed to engineer an ISD-based system for IETF standards, rather  
> than
> to make small patches to RFC designations.

Well, you can guess my position on this as well.

thanks,
John

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

RE: [newtrk] Question about Obsoleted vs. Historic

[john . loughney]

Brian,


> >>What is the reason for continuing to list something 
> obsolete as a Draft Standard?
> > 
> > 
> > Lack of action by the IESG.  
> 
> No, lack of action by the community to request moving 
> documents to Historic.

Section 6.2 of 2026 does say the following:

   When a standards-track specification has not reached the Internet
   Standard level but has remained at the same maturity level for
   twenty-four (24) months, and every twelve (12) months thereafter
   until the status is changed, the IESG shall review the viability of
   the standardization effort responsible for that specification and the
   usefulness of the technology. Following each such review, the IESG
   shall approve termination or continuation of the development effort,
   at the same time the IESG shall decide to maintain the specification
   at the same maturity level or to move it to Historic status. 

My guess is that anything marked as obsolete will be stuck at its
current maturity level in perpetuity, making it a good candidate to
go to Historic. 2026 seems to state that the IESG will handle this.
However, Eliot's Crust removal draft could come to play here.

John

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

RE: Question about Obsoleted vs. Historic

[john . loughney]

Ted,

> I've assumed that it was to tell you it was at Draft Standard when the 
> document
> that replaced it was issued.  That way you can tell whether the new doc is
> a recycle-in-grade, an update to get something to the next step, or a 
> downgrade.
> The real meat of the data here, though, is that you should look at 3912 if
> you want the current spec.  Any other data about an obsolete spec is for
> historical interest only.  If I'm right, that could be made clearer (by saying
> "Status when active:" or some such), but that doesn't really change meat of 
> the
> information.

I'd strongly suggest some tag to indicate that its no longer active. In many 
cases,
a Standard is marked Obsolete because it has been updated for some reason; often
times because of some critical bug or other issues.  I don't think the IETF
wants to recommend an obsolete standard as something folks should go and 
implement.

John

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

RE: [newtrk] Question about Obsoleted vs. Historic

[john . loughney]

Henning,

> > No, lack of action by the community to request moving documents to 
> > Historic.
> 
> There seem to be a number of these housekeeping tasks that have almost 
> no benefit to the individual, have increasing costs and ever longer-term 
> commitments and thus, not surprisingly, don't get done on a regular 
> basis. Promotion and demotion of standards are prime examples, reviewing 
> is another.
> 
> Besides appealing to community spirit, other organizations deal with 
> that by deputizing individuals that get recognized for doing this type 
> of work in general, in one way or the other. This can take the "New 
> York's Strongest" (Dept. of Sanitation) or the "XYZ 
> secretary" approach.
> 
> In many cases, people do unpleasant or boring or no-immediate-reward 
> tasks in hope of getting promoted later - this is why I suggested WG 
> secretaries earlier and maybe why having elected IESG secretaries or the 
> IETF Dept. of Public Works ("just leave your old standards at the curb") 
> might be needed.

Have you seen draft-ietf-newtrk-cruft-00?  It proposes something along
these lines.

John

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

RE: Question about Obsoleted vs. Historic

[john . loughney]

Hi John K,

> >> I would point out that it is historically useful to be able
> >> to track changes between draft and full or proposed and draft
> >> and we don't list status information in the RFCs...
> > 
> > I agree with that.
> > 
> > And, my head still hurts thinking about why we'd leave
> > something as a  "Proposed Standard" when its been obsoleted.
> > Seems more like an "Obsolete Standard" ... but perhaps I am
> > just nit-picking.
> 
> If, as a community, we cared, we could easily have both the
> tracking information and the status by introducing the
> little-known term "former", as in "Obsolete, former Draft
> Standard".
> 
> Of course, how many procedural hoops we'd have to jump through
> to get there is another issue.

That seems like the most reasonable approach, to me - putting the
'former' tag, not having to jump through procedural hoops ...

John L.

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

RE: Question about Obsoleted vs. Historic

[john . loughney]

Nick,

> The way I understand it, an RFC is only historic(al) if the technology it
> defines is no longer in use.

Well, as Iljitsch mail pointed out, some things (3152 Delegation of IP6.ARPA)
are moved to Historic when the IETF wants people to stop using them ...'

> An obsolete RFC means the technology is still being used, but some part of
> the specification (obsolete RFC) has been updated.  An obsolete RFC can
> still be a standard as the RFC that obsoletes it may not change the protocol
> at all.  One example of this is RFC 3912 which is the RFC that obsoletes
> your example (RFC 954) - read 3192's abstract for more detail.
> 
> This is of course only my understanding.

If only part has been updated, then the RFC doing the update should say 'Updates
RFC xyz', I think ...

John

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

RE: Question about Obsoleted vs. Historic

[john . loughney]

Eliot,

> I would point out that it is historically useful to be able to track
> changes between draft and full or proposed and draft and we don't list
> status information in the RFCs...

I agree with that.

And, my head still hurts thinking about why we'd leave something as a 
"Proposed Standard" when its been obsoleted.  Seems more like an "Obsolete
Standard" ... but perhaps I am just nit-picking.

John
 
> Eliot
> 
> [EMAIL PROTECTED] wrote:
> > Hi,
> > 
> > I was wondering if someone could help me out on this one.  
> I was doing a bit
> > of analysis on the current RFC list, and noticed that some 
> Draft Standard
> > documents are obsoleted.  For example:
> > 
> >  954 NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler.
> >   Oct-01-1985. (Format: TXT=7397 bytes) (Obsoletes 
> RFC0812) (Obsoleted
> >   by RFC3912) (Status: DRAFT STANDARD)
> > 
> > This really made me scratch my head. One would imagine if a 
> protocol is obsoleted
> > by another, it would not be listed as a Draft Standard any longer.  
> > 
> > What is the reason for continuing to list something 
> obsolete as a Draft Standard?
> > 
> > John
> > 
> > ___
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ietf
> > 
> > 
> 

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

Question about Obsoleted vs. Historic

[john . loughney]

Hi,

I was wondering if someone could help me out on this one.  I was doing a bit
of analysis on the current RFC list, and noticed that some Draft Standard
documents are obsoleted.  For example:

 954 NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler.
  Oct-01-1985. (Format: TXT=7397 bytes) (Obsoletes RFC0812) (Obsoleted
  by RFC3912) (Status: DRAFT STANDARD)

This really made me scratch my head. One would imagine if a protocol is 
obsoleted
by another, it would not be listed as a Draft Standard any longer.  

What is the reason for continuing to list something obsolete as a Draft 
Standard?

John

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

what is a wg chair's job was: Simplistic metrics Re: WG management

[John Loughney]

Harald,

Your mail prompted me to write a mail I have been contemplating (but I'm 
actually sending this via my phone, so I'm keeping this brief).

What is a wg chairs job? I can think of several tasks:
 1) cheerleader (go wg, go!)
 2) mediator (Mr. x, you need a time-out!)
 3) task manager (draft-foobar is 1.8 weeks late.)
 4) key contributor (I think the header field should be 2.1 bytes long.)
 5) big-picture type (the internet needs a protocols for signaling 
morality.)

With the above tasks, chairs can be active or more reactive, sometimes 
depending upon the situation. 

What I thinks is needed, however, is that the chair and the ad cooperate 
well and have a good understanding of how things are working.  I also think 
that while we can blame the IESG or the wg chair, but I think a key point 
we've often overlooked is the  ad-chair relationship.  If a chair knows 
what the ad reaction will be when sending a draft to the IESG, then this 
may help avoid the late suprise, Also, if an ad knows what is happening 
(roughly) in a wg, then they can help provide some insight into ho to get 
things unstuck.

I thinks this calls for the ads and chairs to be in touch and discussing 
things frequently, even chair reviews by the IESGs (say once a year) and 
maybe even joint wg status reviews. 

John L. 

  

_ Original message _
Subject:Simplistic metrics Re: WG management
Author: "Harald Tveit Alvestrand" <[EMAIL PROTECTED]>
Date:   21st June 2005 10:34:48  AM



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

wrote:

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

Let me offer a simplistic metric.

if a WG chair has posted nothing to the WG mailing list for a week, and 

that WG chair has not told the WG he's on holiday, that WG chair is 

probably not doing his/her job.

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

the WG.

 
Harald





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


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

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

[John Loughney]

Title: Converted from Rich Text

 
 

John, 
  One thing that Danny's questionaire didn't address was "How many additional folks might consider putting their names in the hat if they knew the candidates. In past years, when I have gotten a request from NOMCOM to review the padded list, I've thought to myself 'If I knew only these folks were running, I would have considered ...' I wonder if other people have thought the same. 
 John L.  
 _ Original message _ 
Subject: Re: Complaining about ADs to Nomcom (Re: Voting (again)) 
Author: "John C Klensin" <[EMAIL PROTECTED]> 
Date:  16th May 2005 9:58:21  PM 
 In the light of this and Dave's comments, and since I used to teach people how to design survey questions so that the questions were as non-reactive as possible and the answers could be interpreted.  There is nothing inherently wrong with a self-report question.  We ask them all the time and normally expect truthful answers.  The tricky part is understanding which questions people may not want to answer truthfully, the reasons why, and, if the person who is reluctant to answer provides _some_ answer, how either that or a pattern of non-response is likely to bias the results. 
For example, if one asks a large sample of 10-year-olds how old they are, the answers will, predictably, be mostly truthful: there are few incentives to lie and mistakes will tend to be nearly randomly distributed (slightly fatter tail to the "younger" side because of forgetting birthdays).   If one asks the same question of 60 year olds, the answer pattern would probably be different, and it is important, if one is trying to interpret validity, to understand those differences and their likely impact, rather than assuming either that all population  
groups are the same or that all self-report answers are invalid.Coming back to the question at hand, if the nomcom asks people whether they would have accepted nominations if their names would become public, why would someone lie?  And, if they did, then which way would the report be biased.   I would think that people who are inclined to give incorrect answers would be more inclined to answer "no problem" given the community's biases about openness and unwillingness to admit that they require secrecy.  Maybe I'm wrong about that, but, if I'm not, the  
results Danny reported would, if anything, underestimate the number of people who would not be willing to be considered if their names were public.We now return you to the regularly-scheduled religious arguments on the subject.john 
--On Monday, May 16, 2005 10:52 +0200 Brian E Carpenter <[EMAIL PROTECTED]> wrote:> You've seen Danny's message with the results of asking the> question in a straightforward way - 20% of IESG nominees> say they would not have volunteered. Unlike Dave, I am> willing to believe them.>> fwiw I responded "Yes" to Danny's question, but not> without careful thought and some hesitation. 
>> Brian>> Dave Crocker wrote:>>> Seems fairly easy to judge the validity of that argument to>>> me.  ASk the nomcom to ask volunteers whether they would>>> have volunteered if their name was gonig to be made public.>>> Collect statistics. 
 Sam, Sorry, no. As I posted earlier, that sort of methodology relies on what>> survey  researchers call "self-report". It is very good for assessing attitudes and very bad for>> assessing  actual behavior. 
 For example, what you are likely to get are responses that>> indicate  whether the people would like to have nominations>> be public. It does not guarantee -- and well might not even correlate>> with --  whether they really would run or not run, depending>> on the public-ness  of the nomination. It is one thing to ask simple questions about simple issues. 
>> As soon as  we get into something more "political" the>> psychodynamics get messy.>>   d/>>   --->>   Dave Crocker>>   Brandenburg InternetWorking>>   +1.408.246.8253>>   dcrocker  a t ... 
>>   WE'VE MOVED to:  www.bbiw.net ___>> Ietf mailing list>> Ietf@ietf.org>> https://www1.ietf.org/mailman/listinfo/ietf>>> 
>> ___> Ietf mailing list> Ietf@ietf.org> https://www1.ietf.org/mailman/listinfo/ietf> 
___Ietf mailing listIetf@ietf.orghttps://www1.ietf.org/mailman/listinfo/ietf 

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

Re: Re: New root cause problems?

[John Loughney]

Margaret,

> At 10:50 AM +0200 5/11/05, Brian E Carpenter wrote:
> >But that gives very limited insight into what is holding it up, except
> >for a few cases. If it's in EDIT state you get no useful information about
> >issues and progress, for example.
> 
> Also, if there is the equivalent of the I-D tracker for the RFC 
> Editor Queue (where correspondence and major state transitions for a 
> document are captured and can be seen later), I am not sure where to 
> find it.  The RFC editor queue is a text document that only seems to 
> capture the current state of the document (EDIT, AUTH48, etc.).

I'm personally not to sure about the accuracy of some of those states.  I found 
a couple that I am personally involved in that are still listed as in the AUTH 
state, but where all of the authors have signed off on the document & the RFC 
Editor has confirmed that we have signed off on it.


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

Re: Re: New root cause problems?

[John Loughney]

Margaret,

This is a huge problem, IMO.  If you couple your point with James sub-point 
about drafts expiring in the RFC editors' queue, you really do have a mess.

I often have to discuss with other SDOs on IETF drafts; often they need an RFC 
number for their own processes.  It might be enough to say to some IETFers to 
look at the RFC Editor's Queue, but it is not a reasonable way to manage things 
inter-SDO.

I am a co-author of a draft that was initially requested in August 2003, by 
3GPP for Release 5, but it had not been accepted yet as a WG item, so it was 
not included in 3GPP Release 5.  The authors worked hard to get the document 
done, and the current version is dated August 12, 2004.  It is currently listed 
in the RFC Editors Queue with the note "Fast Track requested." It is in the 
AUTH = Awaiting Author Action state, but all of the authors signed off on it on 
March 23rd.  I'll admit that the authors made a bit of a mess during AUTH48 
because we had quite many changes requestes, but that should only account for 
about 1 month of delay.

I'm actually catching a lot of grief about this via private mail because it 
looks like incompetence to folks outside of the IETF.  I really think these 
type of things really strains any credibility that the IETF has.

John Loughney
> From: Margaret Wasserman <[EMAIL PROTECTED]>
> Date: 2005/05/10 Tue PM 04:36:51 EEST
> To: Brian E Carpenter <[EMAIL PROTECTED]>,  ietf@ietf.org
> Subject: Re: New root cause problems?
> 
> 
> I have one new "root cause" issue that I don't believe was included 
> in the original Problem Statement:
> 
>  It takes too long to publish an RFC after final approval.
> 
> It currently takes several months for an RFC to be published after it 
> is approved by the IESG.
> 
> This results in several problems:
> 
> - RFCs come out much later than they should, contributing greatly to 
> the perception that the iETF is slow.  The time to move from approved 
> I-D to RFC is often a significant percentage (perhaps averaging 20% 
> of more?) of the time required to develop and publish a specification.
> - Stable references are not available until months after a 
> specification is fully approved, resulting in ambiguity about the 
> status of a document and encouraging the use of I-D names as 
> references, thus blurring the distinction between WG I-Ds and 
> approved specifications.
> - Too many changes are made to documents after WG and IESG approval 
> (copy editing, changes to reflect updated thinking/terminology, 
> etc.).  These changes are often not reviewed or approved by the WG or 
> the community.
> - Some RFCs are already out-of-date by the time they are published. 
> The document then contains the RFC publication date, which may result 
> in a mistaken impression about when the IETF held a specific view or 
> encouraged a particular practice.
> 
> I believe that the IETF should consider modifications to our document 
> handling process to reduce or eliminate the delay in publishing 
> approved specifications.
> 
> Margaret
> 
> 
> At 2:36 PM +0200 5/10/05, Brian E Carpenter wrote:
> >Having finally read the list traffic up to date, I have a question.
> >
> >Can anybody identify a *new* "root cause problem" at the same level
> >of abstraction as those identified in RFC 3774? Or is it the case
> >that (at that level of abstraction) we have only been re-discussing
> >the RFC 3774 problem set?
> >
> >(Please try to be succinct... or change the subject header if you want
> >to change the subject.)
> >
> >Thanks
> >Brian
> >
> >
> >
> >
> >___
> >Ietf mailing list
> >Ietf@ietf.org
> >https://www1.ietf.org/mailman/listinfo/ietf
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 


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

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

[John Loughney]

Seems resonable to of as well.


The good thing about mobile email is that t9 forces you to be brief.

--- original message ---
Subject:Re: Complaining about ADs to Nomcom (Re: Voting (again))
Sender: Dave Crocker <[EMAIL PROTECTED]>
Date:   05/10/2005 5:27 pm

>  On day N, publish the list of willing nominees so far and invite further
>
>  nominations before day N+14.
>
>  On day N+28, publish the final list of willing nominees and invite
>  feedback.
>
>  This would, if we wanted to publish the names, give 2 weeks for extra
>  nominations and another 2 weeks to check their willingness to serve.


seems pretty reasonable.


  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



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


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

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

[John Loughney]

How about when someone tosses their hat in the nomcom ring, they indicate if 
their name can be made public. Nomcom publishes a list of these names & a note 
about the number of candidates who are anonymous. The genereal IETF than has a 
somewhat better idea of who to provide comments on & candidates can remain 
anonymous.

John


The good thing about mobile email is that t9 forces you to be brief.

--- original message ---
Subject:Re: Complaining about ADs to Nomcom (Re: Voting (again))
Sender: Brian E Carpenter <[EMAIL PROTECTED]>
Date:   05/09/2005 4:09 pm

Soliman, Hesham wrote:
> 
>  > At 01:10 PM 5/4/2005, Soliman, Hesham wrote:
>  > >  > One way to open up the process would be to allow any participant
>  > >  > to personally request a list of candidates from Nomcom, against
>  > >  > a personal non-disclosure promise. (Not my idea; this 
>  > was suggested
>  > >  > during last week's IESG retreat.)
>  > >
>  > >=> If we do that we may as well put the list on the web. 
>  > How do we define
>  > >"participant"?
>  > 
>  > There is a difference between having participants who are 
>  > interested in 
>  > providing feedback ask for a copy of the list, with a promise of 
>  > confidentiality, and give feedback - versus having that information 
>  > publicly available.  This sounds useful to me.
>  > 
>  > I don't think that "participant" really needs to be defined. 
>  >  Those who 
>  > will be interested are those who are involved.  Currently, 
>  > to obtain input 
>  > from a more diverse set of people, Nomcomm has to guess who 
>  > is appropriate 
>  > to ask & hope that a reasonable sampling of them will be 
>  > willing/interested 
>  > in responding.
> 
> => Ok, since I think it will lead to the same effect (widely known nominees)
> I'm fine with that suggestion. 
> Personally, I don't see the difference between doing what you describe
> above and sending the list of nominees to this mailing list. But either
> option is definitely better than what we have today IMHO.

One difference is that we wouldn't have to update the BCP, since there
would be no overt breach of confidentiality. So next year's NomCom
could simply do this without further bureaucracy.

I'm going to ask this year's Nomcom chair to see if this year's
candidates can answer the question "would you have run if your name
had been made public?"

Brian


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


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

Re: Proper WG chairs (Re: Voting (again))

[John Loughney]

Brian,

it is also that it takes a long time for wgs to finish their work.  It would be 
an interesting stat to compare the initial deliverables vs. current statis vs. 
the reality. We are not good at predicting work.

John


The good thing about mobile email is that t9 forces you to be brief.

--- original message ---
Subject:Re: Proper WG chairs (Re: Voting (again))
Sender: Brian E Carpenter <[EMAIL PROTECTED]>
Date:   05/09/2005 3:38 pm

Harald Tveit Alvestrand wrote:
> 
> 
> --On 8. mai 2005 23:54 +0200 Julian Reschke <[EMAIL PROTECTED]> wrote:
> 
>>> ISTR a case of a WG that got replaced its chair by the IESG, and told to
>>>  do its work differently, two or three times - and *every* time, the new
>>>  chair stopped posting to the list after a short time. (The last time, I
>>>  think he came back after a significant timeout.)
>>>
>>> That's a recipe for exhaustion if ever I saw one. I might even call it
>>> active sabotage.
>>
>>
>> I don't know about ISTR, but similar things have happened to the WEBDAV
>> working group in the last two years (no, I'm not saying it's intentional;
>> but fact is we got two new chairs who did not / do not seem to be very
>> interested in the current WG work).
> 
> 
> My immediate reaction is "who were the available candidates for chair"
> In contentious groups, the requirement list is roughly (not in priority 
> order):
> 
> - Knows enough of the technology to understand the issues
> - Knows enough about the IETF process to steer the group correctly
> - Respected enough by the groups of people involved
> - Not strongly identified with any of the camps of contention
> - Has time enough available (and an employer or family that will allow 
> them to spend that time)
> - Has the personal qualities needed to get people to come to consensus
> - Is known enough to the AD that he/she is comfortable working with that 
> person
> - and I'm sure there are things I've forgotten.
> 
> And since the intersection of all those qualities is frequently the null 
> set, chair candidates tend to be lacking in one or more of these 
> qualities. In the cases cited, the "time enough available" may be the 
> factor that changed - I don't know the specifics.
> 
> I see two possibilities when a chair fails to work out:
> 
> - The AD made a bad choice, and there was someone else who could have 
> done a better job. Solution: AD needs help in picking chairs.
> 
> - There was no better candidate at the time (all the other candidates 
> being more obviously the wrong person for the job). Solution: The chairs 
> need help in calling for help earlier when they're unable to perform, 
> and the AD needs to be more proactive in replacing chairs who aren't 
> doing what they should (again going back to the candidate pool).
> 
> I suspect that the latter happens more often than the former - but as I 
> said, I don't know those specific cases.

Me neither. But I would suspect that we aren't careful enough for Chair
positions in being certain that the candidate has enough free time and
full support from their employer. People often seem to take on being WG
Chair without allowing anything like enough time for it, and I guess
ADs need to watch that point.

Brian


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


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

RE: Proper WG chairs (Re: Voting (again))

[John Loughney]

Harald,

you forgot one:

 - willingness to continue working as a chair, long after their day job has 
moved onto new topics.

In this business, most folks change tasks, if not jobs, sooner than the average 
half-life of wgs in the IETF.
 
John
 

The good thing about mobile email is that t9 forces you to be brief.

--- original message ---
Subject:Proper WG chairs (Re: Voting (again))
Sender: Harald Tveit Alvestrand <[EMAIL PROTECTED]>
Date:   05/09/2005 1:56 pm



--On 8. mai 2005 23:54 +0200 Julian Reschke <[EMAIL PROTECTED]> wrote:

>> ISTR a case of a WG that got replaced its chair by the IESG, and told to
>>  do its work differently, two or three times - and *every* time, the new
>>  chair stopped posting to the list after a short time. (The last time, I
>>  think he came back after a significant timeout.)
>>
>> That's a recipe for exhaustion if ever I saw one. I might even call it
>> active sabotage.
>
> I don't know about ISTR, but similar things have happened to the WEBDAV
> working group in the last two years (no, I'm not saying it's intentional;
> but fact is we got two new chairs who did not / do not seem to be very
> interested in the current WG work).

My immediate reaction is "who were the available candidates for chair"
In contentious groups, the requirement list is roughly (not in priority 
order):

- Knows enough of the technology to understand the issues
- Knows enough about the IETF process to steer the group correctly
- Respected enough by the groups of people involved
- Not strongly identified with any of the camps of contention
- Has time enough available (and an employer or family that will allow them 
to spend that time)
- Has the personal qualities needed to get people to come to consensus
- Is known enough to the AD that he/she is comfortable working with that 
person
- and I'm sure there are things I've forgotten.

And since the intersection of all those qualities is frequently the null 
set, chair candidates tend to be lacking in one or more of these qualities. 
In the cases cited, the "time enough available" may be the factor that 
changed - I don't know the specifics.

I see two possibilities when a chair fails to work out:

- The AD made a bad choice, and there was someone else who could have done 
a better job. Solution: AD needs help in picking chairs.

- There was no better candidate at the time (all the other candidates being 
more obviously the wrong person for the job). Solution: The chairs need 
help in calling for help earlier when they're unable to perform, and the AD 
needs to be more proactive in replacing chairs who aren't doing what they 
should (again going back to the candidate pool).

I suspect that the latter happens more often than the former - but as I 
said, I don't know those specific cases.

Harald




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


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

RE: text suggested by ADs

[John Loughney]

Exactly. If the ad is not a member of the mailing list and the wg chair blocks 
mails from an ad, them the wg has bigger problems than DISCUSSes on drafts.

John


The good thing about mobile email is that t9 forces you to be brief.

--- original message ---
Subject:RE: text suggested by ADs
Sender: "Lars-Erik Jonsson \(LU/EAB\)" <[EMAIL PROTECTED]>
Date:   05/09/2005 1:43 pm

> >> "Spencer" == Spencer Dawkins <[EMAIL PROTECTED]> writes:
> >
> >Spencer> - the mailing lists are often not set up to allow 
> >Spencer> posting by non-members
> >
> > That's a violation of policy.  Please see the IESG statement on spam
> > policy; someone needs to be approving non-member postings for IETF
> > working group lists.
> 
> "allow posting without manual intervention" - the mailing lists I've 
> administered for IETF had two settings, "allow posting by 
> non-members" and "hold postings by non-members for approval".
> 
> What I was trying to say was, this is probably sufficient for first 
> feedback, but probably not sufficient for actually discussing a 
> DISCUSS comment.

True, but as the mailing list administrator you can choose to add
senders to the "accepts-filter" when their first posting is approved,
that should solve the problem, right?

/L-E

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


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

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

[John Loughney]

Hi all,

Is it true true that we suffer from a lack of IESG candidates? I've often heard 
this claim, but I've been asked by the NOMCOM to comment on list for the part 
few years & it seemed that there were capable names on the lists (unless they 
were all ringers).

John


The good thing about mobile email is that t9 forces you to be brief.

--- original message ---
Subject:Re: Complaining about ADs to Nomcom (Re: Voting (again))
Sender: Margaret Wasserman <[EMAIL PROTECTED]>
Date:   05/07/2005 5:43 pm


Hi John,

At 9:18 AM -0400 5/7/05, John C Klensin wrote:
>Whatever the reasons, we don't seem to have enough plausible
>candidates to provide reasonable turnover on the IESG (which,
>personally, I think would be healthy).

What is "reasonable turnover" for the IESG?

I haven't been on a nomcom, but (from the outside) most of them seem 
to start with the assumption that they should not change more than 3 
IESG members at a time.  If that is considered prudent, then we are 
talking about  a situation where a maximum of 1/4 of the IESG will be 
intentionally replaced each cycle. Factoring in mid-term resignations 
and the possibility that the nomcom may occasionally make a poor 
choice requiring quicker turnover, successful ADs who are willing to 
continue serving will probably be in-office for an average of 8-10 
years (4-5 terms).  This seems to match existing practice.

What level of turnover do you think would be healthy?  And what would 
be the impacts of having more new ADs each year?

Margaret

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


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

Re: improving WG operation

[John Loughney]

A slight mod: 

The best technology doesn't always win: engineers don't always solve the right 
problem. Sometimes I think the IETF is making the tools (a.k.a - protocols) 
that make the Internet run. Sometimes the market doesn't want the tool that we 
made, or needed a took sooner than we could produce one.  

John


The good thing about mobile email is that t9 forces you to be brief.

--- original message ---
Subject:Re: improving WG operation
Sender: Sam Hartman <[EMAIL PROTECTED]>
Date:   05/09/2005 2:44 am

> "Tom" == Tom Lord <[EMAIL PROTECTED]> writes:

Tom> All I mean is that, for higher level protocols, letting
Tom> people do what they will ("the market decides") seems to me
Tom> to be the best option.  Yes, using your example, IM protocols
Tom> fragment, interop suffers, there's lots of crap --- so what?


I think our concern is that we have finite resources here in the IETF.
If you want a market decides standards, go set up an industry
consortium or go to a market decides standards body.

The IETF works best when people bringing technologies to it buy into
the idea of building rough consensus.

So, if you want the market to decide, and you don't have a
particularly good reason for being at the IETF, perhaps we're not the
best place for you to do your work.


One obvious question to ask is whether the IETF still has work to do
and is still the right place for anything.  My answer is simple: let
the market decide;)


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


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

Re: text suggested by ADs

[John Loughney]

Bill,

When is a DISCUSS not a discuss? When it is a "You have to fix this and I'm 
holding a DISCUSS until it's fixed." I've seen variations on there as a draft 
editor and it's not always clear. In the past, this has been an issue with ADs 
who have not engaged the WG. It helps to have an explanation of the DISCUSS.

John


The good thing about mobile email is that t9 forces you to be brief.

--- original message ---
Subject:Re: text suggested by ADs
Sender: Bill Fenner <[EMAIL PROTECTED]>
Date:   05/08/2005 7:51 pm

On 5/7/05, Dave Crocker <[EMAIL PROTECTED]> wrote:
>If someone has the authority to block the long-term work of a group of IETF
> participants, they have an *obligation* to take their concerns directly to
> those participants and engage in a direct process to resolve it.

Dave,

  From my point of view, there are two assumptions that the IESG makes
in this situation:

1) Since the responsible AD (or PROTO shepherd) is more familiar with
the working group / document / other work / etc, they will be able to
more effectively communicate the concerns.
2) The AD that registered the DISCUSS is always willing to actually
have a discussion directly with the WG or authors if necessary.

However, I think that the community tends to see instead:

1) The discussing AD is hiding behind a shield
2) The discussing AD isn't willing to communicate with the WG

I've certainly seen responses to discusses that I've filed come back
as "Well, I don't think this is reasonable, but I've made this change
to satisfy the IESG," even though I would have been willing to have
the discussion and yield to the WG's/authors' opinion.

I do think that #1 is solving a real problem - I'm pretty sure that
WGs/authors would rather get one message summarizing all of the IESG's
issues rather than 10 messages from different individuals that might
have overlapping issues, etc.  However, if it's perpetuating the myth
that ADs aren't willing to talk to the WGs/authors, we need to do
*something* about it.

  Bill

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


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

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

[john . loughney]

Brian & Jari,

> > Please understand the argument that was made strongly while
> > RFC 3777 was in WG discussion: there is reason to believe that
> > a substantial fraction of the potential candidates would *not*
> > volunteer if they were entering a public race. It's hard to
> > judge the validity of that argument, but it's certain that
> > publishing the names would change the whole process in
> > unpredictable ways.
> 
> 
> Like Hesham, I am also aware of this argument and do not
> necessarily agree with it. (In fact, one could make the point
> that not being able to tell you have volunteered sounds a bit
> wimpy compared to what kind of public visibility and pressures
> the folks need to deal with if they are actually selected,
> particularly to the IESG.)
> 
> Also, to give you a datapoint on potential candidates -- my name's
> been given to nomcom a couple of times and I certainly would not be
> bothered by folks knowing who has volunteered and who has not.
> And I think John L said something similar as well.

I wouldn't mind if my name was made public the times that I have volunteered;
but again, I wasn't active in the discussions of RFC3777.  I agree with
Jari on the above points.

John

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

Re: Re: text suggested by ADs

[John Loughney]

> > I don't see anything wrong with that.  It's the ADs' job to push back 
> > on documents with technical flaws.  They're supposed to use their 
> > judgments as technical experts, not just be conduits of information 
> > supplied by others.
> 
> I disagree that the ADs are necessarily that much more technically
> astute than the rest of us.  I would actually feel more comfortable with
> ADs providing their technical judgment with the rest of us, through the
> same mechanism: WG or IETF last call.  And that technical judgment
> should be expressed openly, in an archived WG mailing list, where
> everyone's technical input can be reviewed and everyone who provides
> technical input can be held accountable.
> 
> If whoever wants to provide technical input to make a significant change
> in a specification, be it an AD or a WG chair or ..., can't make a
> sufficiently convincing case, in an open WG mailing list, that there at
> least might not be "rough consensus" for a specification, then I would
> say the specification doesn't need the change.

I tend to agree with Ralph here. I've had very good dealings with ADs when they 
bring their DISCUSS to the WG mailing list.  This helps to resolve the issue; 
sometimes making the WG realize something which they missed, and sometimes even 
the AD realizes that the WG has considered their DISCUSS and rejected it for 
technically sound reasons.

Engaging in WG discusses is time consuming, but I think it is consistent with 
the broad principle of "rought consensus and running code."

John


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

Re: Re: Voting (again)

[John Loughney]

Brian,

> > However, I'm not entirely convinced that the unrestricted veto really 
> > exists.  Before I can think about solutions to this problem, I need to 
> > reexamine the process and convince myself that it really is a problem.
> 
> A DISCUSS isn't a veto. I've seen numerous cases even in my short experience
> as an AD of DISCUSSes leading to, er, discussion and a new draft (or edits)
> that solves enough of the issues that the AD removes their DISCUSS. I don't
> think I've seen any new DISCUSSes that I would categorize as frivolous or
> individualistic.
> 
> What we do have is a long tail on the distribution of the dwell time of
> DISCUSSes. I haven't had a chance to analyze the root causes of the very
> old DISCUSSes.

Just a word from the peanut-gallery here.  As a recipient of DISCUSSes, I 
sometimes had trouble understanding what the DISCUSS was about.  Sometimes a 
DISCUSS is a request for a discussion on a point, because something was not 
clear.  Sometimes it is a warning, like "Are you really sure you mean this?  
You should reconsider it or at least come up with some proof that it is a good 
idea." And sometimes, it is an outright veto, meaning "I will not let this 
document pass until this is fixed, even if the WG had fully examined this issue 
and purposefully chosen the solution."  Often, it is hard to understand what is 
meant by a DISCUSS, and due to IESG overload, it is not always possible to 
engage in a meaningful discussion of a DISCUSS.  I will note that recently 
things seem to be headed (slowly) in a more possitive direction, but ...

So, as a recipient of a DISCUSS, I've learned the hard way that the easiest way 
to resolve a DISCUSS is to ask the IESG member for the exact text they want 
added and be done with it.  I don't think this is the correct way to do things, 
but after working on a document for x number of years and trying to push it 
through the last mile, often document editors just want to get it done.

John


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

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

[John Loughney]

Jari,

I agree with you on this point.  I've tossed my hat into nomcom a few times, 
but I would have either reconsidered or would have been more active had I known 
the other candidates.  Additionally, I could have given feedback on candidates 
had I known that they were candidates.  

NOMCOM has been good about soliciting feedback, but I still think that we miss 
out on useful feedback because IETF members cannot reliably say who is a 
candidate and who is not.  Some candidates have sent around BCC: mails, from 
time-to-time, saying that they are a candidate & would appreciate folks to send 
comments to NOMCOM.  This doesn't seem like a good way for getting information 
'public.'

In the absence of facts, there are lots of rumors about whether a specific IESG 
/ IAB member is stepping down or not; reasons why; etc.  This doesn't seem to 
be an optimal process, IMO.


> 
> From: Jari Arkko <[EMAIL PROTECTED]>
> Date: 2005/04/27 Wed PM 01:59:38 EEST
> To: [EMAIL PROTECTED]
> CC: Sam Hartman <[EMAIL PROTECTED]>,  ietf@ietf.org, 
>   Dave Crocker <[EMAIL PROTECTED]>
> Subject: Re: Complaining about ADs to Nomcom (Re: Voting (again))
> 
> 
> Hi Lakshminath,
> 
> > As the title indicates, it is not sufficient to just complain about an 
> > AD (I guess it might be sufficient in the "Recall" process), it is 
> > also necessary to provide a pool of, or just one for that matter, 
> > candidates who are interested and qualified.  Yes, I have real 
> > examples.  (May I suggest that Nomcom procedures be revised to make 
> > the final candidate list, or at least the number of interested 
> > candidates for each position, be made public?)
> 
> I like this suggestion. But first: I'd rather call this thread "feedback"
> than "complaining", because I hope the nomcom gets a lot of input
> and not just when someone is doing badly.
> 
> But back to the suggestion. I have beeing trying to send a lot of
> input on various positions and candidates to the nomcom in recent
> years. But from the point of view of a regular IETF participant this
> isn't always easy. Basically, the problem is that we have a lot of
> input to give you, but we lack the data about the candidates!
> 
> Of course, we can easily give you feedback on the current AD.
> But we've had a large number of people leave the IAB and IESG
> recently, and it isn't easy to provide feedback about potential
> candidates. Sometimes I tried to do that, just to be surprised that
> the people I commented on weren't even running or someone
> I didn't know or didn't consider as a potential candidate was in
> the process. The nomcom goes out to the area chairs and other
> contributors and solicits feedback, revealing at least some of
> the potential candidate names. This helps, but its fairly limited.
> Or at least I would have wanted to give more feedback on more
> areas than I received questions from the nomcom.
> 
> I would suggest that (agreeing) candidate lists be made public
> early in the process, in order to make it easier for the IETFers to
> provide you feedback. This would also increase the transparency
> of the process. And yes, I am aware of the argument that some
> candidates might be shy to reveal that they are running for the
> job. But we are a major organization, and I would suggest that
> the benefits for the organization outweigh benefits (if any) for
> the candidates.
> 
> --Jari
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 


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

Re: Re: Voting (again)

[John Loughney]

Keith,

You've raised these points, over a number of years, but I wonder if it would be 
useful to explore implications of some of your comments:

> 2.  IESG's scaling problems are a direct result of low-quality output
> from working groups, and we can't do much to address that problem 
> by changing how IESG works.  
> 
> 3. I don't think we can make IESG significantly larger, I don't think
> we can dispense with final document review and keep document quality
> up, and I don't think that additional reviewers can signficantly
> relieve IESG of the need to do final review.  I do think that
> additional reviewers could be very valuable in giving WGs feedback from
> early drafts, keeping them on the right track, and keeping IESG
> informed about the status of the WGs.  I also think that a document
> that has enjoyed such review and feedback throughout its life cycle
> will be much easier for IESG to review, and that (without any changes
> to IESG's organization or process) it will be harder for IESG to reject
> such documents without sound technical justification.

Here, in the Problem WG and other places, you've raise the point that 
increasing the IESG probably won't help.  You've implied that we probably have 
too many working groups and too many drafts in the working groups.  The 
implications of these are that the IETF has too much work in too many areas to 
be effective. 

One remedy is to scale back the IETF; not accept so much work.   The 
implications could be that other SDOs pick-up the slack.  Instead of 
3GPP(2)/IEEE/ITU-T bringing work to the IETF, they could do it themselves.  
3GPP is doing a lot with SIP, let them handle it; 3GPP2 is using Mobile IP, let 
them continue the development; IEEE could handle RADIUS & EAP; ITU-T could 
handle AAA & QoS; let's let the ATM Forum handle all of the Sub-IP layer stuff. 
My feeling is that the IESG has been concerned that this would cause 
fragmentation and a lot of problems.  Another result of pushing back on work 
would mean that vendors might not document their work, or document it via 
vendor specifications.  We also see a rise of open source communities creating 
their own mechanisms for creating running code standards - stuff that is 
documented in Linux Kernel updates, SourceForge sites, or simply documented in 
running code.

I think all of the above scenarios are already happening, to some extent, 
today.  The question is, do we want the IETF to assume responsiblity for key 
pieces of the Internet or not.  If the answer is yes, then the real discussion 
is how to make it happen.  I think sticking with the current model because we 
choose not to think differently is not a good answer.

If I understand some of Dave's and John K's comments, they are willing to 
entertain thoughts on how to do things better (& differently) in order to 
ensure that the IETF remains relevant.

John L.


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

NSIS Interim Meeting

[john . loughney]

This is an announcement of an interim meeting for 
the NSIS working group. Themeeting will be held on May 23rd and 24th in 
Munich Germany.  
 
 The venue of this meeting will be:
 
 
Siemens Conference Center, House Passau
 
Richard-Strauss-Strasse 76
 
81679 München
 
Germany
 
Details on location, travel, hotels, etc. are 
at: http://www.ietf-nsis.org/interim-meeting.htm
 
The planned agenda is:
 
Monday May 23, 2005NTLP Issue UpdateNTLP 
Implementation issuesQoS Template & Model DiscussionQoS NSLP 
Update
 
Tuesday May 24th, 2005NAT/FW NSLP open 
issues3GPP2 Firewall Signaling issuesNSIS Mobility 
Considerations
 
Current drafts to be discussed are:
   
GIMPS: General Internet Messaging Protocol for Signaling 

NSLP for Quality-of-Service signaling A NAT/Firewall NSIS Signaling Layer Protocol (NSLP) 
QoS-NSLP QSpec Template Applicability Statement of NSIS Protocols in Mobile 
Environments RMD-QOSM - The Resource Management in Diffserv QoS 
model
 
Thanks,
John Loughney
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Site selection [Re: reflections from the trenches of ietf62

[John Loughney]

 wireless]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: John Loughney <[EMAIL PROTECTED]>
List-Id: IETF-Discussion 
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
<mailto:[EMAIL PROTECTED]>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
<mailto:[EMAIL PROTECTED]>
Content-Type: multipart/mixed; boundary="===1457750250=="
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]

This is a MIME Message

--===1457750250==
Content-Language: i-default
Content-Type: multipart/alternative;
boundary="EPOC32-FjZHQVsDHCQ+ZRRBwhN984fLdR3v-p7XLYGSDnClhYC3yprY"

This is a MIME Message

--EPOC32-FjZHQVsDHCQ+ZRRBwhN984fLdR3v-p7XLYGSDnClhYC3yprY
Content-Type: text/plain; charset=UTF-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

And just remember that site locals can be problematic ...

--- Original message ---
Subject: Site selection [Re: reflections from the trenches of ietf62
wireless]
From: "Brian E Carpenter" <[EMAIL PROTECTED]>
Time: 03/16/2005 5:39 pm

Jordi,

> In my opinion we need a 200% open process to qualify if a sponsor and =
venue
> are acceptable or not. I'm sure Brian will heard us on this ;-)

Since site selection involves contract negotiations, I doubt if the
actual process can ever be even 100% open. But what can, and IMHO
should be, open is the set of technical and logistical criteria
involved in site selection. Then we have to trust the IAD (not the
Chair, in future) to apply those criteria.

Writing the draft defining those criteria is distinct from
updating the draft on hosting requirements, I think, and needs
an editor Of course I would be suspicious if one of the
criteria stated "Must take place in the capital of Spain" :-)

Brian


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
--EPOC32-FjZHQVsDHCQ+ZRRBwhN984fLdR3v-p7XLYGSDnClhYC3yprY
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMiBG
aW5hbC8vRU4iPg0KPEhUTUw+IA0KPEhFQUQ+IA0KPFRJVExFPkNvbnZlcnRl
ZCBmcm9tIFJpY2ggVGV4dDwvVElUTEU+DQo8TUVUQSBIVFRQLUVRVUlWPSJD
b250ZW50LVR5cGUiIENPTlRFTlQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYt
OCI+PE1FVEEgTkFNRT0iZ2VuZXJhdG9yIiBDT05URU5UPSJydDJodG1sIGNv
bnZlcnRlciI+DQo8L0hFQUQ+IA0KPEJPRFkgQkdDT0xPUj0iI2ZmZmZmZiIg
VEVYVD0iIzAwMDAwMCI+DQo8RElWIEFMSUdOPUxFRlQ+QW5kIGp1c3QgcmVt
ZW1iZXIgdGhhdCBzaXRlIGxvY2FscyBjYW4gYmUgcHJvYmxlbWF0aWMgLi4u
PC9ESVY+IA0KPERJViBBTElHTj1MRUZUPiZuYnNwOzwvRElWPjxESVYgQUxJ
R049TEVGVD4tLS0tLS0tLS0tLS0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2Ug
LS0tLS0tLS0tLS0tLS0tLS0tLTwvRElWPiANCjxESVYgQUxJR049TEVGVD5T
dWJqZWN0OiBTaXRlIHNlbGVjdGlvbiBbUmU6IHJlZmxlY3Rpb25zIGZyb20g
dGhlIHRyZW5jaGVzIG9mIGlldGY2Mg0KIHdpcmVsZXNzXTwvRElWPiANCjxE
SVYgQUxJR049TEVGVD5Gcm9tOiAiQnJpYW4gRSBDYXJwZW50ZXIiICZsdDti
cmNAenVyaWNoLmlibS5jb20mZ3Q7PC9ESVY+IA0KPERJViBBTElHTj1MRUZU
PlRpbWU6IDAzLzE2LzIwMDUgNTozOSBwbTwvRElWPiANCjxESVYgQUxJR049
TEVGVD4mbmJzcDs8L0RJVj48RElWIEFMSUdOPUxFRlQ+Sm9yZGksPEJSPjwv
RElWPiANCjxESVYgQUxJR049TEVGVD4mZ3Q7IEluIG15IG9waW5pb24gd2Ug
bmVlZCBhIDIwMCUgb3BlbiBwcm9jZXNzIHRvIHF1YWxpZnkgaWYgYSBzcG9u
c29yIGFuZCB2ZW51ZTxCUj4mZ3Q7IGFyZSBhY2NlcHRhYmxlIG9yIG5vdC4g
SSdtIHN1cmUgQnJpYW4gd2lsbCBoZWFyZCB1cyBvbiB0aGlzIDstKTxCUj48
L0RJVj4gDQo8RElWIEFMSUdOPUxFRlQ+U2luY2Ugc2l0ZSBzZWxlY3Rpb24g
aW52b2x2ZXMgY29udHJhY3QgbmVnb3RpYXRpb25zLCBJIGRvdWJ0IGlmIHRo
ZTxCUj5hY3R1YWwgcHJvY2VzcyBjYW4gZXZlciBiZSBldmVuIDEwMCUgb3Bl
bi4gQnV0IHdoYXQgY2FuLCBhbmQgSU1ITzxCUj5zaG91bGQgYmUsIG9wZW4g
aXMgdGhlIHNldCBvZiB0ZWNobmljYWwgYW5kIGxvZ2lzdGljYWwgY3JpdGVy
aWE8QlI+aW52b2x2ZWQgaW4gc2l0ZSBzZWxlY3Rpb24uIFRoZW4gd2UgaGF2
ZSB0byB0cnVzdCB0aGUgSUFEIChub3QgdGhlPEJSPkNoYWlyLCBpbiBmdXR1
cmUpIHRvIGFwcGx5IHRob3NlIGNyaXRlcmlhLjxCUj48L0RJVj4gDQo8RElW
IEFMSUdOPUxFRlQ+V3JpdGluZyB0aGUgZHJhZnQgZGVmaW5pbmcgdGhvc2Ug
Y3JpdGVyaWEgaXMgZGlzdGluY3QgZnJvbTxCUj51cGRhdGluZyB0aGUgZHJh
ZnQgb24gaG9zdGluZyByZXF1aXJlbWVudHMsIEkgdGhpbmssIGFuZCBuZWVk
czxCUj5hbiBlZGl0b3IuLi4uIE9mIGNvdXJzZSBJIHdvdWxkIGJlIHN1c3Bp
Y2lvdXMgaWYgb25lIG9mIHRoZTxCUj5jcml0ZXJpYSBzdGF0ZWQgIk11c3Qg
dGFrZSBwbGFjZSBpbiB0aGUgY2FwaXRhbCBvZiBTcGFpbiIgOi0pPEJSPjwv
RElWPiANCjxESVYgQUxJR049TEVGVD4gICAgQnJpYW48QlI+PC9ESVY+IA0K
PERJViBBTElHTj1MRUZUPjxCUj5fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxCUj5JZXRmIG1haWxpbmcgbGlzdDxC
Uj5JZXRmQGlldGYub3JnPEJSPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL2lldGY8QlI+PC9ESVY+IA0KPC9CT0RZPg0KPC9IVE1M
PiANCg==

--EPOC32-FjZHQVsDHCQ+ZRRBwhN984fLdR3v-p7XLYGSDnClhYC3yprY--




--===1457750250==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

__

Re: UPDATE - mp3 audio streaming...

[John Loughney]

Title: Converted from Rich Text

 
 

Yeah, I've had trouble with Jabber too. I was the Jabber scribe in multi6 yesterday and it just stopped working halfway through. Noone had communication, even though the wireless was working, more or less. 
 John  
 --- Original message --- 
Subject: Re: UPDATE - mp3 audio streaming... 
From: "Ken Raeburn" <[EMAIL PROTECTED]> 
Time: 03/09/2005 11:33 am 
 On Mar 9, 2005, at 11:23, Tony Hansen wrote:> So far, the mp3 streams have been quite a success. From the feedback > I've heard, the audio quality has been mostly excellent. When combined > with the xmpp/jabber rooms, we have a two way communication path, and > several meetings I've been in have used this combination quite > effectively. 
In krb-wg this morning, I've heard reports of people being unable to join the jabber chat rooms, including at least one person listed as being in the chat room but report (by email) unable to send anything.  (Haven't heard of problems with audio though.) 
Ken 
___Ietf mailing listIetf@ietf.orghttps://www1.ietf.org/mailman/listinfo/ietf 

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

Re: What problems does the draft cut-off solve? (was: Re: MARID

[John Loughney]

 back   from the grave?)
Cc: Spencer Dawkins <[EMAIL PROTECTED]>, IETF 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Well, it is a mess. I couldn't even start making a wg schedule, as my  wg 
wasn't scheduled until yesterday. I even sent my reuest for a slot in December! 
It seems that scheduling is getting to be an impossible task.

John

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

Re: Re: MARID back from the grave?

[John Loughney]

Hi Keith,

Working groups have a charter, which I think should be viewed as a contract for 
what the working group will work on / develop.  When a working group wants to 
adopt a new draft, they need to have permission from the AD and may even need 
to revise the charter to be able to adopt the work.

This, I think, shows a clear intent by the WG chair and the AD that a draft has 
some merit and at least an informal commitment to progressing the document.

I don't see it as a binding contract, but it does imply that the draft should 
progress.

John
> 
> From: Keith Moore 
> Date: 2005/02/27 Sun AM 05:18:57 EET
> To: kw2578 <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED],  moore@cs.utk.edu,  ietf@ietf.org
> Subject: Re: MARID back from the grave?
> 
> > Graham,
> > 
> > You are right. WG dtafts have a more official standing iin the IETF,
> > they will, most likely, become an RFC. 
> 
> I hope not.  When a WG agrees to consider a draft it should not be taken
> as an assurance that the draft will be published as an RFC.  Too many
> WGs work far beyond their chartered deadlines because they haven't 
> finished all of their working drafts - often because those drafts turned
> out to be bad ideas or not sufficiently well-understood or robust to 
> warrant standardization (or sometimes, even publication).
> 
> Keith
> 
> 
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 


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

Re: IDN security violation? Please comment

[John Loughney]

Title: Converted from Rich Text

 
 

SMS's for some languages are indeed in unicode, often one message is sent in a multipart message - i.e. - in more than one message. Even in various Nordic languages that have strange things like Ã, Ã, Ã ... SMS's are sent in unicode. 
 Some cell phones sport pen input, but also support Asian text input via a stroke system via the normal digit keypad. 
 John 
 --- Original message --- 
Subject: Re: IDN security violation? Please comment 
From: "Harald Tveit Alvestrand" <[EMAIL PROTECTED]> 
Time: 02/10/2005 10:21 pm 
  
--On torsdag, februar 10, 2005 10:49:50 -0500 Bruce Lilly <[EMAIL PROTECTED]> wrote: 
> 1. I have in mind a keyboard on a certain device which has>support for protocols which use domain names (HTTP, SMTP/>Internet Message Format, VPIM).  It has a keyboard which>is at best inconvenient for entry of ASCII text. Unicode>"text" (see below for an explanation of the scare quotes)>is unthinkable.  That device is a cell phone. 
Note that the SMS service is popular in Asia too - and there, the characters sent are definitely not ASCII. 
No, I have no idea how they type them - but they do. 
 
___Ietf mailing listIetf@ietf.orghttps://www1.ietf.org/mailman/listinfo/ietf 

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

Re: WG Review: IPv6 over IEEE 802.15.4 (lowpan)

[John Loughney]

Title: Converted from Rich Text

 
 

Low power PAN - personalarea network. But then I wade through these acronyms for my day job. 
 John 
 --- Original message --- 
Subject: Re: WG Review: IPv6 over IEEE 802.15.4 (lowpan)  
From: "Spencer Dawkins" <[EMAIL PROTECTED]> 
Time: 02/09/2005 9:11 pm 
 This may be a mindstoppingly stupid comment, but "LowPAN" isn't exactly a commonly-used term in my end of the swamp, and it wasn't defined on the WG Review announcement ("go read the drafts", I guess?). If you charter the WG, it would be lovely to define it on the WG home page... 
Spencer  
 
___Ietf mailing listIetf@ietf.orghttps://www1.ietf.org/mailman/listinfo/ietf 

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

Re: Rough consensus? #425 3.5

[John Loughney]

Steve's email caused me to think, but first let me say that this should not be 
in the BCP.  Is it a correct assumption to think that the IASA will give an 
update at every IETF plenary, along the lines of IANA and the RFC Editor? I 
would hope so.

John L.

-- original message --
Subject:Re: Rough consensus? #425 3.5
From:   "Steve Crocker" <[EMAIL PROTECTED]>
Date:   01/19/2005 6:03 pm

I have not been paying close attention to the debate over this section 
of the BCP before, so I may be covering a point that's been made before.

I think there will necessarily be a mixture of formal and informal 
processes at work once the IASA is in operation.  The IAOC is intended 
to be at once both independent of the day to day operation of the IESG 
and IAB so it can relieve them of the burden of managing the details on 
a day to day basis and at the same time responsive to the community.  No 
matter what formal mechanisms are put in place, the IAOC needs to keep 
its eyes and ears open to understand how well it is serving the 
community's needs.  Inevitably, there will be some decisions or actions 
that some will complain about.  When things are working well, the IAOC 
will find useful ways of respoding to such complaints, either by 
explaining the situation more fully, adjusting its decisions and 
actions, or, when the complaints simply represent a small minority with 
an unresolvable difference of opinion, standing firm.

Formal means for resolving disputes do need to exist.  I haven't studied 
Margaret's formulation carefully, but on first glance it looks fine to 
me.  Other formulations will also work.  As we all know, if there are 
very many formal disputes, then something larger is probably broken and 
needs to be fixed.  I'm confident the community will raise the noise 
level in that case and we'll be re-engaged in a full, open, community 
review of the IASA, IAOC, etc.

The bottom line on this for me is that everyone should expect the IAOC 
to report regularly and substantively to the community and to listen 
carefully to the community, and that form of communication will be the 
primary safety valve.

Steve

Margaret Wasserman wrote:
> 
> Okay, Harald indicated to me privately that I should be more specific 
> about my objections to the current wording and offer some alternative, 
> so here goes...
> 
> I do not object to the use of the term "review" instead of "appeal".
> 
> However, I do object to the current wording proposed by Harald for two 
> reasons:
> 
> (1) I think that there should be an effective way for members of the 
> community (not just members of the I*) to question the decisions of the 
> IAOC and receive some response.  If a wrong decision was made, it may 
> not always be possible to reverse the decisions of the IAOC (contracts, 
> etc.), but it could be possible to consider the situation and create new 
> rules or guidelines to prevent a similar situation from occurring in the 
> future.
> 
> (2) I don't think that the mechanism is appropriately specified.  If we 
> used the appeals mechanism in 2026, there is already a definition and 
> some practical history.  I understand there is some objection to using 
> that mechanism, but if we want to invent a new one, then I think we need 
> to specify it so that a member of he community (not just I* members) 
> could actually use it.
> 
> Here is a stab at some alternative wording...
> 
> --
> 3.5 Decision review
> 
> In the case where someone believes that a decision of the IAD or the IAOC
> he or she may ask for a formal review of the decision by sending e-mail
> to the IAOC chair.  The request for review is addressed to the IAOC, and
> should include details of the decision that is being reviewed, an 
> explanation
> of why the decision should be reviewed, and a suggestion for what action
> should be taken to rectify the situation.  All requests for review will be
> published publicly on the IAOC web site.
> 
> It is up to the IAOC to determine what level of formal review is required
> based on the specifics of the request for review.  However, the IAOC is
> expected to make some public response to a request for review within
> 90 days of the request, indicating the findings of the review.
> 
> If the IAOC finds that an incorrect or unfair decision was made, it will be
> up to  the IAOC to decide what type of action, if any, makes sense as a
> result.  In many cases, it may not be possible or practical to change the
> decision (due to signed contracts or business implications), but the IAOC
> may choose to make changes to its policies or practices to avoid similar
> mistakes in the future or may simply wish to acknowledge that  a mistake
> was made and learn from the error.
> 
> If a person believes that his or her request for review was not handled
> properly or fairly by the IAOC, he or she may escalate the request to the
> IESG by sending mail to the IETF chair.  The I

Re: Last Call Comments on draft-iasa-bcp-04.txt

[John Loughney]

Again. I agree with Sam and John here.  Getting out of the over specification 
here is important.  The IASA will need to write-up some rules, but I think this 
BCP is the wrong place, having some operational experience is important.

John L.

-- original message --
Subject:Re: Last Call Comments on draft-iasa-bcp-04.txt
From:   "Sam Hartman" <[EMAIL PROTECTED]>
Date:   01/17/2005 8:00 pm

> "John" == John C Klensin <[EMAIL PROTECTED]> writes:

John> How the text should be fixed depends a bit on what we do
John> about that "outsourcing" assumption, to which I continue to
John> object. If we can lose it, the paragraph might end up
John> reading something like:

John> The IAOC is expected to determine what IETF
John> administrative functions are to be performed, and how or
John> where they should be performed (e.g., internally to the IASC
John> or by outside organizations), so as to maintain an optimal
John> balance of functional performance and cost of each such
John> function.  The IAOC should document all such decisions, and
John> the justification for them, for review by the
John> community. Each function should be reviewed on a regular
John> basis, using the assumption that the function is unnecessary
John> and that, if necessary, it is overstaffed, rather than an
John> assumption that anything that has been done is necessary,
John> and adjusted as needed.

John> That probably still needs word smithing.  The second
John> sentence may be redundant enough with other statements in
John> the BCP that it can be removed.  And the last sentence is a
John> bit long.  But it is at least relatively jargon-free.

I support the intent of this paragraph and the implied move away from
the current out sourcing text.  I think the last sentence could use
some work but could accept the current text.

--Sam


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


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

Re: iasa-bcp-04: unanimity in section 3.4

[John Loughney]

> Proposed change: Get rid of "unanimous" (both times), replacing
> it with "consensus" and appropriate editorial smoothing.

I agree.

John L


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


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

Re: An M2PA Question

[John Loughney]

Haritha,

You might want to ask on the SIGTRAN list -  
www.ietf.org/html.charters/sigtran-charter.html.

John

--- Original message ---
Subject: An M2PA Question
From: "haritha g" <[EMAIL PROTECTED]>
Time: 01/13/2005 3:54 pm

Hi

I had a question regarding association mapping for
M2PA. Can some one give me more information as to what
information needs to be maintained to perform the SLC
to association mapping in the M2PA layer?

Regards
Haritha






__ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail

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


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

Re: Suggest no change: #739 Assuring ISOC commitment to AdminRest

[John Loughney]

I agree with Brian & John K.

John L.

-- original message --
Subject:Re: Suggest no change: #739 Assuring ISOC commitment to 
AdminRest
From:   "Brian E Carpenter" <[EMAIL PROTECTED]>
Date:   01/14/2005 11:49 am

John C Klensin wrote:
> Pete,
> 
> I still think this is misdirected energy.
> 
> But, in the interest of finding a reasonable compromise and
> moving on, let me make a suggestion:
> 
>   (1) We let the current text and resolution style stand,
>   so that bylaw changes don't become a gating factor [note
>   1 below].
>   
>   (2) We ask the current, sympathetic, helpful,
>   supportive, ISOC Board to consider a bylaws modification
>   that does not single out the IETF Administrative Entity...

(details deleted)

I think this is the only realistic approach. Pete asked why it takes
months to get the by-laws amended. Well, it's because a corporation
takes its by-laws seriously, will need to debate the text, get
legal review, and finally take a formal vote. Corporation law requires
that formal vote to be face to face or conference call, not email.
It just takes time, whereas I would hope that a resolution endorsing
the BCP would take a couple of weeks. [Truth in advertising: the email
vote on a resolution has to be confirmed face to face, but that is
truly a formality.]

(Side note - I wouldn't go near the Articles of Incorporation. If they
get modified, it's likely to trigger a review of ISOC's non-profit
tax status and that is nuisance for no reason.)

 Brian

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


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

Re: Consensus search: #725 3.4b Appealing decisions

[John Loughney]

I agree.

John L.
-- original message --
Subject:Re: Consensus search: #725 3.4b Appealing decisions
From:   Brian E Carpenter <[EMAIL PROTECTED]>
Date:   01/13/2005 3:08 pm

I think this is acceptable given that we *also* have a recall
procedure. In other words, if the IAOC isn't responsive
to a clear message from a review that "you screwed up", then
we'd better make sure that a recall is initiated.

Brian

Harald Tveit Alvestrand wrote:
> On reviewing #725 on appealing decisions, and the crosslinked #720 on 
> IAD autonomy, I sense a disquiet in the community.
> 
> On the one hand, we recognize that a well functioning IAD and IAOC needs 
> to be allowed to run the show without a thousand people trying to "put 
> their hands on the tiller".
> 
> On the other hand, the community is deeply uneasy about setting up a 
> situation where we have decisions being made that profoundly affect the 
> working of the IETF, and if we disagree with the decision, the only 
> response we can get from anyone in authority is "I made the decision. Go 
> away."
> 
> The second concern was perhaps best expressed by Avri Doria:
> 
>> A letter of complaint requires no response unless there is something
>> that formalizes the requirement of response.
>>
>> And if there is no procedure indicating that the IAOC needs to pay
>> attention to a letter of complain, that decision, i.e the one to ignore
>> letters of complain, cannot be appealed.
>>
>> So, as I see it, without a formalized process of complaint/appeal of
>> IAD actions we are left with no avenue to deal with problems other then
>> by the yearly nomcom process and the IETF list.
> 
> 
> And the first viewpoint was perhaps best expressed by John Klensin:
> 
>> If people don't believe that The Right Thing is being done, they
>> shouldn't be looking in detail at particular decisions. They
>> should, instead, be suggesting that the IAOC review its own
>> decisions contributing whatever additional information is
>> available to that review. And, if the IAOC adopts a pattern of
>> doing Wrong Things, it should be time to replace them (starting
>> with a request for resignations), not to try to retune or
>> override individual decisions.
>>
>> Get the right people into these positions, and then let them do
>> the job.
>>
>> If we can't find the right people and put them there, then none
>> of these procedures --other than firing the duds and trying
>> again-- are good enough to protect the IETF. Perhaps worse, we
>> then run the risk of getting us seriously bogged down while we
>> try to use those incremental correction procedures.
> 
> 
> In the debate, I suggested a resolution that involved keeping the 
> in-draft version of the appeals procedure, with three differences:
> 
> - Not limited to procedure, and not limited to the IAOC
> - Abandoning the "chain" model of "if you don't like one decision, try
> again" that the current appeal structure has
> - Not using the word "appeal"
> 
> While debate did not stop, this did not seem like a bad idea.
> 
> So here's another attempt at section 3.5, replacing the last 3 
> paragraphs of section 3.4:
> 
> 3.5 Decision review
> 
>   In the case where someone questions a decision of the IAD or the
>   IAOC, he or she may ask for a formal review of the decision.
> 
>   The request for review is addressed to the person or body that made
>   the decision. It is up to that body to decide to make a response,
>   and on the form of a response.
> 
>   The IAD is required to respond to requests for a review from the
>   IAOC, and the IAOC is required to respond to requests for a review
>   of a decision from the IAB or from the IESG.
> 
>   If members of the community feel that they are unjustly denied a
>   response to a request for review, they may ask the IAB or the IESG
>   to make the request on their behalf.
> 
>   Answered requests for review and their responses are made public.
> 
> I think that should be enough - the IAD and IAOC can route all frivolous 
> requests to /dev/null; the decision of the IESG to not ask the IAOC for 
> a review is an IESG action that can be handled in the usual way; there 
> is no formal "I can overturn your decision" involved; if the IAOC shows 
> a pattern of replying "go away" when a review is requested, that becomes 
> a matter of public record, and can be used at nomcom time.
> 
> Does this seem like a reasonable point on the various scales of concern?
> 
>   Harald
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 

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


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

Re: Consensus? #733 Outsourcing principle

[John Loughney]

Title: Converted from Rich Text

 
 

"Minimum staff required" seems uncomfortably worded to me. I am not sure we need to go into this detail, for the reason Scott listed. If we do need to have this leel of detail, could we say 'sufficient staff' or something along those lines? 
 John L 
 --- Original message --- 
Subject: Re: Consensus? #733 Outsourcing principle 
From: "Scott W Brim"  
Time: 01/12/2005 7:29 am 
 On 1/12/2005 04:51, Harald Tveit Alvestrand allegedly wrote: 
> In principle, IETF administrative functions should be> outsourced. Decisions to perform specific functions> "in-house" should be explicitly justified by the IAOC> and restricted to the minimum staff required, with these> decisions and staffing reviewed by the IAOC on a regular> basis and against a "zero base" assumption.>"Minimum staff required" is a little difficult.  One can do anything with existing staff if quality and timeliness don't matter.  The IAOC has to determine those parameters as part of deciding staffing levels.  I suggest "minimum staff required to perform the functions satisfactorily as determined by the IAOC", or something along those lines. 
Scott 
___Ietf mailing listIetf@ietf.orghttps://www1.ietf.org/mailman/listinfo/ietf 

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

Re: Other change needed? #722 - 5.4 - ISOC off-account payment for expenses

[John Loughney]

Title: Converted from Rich Text

 
 

I think your text is reasonable. 
 John L. 
 --- Original message --- 
Subject: Other change needed? #722 - 5.4 - ISOC off-account payment for
 expenses 
From: "Harald Tveit Alvestrand" <[EMAIL PROTECTED]> 
Time: 01/12/2005 12:10 pm 
 Bernard Aboba said, and it seems nobody commented: 
> Section 5.4>> " Other ISOC support shall be based on the budget process as specified in> Section 6IASA Budget Process. ISOC shall credit the appropriate IASA> accounts at least quarterly.>> If ISOC pays any other IETF expenses directly, without transferring funds> to the IASA, this shall be documented as a footnote to the IASA accounts.">> I think we want to state explicitly that any such other ISOC support shall> be considered to be an irrevocable donation to the IASA, rather than a> debt to ISOC, if and when the Removability clause of Section 7 is invoked. 
I think this is too much detail for the BCP, but want to restructure this - the "footnote" paragraph is too much detail too. 
I suggest that 5.4 be rephrased as: 
5.4  Other ISOC Support 
   Other ISOC support shall be based on the budget process as specified   in Section 6, which includes deciding when ISOC monetary support is   to be credited to the IASA accounts. 
   All ISOC support, no matter how it is delivered, shall be reported   in the IASA financial reports. 
Note that this removed the rather stilted language of "ISOC shall periodically credit..." - as I mentioned in the "general finances" message, this will in practice only affects the reporting; the money stays in the same set of bank accounts. 
What do people think? 
Harald 
___Ietf mailing listIetf@ietf.orghttps://www1.ietf.org/mailman/listinfo/ietf 

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

Re: Consensus? #733 Outsourcing principle

[John Loughney]

Title: Converted from Rich Text

 
 

This seems reasonable to me. 
 John L. 
 > John Klensin suggested the following text for the first sentence, and > Scott Bradner supported the idea:> > In principle, IETF administrative functions should be> outsourced. Decisions to perform specific functions> "in-house" should be explicitly justified by the IAOC> and restricted to the minimum staff required, with these> decisions and staffing reviewed by the IAOC on a regular> basis and against a "zero base" assumption.> > We have to adjust the second sentence (referring to "such contracts" > would become ambiguous), so the total paragraph becomes:> >   In principle, IETF administrative functions should be>   outsourced. Decisions to perform specific functions>   "in-house" should be explicitly justified by the IAOC>   and restricted to the minimum staff required, with these>   decisions and staffing reviewed by the IAOC on a regular>   basis and against a "zero base" assumption.> >   The IAD is responsible for negotiating and maintaining outsourcing>   contracts, as well as providing any coordination necessary to make>   sure the IETF administrative support functions are covered properly.>   The IAOC is accountable for the structure of the IASA and thus>   decides which functions are to be outsourced.  All outsourcing must>   be via well-defined contracts or equivalent instruments.  Both>   outsourced and in-house functions must be clearly specified and>   documented with well-defined deliverables, service level agreements,>   and transparent accounting for the cost of such functions.> > Is that OK with everyone? Case closed? 

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

Re: Timeline for further work on IASA BCP

[John Loughney]

Title: Converted from Rich Text

 
 

Harald, 
 This sounds reasonable to me.  How long do you are you planning to give us to review the updated draft? I've put off doing a thorough review of the draft (mostly just lurking on the discussions here) as it has been difficult to keep up with changes. 
 John 
 --- Original message --- 
Subject: Timeline for further work on IASA BCP 
From: "Harald Tveit Alvestrand" <[EMAIL PROTECTED]> 
Time: 01/12/2005 11:07 am 
 At the moment, there are 19 open tickets in the issue tracker. Some of these are overlapping. 
Of these, I think only issue #740 has been raised by people who speak for ISOC; I am not sure whether it means that ISOC is otherwise OK with the text or that ISOC has not sent comments yet. 
Lynn Duval (ISOC) has reviewed the document from a financial perspective, and sent comments. The editors have scheduled a meeting with her next week to check the current wording.Jorge Contreras (the IETF lawyer) is reviewing the document from a legal perspective. More review is, of course, welcome! 
My current plan for this week is: 
- Today: Attempt to send "Consensus?" messages on the remaining 19 issues, if I think that's possible 
- Friday morning, US-ET: Submit a revised draft (-04) to the internet-drafts editor. 
- Friday afternoon, once I-D is published: Send out a note on this list asking 2 questions:  - Is the draft now good enough?  - Do we need to reissue, lengthen or restart the Last Call? 
The next two steps are contingent on a "no" answer on the last question: 
- Thursday, Jan 20: Put the document before the IESG for IESG review and possible approval. If the discussion indicates that IETF community members require more time for review, I will place a DISCUSS vote on the document that will remain in force until I conclude that the community says that it has had enough time to review. I think it unlikely that it can be passed on this date, but it is good to have the formal IESG review done. 
- The next IESG telechat is on Thursday, Feb 3. Given that the document is discussed at one IESG telechat, it is possible to have it approved between telechats, if community consensus indicates that this is the Right Thing. Otherwise, we discuss it again here. 
Seems like a plan? 
  Harald 
 
 
___Ietf mailing listIetf@ietf.orghttps://www1.ietf.org/mailman/listinfo/ietf 

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

Re: Transparency/Openness of the IAOC

[John Loughney]

Brian's response seems reasonable to me.

John
--- Original message ---
Subject: Re: Transparency/Openness of the IAOC
From: "Brian E Carpenter" <[EMAIL PROTECTED]>
Time: 12/08/2004 3:53 pm

Margaret Wasserman wrote:
> 
> Hi All,
> 
> In reviewing the IASA BCP draft, I noticed that there are no specific 
> requirements regarding the level of transparency or openness expected 
> from the IAOC.  IMO, we should be careful to start this activity with a 
> well-established understanding regarding the level of transparency and 
> openness that we expect.
> 
> Do we expect the IAOC to keep minutes of their meetings and post them 
> publicly (unless there is a specific reason not to post a certain 
> section)?  Specific reasons might include:  personnel issue and/or 
> sensitive negotiation-position-related information.

yes

> 
> Do we expect the IAOC mailing list archives to be publicly available?

no, that would prevent any email on sensitive contractual or personnel
issues

> 
> Should the IAOC maintain a web site that lists its members and their 
> e-mail addresses?

on ietf.org

> 
> Should the same web site also include a record of all written/legal 
> correspondence received by or sent by the IAOC (with sections removed if 
> absolutely necessary for confidentiality)?

I think that is an onerous requirement

> 
> Should all of the official IAOC decisions be announced publicly?

yes, ietf-announce

> And/or 
> do we expect a regular (monthly?) report on IAOC activities?

I'd say the mandatory frequency should be per IETF meeting

> 
> If we think that it is reasonable to require any of these things, which 
> ones should apply to the IASA TT that we just formed?

exactly the same ones

IMHO
Brian

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


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

Re: The gaps that NAT is filling

[John Loughney]

Title: Converted from Rich Text

 
 

Margaret, 
 > These users care about ease of deployment, > cost and avoiding unscheduled outages (whether due to security issues > or ISP changes) 
 Don't know about you, but if ever I have connectivity problems, the fiirst thing my provider wants me to do is power cycle the home gateway / router / NAT. All of that NAT state doesn't get cleared. Tihngs are only getting worse. Long live the e2e principle. 
 John 

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

Re: How the IPnG effort was started

[John Loughney]

Title: Converted from Rich Text

 
 

Hi Paul, 
 As you are aware, just because it is possible doesn't make it a good idea. 
 John 
 --- Original message --- 
Subject: Re: How the IPnG effort was started 
From: "Paul Vixie" <[EMAIL PROTECTED]> 
Time: 11/20/2004 8:19 pm 
 let me apologize in advance.  it's saturday here and i'm behaving offtopicly. 
> One question.  Governments don't assign street adresses at birth, why> would they assign IP addresses? IP addresses are addresses, not Internet> Identifiers. 
well, here in the land of the PATRIOT act, there's been some discussion oftaking a DNA sample at birth and keeping it on file.  a one-way hash of thenumerical analysis of the sample would make a very unique value.  think ofit as the human equivilent of ethernet's 48-bit MAC address.  don't laugh,this kind of thing plays really well in "the red states" where the executivebranch of the U.S. government is trusted beyond any possible reproach. 
128 bits ought to be just about right.  so, ipv6 may yet come into vogue.-- Paul Vixie 
___Ietf mailing list[EMAIL PROTECTED]https://www1.ietf.org/mailman/listinfo/ietf 

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

Re: How the IPnG effort was started

[John Loughney]

Title: Converted from Rich Text

 
 

One question.  Governments don't assign street adresses at birth, why would they assign IP addresses? IP addresses are addresses, not Internet Identifiers. 
 John 
 --- Original message --- 
Subject: Re: How the IPnG effort was started 
From: "JFC (Jefsey) Morfin" <[EMAIL PROTECTED]> 
Time: 11/20/2004 5:13 am 
 On 19:10 19/11/2004, Kurt Erik Lindqvist said:>I have long thought that the knowledge of having long (life-long)>persistent, well-spread unique personal identifiers are bad was general>knowledge. Then again, I guess the US biometric stuff has proven me>wrong on that already. 
I am not sure I understand the English of this remark. I suppose you mean that you thought if everyone known a user 's persistent number the user would be worried? If this is the case, it only makes my points that IETF lacks market studies and reporting from the end-users. This a general demand that Telephone companies hesitated to provide due to the complexity until mobiles came in. Now it is a simple common demand to have on fixed lines the same features as on mobiles (permanent and temporary numbers). 
This does not mean that you are bound to a single number, the same you are not bound to a single mobile. Let not think "the users should do it the way I think", but "I am to permit the users to do it the way I never thought they would do it", because it is generally the way these people behave  
Does this respond your remark? 
>I am going for the sake of argument to go along with your reasoning>above (although I don't agree). Apparently there is something here to>be gained, as we need to 'promote' a particular technology that is>under control of intergovernmental treaties. First of all, what would>the sales pitch be? I am seriously interested, and as you are arguing>for this model you must have an answer. Second, if I understand you>correctly above, you are implying this is not a 'free service' today,>while it would be under the ITU, sanctioned by governments. Correct? In>your view, how would allocations of IP addresses and ports, and>protocol numbers be made? Last, how would a address policy process look>like under the ITU and international treaties? 
OK. Until this threat I was embarrassed because I thought that "real world evidences" were too far away from IPv6 designers. When Quite - and Aaron confirmed - said that IPv6 was IPv4 with larger addresses, I started thinking that we could make it, even with NATs which belong to the IPv4 world. Let consider what is new in IPv6 and where are the problems. 
We have several propositions :- IPv6=IPv4+longer addresses- NGN is many things needing long addresses (may be /256) using IP as their core (ITU)- IETF is accustomed to small ISP operators, the rest of the world deregulates big Telcos.- there are 800 millions of Internet users and 1.3 billions of mobile owners. 
NGN shows that the world (in general) is not opposed to the IP technology. OK.Web deployment and mobiles show that the users have developed a brainware where names and numbers have their different roles which are not far from their technology purpose and that people know how to play with them. OK.Everyone agrees that we need more addresses; so everything seems fine. Except that it does not catch. Why ? 
I think it does not catch, because this is the old IPv4 model, that it still relies on ISPs and that if addresses are longer they still are far too short. Because they are managed by RIRs who have no societal and no political power. But mainly because we consider the wrong product: no one is interested in the Version 6 of the IP protocol. There are a lot of people interested in the management and political capacity to manage /128 long addresses. 
The real product is the addressing plan. And the reasons why no one is excited are that: 
- these addresses are managed "a la IPv4", as a unique Vint Cerf's/ICANN numbering area. This is what they want to correct with ITU. I submit there is no conflict. IPv6 has 6 different numbering plans. Let say that 001 is for the US Vint's legacy and 011 for international. That Vint can manage the 001 area and the ITU the 011 area. This is status quo. 
- now, the way ITU wants to manage the international digital address numbering plan is in using DCC (or the like). (DCC is data country code). The same as there are ccTLDs in naming. So Frank has no problem for his SOPAC islands. They are entitled as many addresses as others. Does that change anything for the RIRs and the routing? No, this is simple address management. 
- the way the countries will manage their numbering space is up to them. But if I refer to the telephone solutions, my guess is that many will differentiate routing and addressing in a very simple way (and this is certainly what the ART (French FCC) wants to hear about - because this is what users want : IP addresses are to be independent from the ISP). This means that they will allo

Re: How the IPnG effort was started

[John Loughney]

Title: Converted from Rich Text

 
 

Spencer, 
 Inertia is actually a fairly stong force, and IPv4 has a lot of it. 
 I'd be happy to point out some shipping products & announcements from carriers about IPv6, however. 
 John 
--- Original message --- 
Subject: Re: How the IPnG effort was started 
From: "Spencer Dawkins" <[EMAIL PROTECTED]> 
Time: 11/18/2004 11:10 pm 
 I apologize in advance for feeding this thread, but the conversation seems to be diverging from what I thought we had actually been previously... 
IIRC, we've semi-recently been off to the land of "PCs in homes and cell phones". I can say I was honestly dismayed that cable providers in the United States went to IPv4 instead of IPv6, but they did. I can say I was honestly dismayed to learn (in the past year) that the Push-to-talk Over Cellular (PoC) 1.0 specifications (*) changed the 3GPP IMS specifications (that required IPv6) to use IPv4 instead. But that's what's been happening lately. 
I'm not nearly as interested in forecasting the future as some of you guys, but it seems like we do have to recognize that deployment of IPv6 in either residential access or cell phones would reverse some pretty recent trends. Trends do reverse, but I haven't seen a deceleration point yet, much less a "tipping point" in these networks. 
Sorry! 
Spencer 
(*) Available from a variety of places, including http://www.ericsson.com/mobilityworld/sub/open/technologies/ims_poc/docs/poc_relase_1_0_spec 
From: "Peter Ford" <[EMAIL PROTECTED]>Sent: Thursday, November 18, 2004 1:12 PMI think there are at least two possible scenarios: 
1) a bunch of kids in college write cool software and document how theydo it, and band together with other interested parties to form aconsortium of people who build stuff that uses IPv4 as a bearer and runtheir own protocols on top of it (e.g. IPNNG ).  Over time, peoplerecognize there may be economic gain in deploying IPNNG networks. 
2) Some of the incumbents think about (1) and do the same.   They do itwith the two largest constituencies of data networking in the next 5years (PCs in homes and cellphones).   They may have actually startedthe development of same several/many years ago.  They might actuallythink about using IPv6 in place of IPNNG because they are lazier thanbright college kids with time on their hands :-).  
 
___Ietf mailing list[EMAIL PROTECTED]https://www1.ietf.org/mailman/listinfo/ietf 

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

Re: How the IPnG effort was started

[John Loughney]

Title: Converted from Rich Text

 
 

Harold, 
 > Numbers are for losers and technologists. 
 Except that numbers seem to cross a number of languages better than, say, 7-bit ASCII ... YMMV. 
 John 
___Ietf mailing list[EMAIL PROTECTED]https://www1.ietf.org/mailman/listinfo/ietf 

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

802.1x & WPA settings

[john . loughney]

Hi all,

I  couldn't find from the terminal room web page info on the 802.1x or WPA 
settings for the WLAN network.  Anyone have details on the settings needed?

thanks,
John


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

Re: Call for Consensus: IETF Administrative Restructuring

[John Loughney]

I agree with Scott.

John

 Original message 
Subject:Re: Call for Consensus: IETF Administrative Restructuring
Author: "(scott bradner)" <[EMAIL PROTECTED]>
Date:   28th October 2004 9:41:17  AM


> For the documents that are to become RFCs, I most heartily agree.
> Keeping the community informed of what we are doing in detail is slightly 

> different - this is not developing a document, it's keeping our notebook 
in 
> a public place.

I agree with Harald that keeping the notebook in a public place is
a good idea but I happen to agree with Brian that the "right place"
(IETF process wise) is IDs - for two reasons
1/ it follows our written process (which does not limit
   IDs to RFC precursors)
2/ like it or not, there are easy to find archives of IDs and
   that is where people look for IETF 
history

Scott

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


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

Reshuffling those deck chairs!

[John Loughney]

A very small comment - I've noticed that successful IETF protocols have had 
an open source or at least publically available code. This gives groups and 
organizations an opportunity to use these new protocols. I'd generally 
recommend most WGs to consider mechanisms to make code available for the 
protocols they are developing. I now let you retun to the IPR discusssion 


John 


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

a note about the scenarios

[John Loughney]

Title: Converted from Rich Text

 
 

I've skimmed the recent documents and have come away feeling rather  
uninterested in the topic. As with most others, I asume, I'm more interested  
in technical work not aministrative or reorg work. 
 What I assumed would happen is that we would hire a consultant to review 
the possible structures for the IETF (we did). Next would be for that  
consultant to make a recommendation, get buy-in from the major 
stakeholders, then institute the change. 
 I expect most of us don't understand the nuances of tax exempt status, 
(for example) so why are we debating them? I'm not sure that we have the 
correct mix of skills to do this particular task & I prefer to spend my effort on  
the technical work. 
 At the end of the day, any structure we create will have its unintended 
consequences that we will need to engineer around. However, the current  
process is akin to slowly peeling a band aid off rather than just pulling it 
off. Reorgs that I have been involved in that have been long and drawn 
out have tended to impact morale negatively. 
 As this process, starting before Yokohama, has taken so long, my  
assumption is that we will be extremely risk adverse when considering  
change in the future, as well.   

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

Re: seems to work now Re: Hotel online reservations

[john . loughney]

Hi Tim,

I think it was some Minneapolis meeting that I was told to call back at 8 am (local 
time) ... Good to see Washington is a bit more cosmopolitan.

John

-- original message --
Subject:Re: seems to work now Re: Hotel online reservations
From:   Tim Chown <[EMAIL PROTECTED]>
Date:   31st August 2004 12:08:05 pm

On Tue, Aug 31, 2004 at 01:44:04PM +0300, John Loughney wrote:
> 
>It  seems  to  be working now. Nice to book on-line, for those who are
>time zone challenged.

I think the phone lines are there 24x7.   The person I spoke to was very
lively for what would have been at best 4am on the east coast :)

Tim

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


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

seems to work now Re: Hotel online reservations

[John Loughney]

Title: Converted from Rich Text

 
 

It seems to be working now.  Nice to book on-line, for those who are time zone challenged. 
 John 
  Reply header  
Subject: Re: Hotel online reservations 
Author: "Rob Evans" <[EMAIL PROTECTED]> 
Date:  30th August 2004 10:57:22  PM 
 > do not work as advertised. All rooms show booked, despite putting in > correct dates and group code as instructed.Odd.  It worked for me just now, perhaps it has been fixed (or alternatively, I broke it :-)).  YM obviously Vs.Regards,Rob___ 
Ietf mailing list[EMAIL PROTECTED]https://www1.ietf.org/mailman/listinfo/ietf 

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

Re: hop-by-hop and router alert options [Re: Question about use of RSVP in Production Networks]

[John Loughney]

> Of course.  Then why this wasn't the first thing NSIS did after going
> for on-path signalling, or didn't I just manage to find it?  

NSIS was specifically charged to by the Transport ADs to work on on-path signaling. 
There is an analysis document being reviewed by the IESG right now ...

> I really really hope that there has been a problem statement...

Why? I've generally found that problem statement documents have limited usefulness.
> Further point where you can use path-coupled signalling, you mean?  
> Not really, as there seems to be something seriously broken if you
> need set up priorization except in well-defined points in the network.  
> And to achieve that, you could use a "bandwidth broker": either it's
> able to set up the required bandwidth (it's in the same site, or at a
> site your site has a roaming agreement with), or it isn't and the
> approach is going to fail in any case, because the sites out in the
> Internet don't want outsiders to request bandwidth allocations.

As you know from  IPv6 discussions, people's view of what constitutes a site 
is very different. It is not a well defined term. NAT & FW traversal is very 
difficult, especially for signalling incoming connections. We have documentation, if 
you are interested.

Also, there is no standard bw broker. Hoping that there was doesn't help. Currently 
deployed bw brokers have scalability problems, especially if they are meant to scale 
Internet-wide.

> True enough, I had my operator hat on ;-).  My mind just boggled when
> I started to realize that some part of the IETF is still in denial on
> why RSVP didn't go through, and is now in the process of reinventing
> it .. wasting a lot of time and effort that could be much better spent
> on making an operationally more feasible system to provide these
> reservations in a well-defined, constrained points of the network.

Interestingly  enough, there are operators involved in the NSIS discussions. 
Also, some of the protocoà mechanisms of RSVP are suprisingly robust, but not all of 
the design criteria of RSVP hold today.

> What I can't figure why this is happening.  I guess the IESG must have
> been asleep, or the most people just thought, "well.. let them waste
> their energy on that.. at least they don't bother us while they are
> bashing the heads in the wall.."

Before passing such judgements on the IESG, reading the charter would be recommended. 
If you find yourself nearby Helsinki, I'd be happy to explain things.

John


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

RE: Question about use of RSVP in Production Networks

[John Loughney]

Dean,

Just limiting my reply to one point:

>That relegates RSVP to the enterprise Lan, where it usually isn't 
needed.  
>Remember, RSVP is only useful if you have a congestion problem and 
need to
>choose which packets to discard.  If you have no congestion problem, 
then
>you have no need of RSVP. However, having a congestion problem also 
opens
>the question of the nature of the congestion and what is the best way 
to
>deal that problem.  I was involved in a study done by Genuity and 
Cisco in
>which the congestion problem was found to most often involve the tail
>circuit--the link between the customer and the ISP.  The best solution 
for
>this problem was found to be low latency queuing, not RSVP.

Adding VOIP to an enterprise LAN can often add to congestion. Some on-path signaling 
can help here - not to mention NAT & FW traversal issues.  RSVP doesn't solve these, 
but NSIS is looking into these issues.

John


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

Re: YATS? Re: T-shirts, and some suggestions fo r future ietf meetings

[John Loughney]

If we scheduled the March meeting in New Orleans or Rio, maybe things would get 
interesting!

John

 Reply Header 
Subject:Re: YATS? Re: T-shirts,
and some suggestions for future ietf meetings
Author: "shogunx" <[EMAIL PROTECTED]>
Date:   09th August 2004 5:21:34  PM

On Tue, 10 Aug 2004, George Michaelson wrote:

Personally, I find the requirement of wearing clothes tiresome, but then
again, who REALLY wants to see all the IETF'ers naked?

Enjoy,
Scott


>
> Jon Crowcroft told us in UCL-CS back in '85 that the pre-IETF meetings were
> smoke filled rooms, including uniforms with medal-bars out to the elbows...
>
> -George
>
> ___
> Ietf mailing list
> [EMAIL PROTECTED]
> https://www1.ietf.org/mailman/listinfo/ietf
>

sleekfreak pirate broadcast
http://sleekfreak.ath.cx:81/


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


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

Re: Naming convention for a WG I-D that returns to

[John Loughney]

Title: Converted from Rich Text

 
 

> I don't know whether stopping "manyfolks" is right or not. 
A note about manyfolks, a few IETF's ago, there were 3 or 4 drafts submitted into the WG I chair that were on the same topic. I felt it would be best if the authors got together and submitted a common draft. To short-circuit any meaningless discussions on whose name should be on the draft name, the manyfolks name seemed reasonable. 
 John 

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

Re: T-shirts, and some suggestions for future ietf meetings

[John Loughney]

Title: Converted from Rich Text

 
 

> > By the way, the hotel has free IPv6 connectivity in every room, since we 
> > installed it in May 2003 (first one in the world as I know).> (snip)> > PS: And yes, we of course plan to provide a nice t-shirt !> > OK, I'm convinced. Lets go there as soon as possible. 
I'm convinced as well! 
 John 

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

Re: IESG review of RFC Editor documents

[John Loughney]

Title: Converted from Rich Text

 
 

Hi Eliot, 
 > Similarly, SOCKS went quite far before the IETF ever got a look at it. > Why?  Because we are no longer viewed as a place where development can > seriously take place.  Risk averse.  You know that thing about running > code?  Taken too far we fail what I think part of our mission is, which > is to be a place to collaborate, because everyone will have shown up > with their respective running code, only to fight over whose running > code (if anybody's) will become the standard.  See, for instance, the > XMPP/IMPP wars. 
I agree with you on this. I think we see already other groups working on IP protocols, avoiding the IETF. One could look at the example of RADIUS, for example. RADIUS was originally developed outside of the IETF, brought into the IETF, extended by a half-dozen SDOs and now the IETF is considering trying to clean up the current mess. The IETF has used individual submissions to make things a bit better, with some success.  
 Part of the problem was that the we  took so long to develop the follow-up to RADIUS - Diameter - that we completely missed the window, so the world kept extending RADIUS. 
 John 

 

Re: [isdf] Re: www.internetforce.org

[john . loughney]

Folks,

I wrote up a draft, 
http://www.ietf.org/internet-drafts/draft-loughney-what-standards-00.txt which 
discusses similar issues. I'd appreciate comments, as I intend on updating the 
document soon.

Thanks,
John
-- original message --
Subject:Re: [isdf] Re: www.internetforce.org
From:   "jfcm" <[EMAIL PROTECTED]>
Date:   8th January 2004 11:32:43 pm

At 21:45 08/01/04, John C Klensin wrote:
>A better answer would have been "the term 'request for comment' is 
>historical, dating from a time when the preferred way to make a formal 
>comment on a document involved writing another document, which then was 
>numbered into the series".  That mechanism is still available, although 
>usually very slow.  But documents that become RFCs are now first posted as 
>Internet Drafts (see http://www.ietf.org/ID); comments on those are both 
>solicited and, usually, handled very quickly.
>
>Today, the RFC Series, despite retention of the original name and 
>numbering series, acts as a permanent, archival, repository of 
>information, decisions taken, and standards published.  As such, documents 
>in the series are subjected to review and editing processes (which differ 
>somewhat depending on the type of document and are appropriate for 
>conventional references from conventional documents.  Running 
>conversations, logs of comments, etc., are not well suited for that 
>archival and reference role, regardless of their other advantages and 
>disadvantages.


Could it not be useful to have a "List of Comments" (LOC) for each RFC? 
Where experience about the RFC reading, testing and implementation could be 
listed by the authors (or a successor) from experience and questions 
received. It would avoid the same questions to be debated again and again 
and it would help further thinking. These comments could start with a 
summary of the WG debated issues, explaining the whys of some options. I 
suppose the implementation would be easy enough since it would follow the 
same numbering scheme and titles. Such a LOC being an updated appendix 
could be reviewed and help preparing replacements.
jfc