Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before

[Arnt Gulbrandsen]

Fred Baker writes:
I'm not sure I agree that Friday is a "problem"; the problem is that  
we have N working groups asking for M meetings and N*M needs to be <= 
 that fixed number. Friday is a solution, one that has certain  
downsides. Stanislaus doesn't like the solution and IMHO has not  
proposed a solution that tells us how to better manage the demands on 
 the resource.


The hotel has X meeting rooms, and X is known when the location is 
announced. If N*M/X<=4 and the increased density doesn't lead to more 
problems than Friday does, then Friday is unnecessary for that 
particular meeting.


Right now, the agenda is based on the chairs' perceptions of conflicts. 
It could be based on registrants' wishes, instead, which I think will 
permit a higher degree of parallelism without an increase in conflicts. 
That is, when you register, you click which WGs you really want to 
attend and which ones are also interesting, and the agenda is computed 
from that.


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

Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before

[Scott Brim]

Arnt Gulbrandsen allegedly wrote on 11/11/2009 6:08 PM:
> Fred Baker writes:
>> I'm not sure I agree that Friday is a "problem"; the problem is that 
>> we have N working groups asking for M meetings and N*M needs to be <=
>>  that fixed number. Friday is a solution, one that has certain 
>> downsides. Stanislaus doesn't like the solution and IMHO has not 
>> proposed a solution that tells us how to better manage the demands on
>>  the resource.
> 
> The hotel has X meeting rooms, and X is known when the location is
> announced. If N*M/X<=4 and the increased density doesn't lead to more
> problems than Friday does, then Friday is unnecessary for that
> particular meeting.

Even a full Friday isn't enough to remove the conflicts.  In fact I'm
triple-booked on Friday itself.  There is no chance the IETF will fit in
4 days.  That hasn't been possible for years.

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

Virtual Open Mike for NomCom :-)

[Spencer Dawkins]

Hi, Mary,

I was really surprised this year when NomCom announced local interview slots 
wherever the NomCom members were, thought to myself that I should arrange 
for one of the interviews, and then got busy, left the country, etc. ...


But I'd like to thank you guys for making this offer.

You mentioned in your report tonight that you hadn't had a lot of people 
request slots locally - I hope you can talk about this process a little in 
your final report in March, because I hope future NomComs might also make 
this offer as well, if it's the right thing to do.


Thanks,

Spencer 


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

Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before

[Arnt Gulbrandsen]

Scott Brim writes:

Even a full Friday isn't enough to remove the conflicts.  In fact I'm
triple-booked on Friday itself.  There is no chance the IETF will fit in
4 days.  That hasn't been possible for years.


Why do so many people in WG meetings read mail, look bored and hardly 
say a word, then?


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

Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before

[Brian E Carpenter]

I read mail and listen and look at the slides, when I'm
in a session that is secondary to my main interests.
That doesn't mean I'm bored (maybe I always look bored),
but I don't see that it affects the question whether we
can fit all the parallel sessions into 4.5 days.

Brian

On 2009-11-11 22:23, Arnt Gulbrandsen wrote:
> Scott Brim writes:
>> Even a full Friday isn't enough to remove the conflicts.  In fact I'm
>> triple-booked on Friday itself.  There is no chance the IETF will fit in
>> 4 days.  That hasn't been possible for years.
> 
> Why do so many people in WG meetings read mail, look bored and hardly
> say a word, then?
> 
> Arnt
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before

[Scott Brim]

Arnt Gulbrandsen allegedly wrote on 11/11/2009 6:23 PM:
> Scott Brim writes:
>> Even a full Friday isn't enough to remove the conflicts.  In fact I'm
>> triple-booked on Friday itself.  There is no chance the IETF will fit in
>> 4 days.  That hasn't been possible for years.
> 
> Why do so many people in WG meetings read mail, look bored and hardly
> say a word, then?

Because Stanislav is at the mike :-) ... Seriously, are you suggesting
that it might be possible to cluster WGs together so that people can
stay for parts of the week?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Updated logistics and agenda for Smart Grid Bar BOF at IETF 76

[Fred Baker]

There was an error in the reservation announcement. When I first set  
it up, I managed to hit the wrong date, and so I set up a correct one.  
The error was sent to the list earlier; it's still an error.


oops

Here is the correct data.

Begin forwarded message:


From: Frederick Baker 
Date: November 8, 2009 1:03:32 PM JST
To: f...@cisco.com
Subject: (Forward to attendees) Meeting invitation: Smart Grid IETF  
"Bar" BOF

Reply-To: f...@cisco.com

 You can forward this email invitation to attendees 

Hello ,

Frederick Baker invites you to attend this online meeting.

Topic: Smart Grid IETF "Bar" BOF
Date: Wednesday, November 11, 2009
Time: 8:00 pm, Japan Time (Tokyo, GMT+09:00)
Meeting Number: 201 328 939
Meeting Password: smartgrid


---
To join the online meeting (Now from iPhones too!)
---
1. Go to 
https://ciscosales.webex.com/ciscosales/j.php?ED=128776627&UID=0&PW=NZTViNTIwYzFh&RT=MiM0OQ%3D%3D
2. Enter your name and email address.
3. Enter the meeting password: smartgrid
4. Click "Join Now".

To view in other time zones or languages, please click the link:
https://ciscosales.webex.com/ciscosales/j.php?ED=128776627&UID=0&PW=NZTViNTIwYzFh&ORT=MiM0OQ%3D%3D


ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes


The affected toll free numbers are: (866) 432-9903 for the San Jose/ 
Milpitas area and (866) 349-3520 for the RTP area.


Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

---
To join the teleconference only
---
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or  
Access Code followed by the # sign.


San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350. Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

---
For assistance
---
1. Go to https://ciscosales.webex.com/ciscosales/mc
2. On the left navigation bar, click "Support".

You can contact me at:
f...@cisco.com
1-408-526 4257

To add this meeting to your calendar program (for example Microsoft  
Outlook), click this link:

https://ciscosales.webex.com/ciscosales/j.php?ED=128776627&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=OPRSuEQjxcIW1i8IRtMp/EUOrwEVTnOuxF2HObLGnx4=&RT=MiM0OQ%3D%3D

The playback of UCF (Universal Communications Format) rich media  
files requires appropriate players. To view this type of rich media  
files in the meeting, please check whether you have the players  
installed on your computer by going to https://ciscosales.webex.com/ciscosales/systemdiagnosis.php


Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com



IMPORTANT NOTICE: This WebEx service includes a feature that allows  
audio and any documents and other materials exchanged or viewed  
during the session to be recorded. By joining this session, you  
automatically consent to such recordings. If you do not consent to  
the recording, do not join the session.


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

Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before

[Arnt Gulbrandsen]

Scott Brim writes:
Seriously, are you suggesting that it might be possible to cluster WGs 
together so that people can stay for parts of the week?


I hadn't thought of that...

No, I was suggesting that if registrants explicitly say which WGs are 
really interesting ("conflicts in that set spoil my trip") and which 
are less interesting ("I'll attend those since I'm there anyway"), then 
it may be possible to use more meeting rooms for a shorter period, 
without spoiling people's trips.


It really depends on how many people would include forty WGs in the 
"really important for me" set.


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

Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before

[Marshall Eubanks]

On Nov 11, 2009, at 5:01 AM, Arnt Gulbrandsen wrote:


Scott Brim writes:
Seriously, are you suggesting that it might be possible to cluster  
WGs together so that people can stay for parts of the week?




Of course it might be possible - in fact, I would assert that it is  
highly likely to be possible.

Many organizations do this. With the RFID "blue sheet" data it would be
pretty straightforward to do a cluster analysis and see if (say) RAI and
Routing area attendees are disjoint enough that you could have
RAI at the beginning of the week, RA at the end, and spread the load  
out.


I would personally be surprised if a cluster analysis or principal  
component
analysis of the RFID data didn't reveal some means of separating the  
meeting sessions like this.


Whether this is a good idea is another matter.

Regards
Marshall



I hadn't thought of that...

No, I was suggesting that if registrants explicitly say which WGs  
are really interesting ("conflicts in that set spoil my trip") and  
which are less interesting ("I'll attend those since I'm there  
anyway"), then it may be possible to use more meeting rooms for a  
shorter period, without spoiling people's trips.


It really depends on how many people would include forty WGs in the  
"really important for me" set.


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



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

If you found today's plenary debate on standards track tedious...

[Brian E Carpenter]

Who would like to adopt this idea:

http://tools.ietf.org/id/draft-loughney-newtrk-one-size-fits-all-01.txt

Brian

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

IETF Plenary Discussions

[Danny McPherson]

Russ, Olaf, et al,
I was serious in my recommendation to experiment with limiting
question (comment) time at the microphone at plenaries.  I believe
it'll not only help mere mortals pay more attention, but will also
encourage those folks that have questions or comments to be more
concise, thereby keeping the audience better engaged.

I honestly mean no disrespect and appreciate the wealth of
institutional  knowledge that's on hand and frequently shared,
I just believe that it'd be more effective use of such precious
time (and encourage more discussions on this list :-).

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

Re: If you found today's plenary debate on standards track tedious...

[Dave CROCKER]

Brian E Carpenter wrote:

Who would like to adopt this idea:

http://tools.ietf.org/id/draft-loughney-newtrk-one-size-fits-all-01.txt



Typically, it's better to gain some agreement about tradeoffs among some 
choices, prior to starting lobbying for a particular choice.


This has the distinct advantage of allowing the community to know why it 
rejected alternatives.  And /that/ has the advantage of avoiding morning-after 
regret.


d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: If you found today's plenary debate on standards track tedious...

[Richard Barnes]

From the perspective of the world outside the IETF, this is already  
the case.  An RFC is an RFC is an RFC...

--Richard


On Nov 11, 2009, at 7:25 PM, Brian E Carpenter wrote:


Who would like to adopt this idea:

http://tools.ietf.org/id/draft-loughney-newtrk-one-size-fits- 
all-01.txt


   Brian

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


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

Re: IETF Plenary Discussions

[Stephan Wenger]

+1
Stephan


On 11/11/09 7:53 PM, "Danny McPherson"  wrote:

> Russ, Olaf, et al,
> I was serious in my recommendation to experiment with limiting
> question (comment) time at the microphone at plenaries.  I believe
> it'll not only help mere mortals pay more attention, but will also
> encourage those folks that have questions or comments to be more
> concise, thereby keeping the audience better engaged.
> 
> I honestly mean no disrespect and appreciate the wealth of
> institutional  knowledge that's on hand and frequently shared,
> I just believe that it'd be more effective use of such precious
> time (and encourage more discussions on this list :-).
> 
> -danny
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf


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

Re: If you found today's plenary debate on standards track tedious...

[Adrian Farrel]

Hi,

From the perspective of the world outside the IETF, this is already  the 
case.  An RFC is an RFC is an RFC...


I don't think this is a truth universally acknowledged.

I have heard the IETF disparaged a number of times on account of "hardly 
having any standards". For example, a full Standard is equated by some 
people with an ITU-T Recommendation with the implication that a DS and PS 
are significantly inferior to a Recommendation.


Whatever we might think of the value of this statement and the motives of 
the people who make it, it is clear that the names of the different levels 
of RFC are perceived outside the IETF.


Over dinner this evening we wondered whether something as simple as looking 
again at the names of the stages in the three phase RFC process might serve 
to address both the perceptions and the motivations for progression.


Cheers,
Adrian 


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

Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before

[Andrew Sullivan]

On Wed, Nov 11, 2009 at 05:08:44AM -0500, Marshall Eubanks wrote:
> I would personally be surprised if a cluster analysis or principal  
> component
> analysis of the RFID data didn't reveal some means of separating the  
> meeting sessions like this.
>
> Whether this is a good idea is another matter.

Indeed, I thought the primary argument for the Big Giant Meeting was
supposed to be that cross-pollination of areas and WGs was beneficial.
If we then try to schedule things so that people can conveniently come
for just a few days (and, presumably, use the day passes that have
just been invented), then that purported benefit goes away.  In that
case, I predict we'd quickly move to WG- or area-specific meetings
with no or fewer Big Giant Meetings.  (I am agnostic on whether that's
a good idea, but it might be.)

A

-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: If you found today's plenary debate on standards track tedious...

[Eliot Lear]

Not THIS again.  Let's look at a few of the standards that are commonly 
used today:


HTTP: DS
SNTP: PS
SIP: PS
IPv6 Addressing Architecture: DS
SMTP: DS & Full standard
MPLS-VPNs: PS
BGPv4: DS
MIME: DS
XMPP: PS (although it seems the real work goes on elsewhere)
OSPF: Full standard
RIPv2: full standard
BFD: not to be found
VRRP: DS
Radius: DS
DNS base: full standard
DNS components: varying
SNMPv3: full (but long before anyone actually used it)

And so you will forgive people who seem confused by our quaint notion 
that there are flavors of standards.  We don't do a good job of 
describing maturity with our standards levels.  Perhaps we do a good job 
of using the standards levels to make a recommendation.  How much SNMPv1 
and v2 is out there still?  Apparently not many people are listening to 
that recommendation.


Does standard matter at all any more?  I think so.  A good number of the 
base protocols that are run on the computer I type this from are 
actually IETF standards.  Yeah (except for software and device 
management.  We blew, and continue to blow that one).


So let's get real.  John's draft was the right thing to do for NEWTRK.  
But do we really have the stomach for it?  Last time out we did not.


Eliot
ps: see you all in Orange County, where I'm sure this endless debate 
will continue.


On 11/11/09 5:04 PM, Adrian Farrel wrote:

Hi,

From the perspective of the world outside the IETF, this is already  
the case.  An RFC is an RFC is an RFC...


I don't think this is a truth universally acknowledged.

I have heard the IETF disparaged a number of times on account of 
"hardly having any standards". For example, a full Standard is equated 
by some people with an ITU-T Recommendation with the implication that 
a DS and PS are significantly inferior to a Recommendation.


Whatever we might think of the value of this statement and the motives 
of the people who make it, it is clear that the names of the different 
levels of RFC are perceived outside the IETF.


Over dinner this evening we wondered whether something as simple as 
looking again at the names of the stages in the three phase RFC 
process might serve to address both the perceptions and the 
motivations for progression.


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



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

Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before

[Michael Richardson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


> "Dave" == Dave CROCKER  writes:
>> I'm not sure I agree that Friday is a "problem"; the problem is
>> that we have N working groups asking for M meetings and N*M needs
>> to be <= that fixed number. Friday is a solution, one that has
>> certain downsides. Stanislaus doesn't like the solution and IMHO
>> has not proposed a solution that tells us how to better manage
>> the demands on the resource.


Dave> Establish authorization criteria for meeting slots that are
Dave> based on demonstrated progress and meeting milestones, along
Dave> with an agenda that is designed to achieve more progress.

Dave> Enforce the criteria rigorously.

Dave> We will then need far fewer meeting slots.

+1
What he said.

- -- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBSvr0G4CLcPvd0N1lAQLacgf/YJuqXWMsOoBP0bLvmm/zOnaMl1umb1Mq
VP3+arM/te9fgQqn+u4NUkOnfKusV+RCcb5AoBFgZ5QoIySZ/lQEmlgWw2XwkUeu
uiOGvWlf5KojJ3IHZyX3ifJVLk2UmOsZKLRBlfFY+vzOpCnXdWrElJqJA2UAFteO
MafOE+M7Y0Tvz5KWekten/hn7AsxdJ2rbFM/rcbFfYv+IEahg2dRBV0Rc+3b05eb
3OHosGsMJm+HnmtepJaP63B0MhlollRJdU70uX1t88A4nm5ThM/t9DmJdLxXCglQ
UnedSJdZn3/3cZm4pILE7ZajNr990LEbPmjPQNmJ9ru9GVJ0YKjQdA==
=bv+T
-END PGP SIGNATURE-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before

[Pekka Savola]

On Tue, 10 Nov 2009, Stanislav Shalunov wrote:

"But nobody will come to the technical plenary Friday afternoon!" --
1. We did come to the technical plenary when it was the last thing on 
Thursday, and it was in the evening.
2. If people won't come to the technical plenary, they won't come to WG 
meetings.  If it's an unsuitable meeting time, we should not put WGs there.


I tend to sympathize with this argument.  I suppose WG meetings are, 
from some POV, more important than a plenary.  So what if out of 1100 
participants we get only 600 at the plenary?  Maybe if the attendance 
drops low enough we could drop the whole plenary.


Even better would be putting the administrative plenary there ;-)

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: If you found today's plenary debate on standards track tedious...

[John]

+1

you shouldn' need to be an IETF insider to actually understand IETF standards.

John

Sent from my Nokia N900.

- Original message -
> Not THIS again.  Let's look at a few of the standards that are commonly
> used today:
>
> HTTP: DS
> SNTP: PS
> SIP: PS
> IPv6 Addressing Architecture: DS
> SMTP: DS & Full standard
> MPLS-VPNs: PS
> BGPv4: DS
> MIME: DS
> XMPP: PS (although it seems the real work goes on elsewhere)
> OSPF: Full standard
> RIPv2: full standard
> BFD: not to be found
> VRRP: DS
> Radius: DS
> DNS base: full standard
> DNS components: varying
> SNMPv3: full (but long before anyone actually used it)
>
> And so you will forgive people who seem confused by our quaint notion
> that there are flavors of standards.  We don't do a good job of
> describing maturity with our standards levels.  Perhaps we do a good job
> of using the standards levels to make a recommendation.  How much SNMPv1
> and v2 is out there still?  Apparently not many people are listening to
> that recommendation.
>
> Does standard matter at all any more?  I think so.  A good number of the
> base protocols that are run on the computer I type this from are
> actually IETF standards.  Yeah (except for software and device
> management.  We blew, and continue to blow that one).
>
> So let's get real.  John's draft was the right thing to do for NEWTRK. 
> But do we really have the stomach for it?  Last time out we did not.
>
> Eliot
> ps: see you all in Orange County, where I'm sure this endless debate
> will continue.
>
> On 11/11/09 5:04 PM, Adrian Farrel wrote:
> > Hi,
> >
> > > From the perspective of the world outside the IETF, this is already 
> > > the case.  An RFC is an RFC is an RFC...
> >
> > I don't think this is a truth universally acknowledged.
> >
> > I have heard the IETF disparaged a number of times on account of
> > "hardly having any standards". For example, a full Standard is equated
> > by some people with an ITU-T Recommendation with the implication that
> > a DS and PS are significantly inferior to a Recommendation.
> >
> > Whatever we might think of the value of this statement and the motives
> > of the people who make it, it is clear that the names of the different
> > levels of RFC are perceived outside the IETF.
> >
> > Over dinner this evening we wondered whether something as simple as
> > looking again at the names of the stages in the three phase RFC
> > process might serve to address both the perceptions and the
> > motivations for progression.
> >
> > Cheers,
> > Adrian
> > ___
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf
> >
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

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

Re: If you found today's plenary debate on standards track tedious...

[Spencer Dawkins]

As I begged at the mike last night, let's make sure that this problem 
actually causes pain before spending one more second discussing it.


Just for completeness :-|

There is also the question of standards where we DO NOT WANT people to 
implement the full standard and say they are through - without PS updates, 
disaster happens.


You don't need to look further than TCP. The full standard (STD007) is only 
RFC 793, with no slow start, no congestion avoidance ... that stuff is all 
in PSes. And we can't even add them to STD007, because they aren't full 
standards.


Does this matter? A company that I worked at several years ago thought they 
were supposed to implement the full standards for TCP and waiting for the 
other "in-process" standards to become full standards - that wouldn't work, 
but we were doing passive network monitoring and not transmitting any 
packets, so it would have been Mostly Harmless.


John told me he had the same experience at HIS company (before he explained 
that our standards levels are usually meaningless), and they DID transmit 
packets - they've probably made hundreds of millions of UAs (guess which 
technology this is), and they would probably have made a pretty serious dent 
in the Internet if they made another few hundred million UAs that provided 
HTTP (for example) and implemented TCP without congestion avoidance or slow 
start.


On the other hand, we didn't add congestion avoidance or slow start to TCP 
until the net actually collapsed LAST time, so maybe that's what it would 
take for us to decide that fixing the standards track is worth doing. But we 
need to decide how much pain the standards track as defined today causes 
first, or we'll go through another round of endless discussions and still 
have STD007.


IMO.

Spencer

Not THIS again.  Let's look at a few of the standards that are commonly 
used today:


HTTP: DS
SNTP: PS
SIP: PS
IPv6 Addressing Architecture: DS
SMTP: DS & Full standard
MPLS-VPNs: PS
BGPv4: DS
MIME: DS
XMPP: PS (although it seems the real work goes on elsewhere)
OSPF: Full standard
RIPv2: full standard
BFD: not to be found
VRRP: DS
Radius: DS
DNS base: full standard
DNS components: varying
SNMPv3: full (but long before anyone actually used it)

And so you will forgive people who seem confused by our quaint notion that 
there are flavors of standards.  We don't do a good job of describing 
maturity with our standards levels.  Perhaps we do a good job of using the 
standards levels to make a recommendation.  How much SNMPv1 and v2 is out 
there still?  Apparently not many people are listening to that 
recommendation.


Does standard matter at all any more?  I think so.  A good number of the 
base protocols that are run on the computer I type this from are actually 
IETF standards.  Yeah (except for software and device management.  We 
blew, and continue to blow that one).


So let's get real.  John's draft was the right thing to do for NEWTRK. 
But do we really have the stomach for it?  Last time out we did not.


Eliot
ps: see you all in Orange County, where I'm sure this endless debate will 
continue.


On 11/11/09 5:04 PM, Adrian Farrel wrote:

Hi,

From the perspective of the world outside the IETF, this is already  the 
case.  An RFC is an RFC is an RFC...


I don't think this is a truth universally acknowledged.

I have heard the IETF disparaged a number of times on account of "hardly 
having any standards". For example, a full Standard is equated by some 
people with an ITU-T Recommendation with the implication that a DS and PS 
are significantly inferior to a Recommendation.


Whatever we might think of the value of this statement and the motives of 
the people who make it, it is clear that the names of the different 
levels of RFC are perceived outside the IETF.


Over dinner this evening we wondered whether something as simple as 
looking again at the names of the stages in the three phase RFC process 
might serve to address both the perceptions and the motivations for 
progression. 


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

Re: IETF Plenary Discussions

[Russ Housley]

I did not take the comment as disrespectful.  A timer might be a very 
good experiment.


Russ


At 05:53 AM 11/11/2009, Danny McPherson wrote:

Russ, Olaf, et al,
I was serious in my recommendation to experiment with limiting
question (comment) time at the microphone at plenaries.  I believe
it'll not only help mere mortals pay more attention, but will also
encourage those folks that have questions or comments to be more
concise, thereby keeping the audience better engaged.

I honestly mean no disrespect and appreciate the wealth of
institutional  knowledge that's on hand and frequently shared,
I just believe that it'd be more effective use of such precious
time (and encourage more discussions on this list :-).

-danny


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

Re: IETF Plenary Discussions

[Jari Arkko]

Individuals taking a long time to talk either on the mike or responding 
on the stage :-) is one problem.


At times I wonder if a bigger issue is how long certain topics are 
discussed. I'm sorry but I just can't get excited about labeling of 
standards track RFCs, or even about how to get early review from the 
IESG on documents that advance. The issues are the same as they are for 
all other documents. If we want early review, get the document to the 
IESG and have us provide feedback in some documented manner.


I'm curious why we end up discussing this stuff in the administrative 
plenaries. I do not believe we have run out of other things to discuss. 
For instance, we could have talked about the direction of the v6 
transition work in the face of an ever growing set of proposals only 
slightly different from each other. Or how the IESG handled some BOFs, 
or the controversies that we have in a number of working groups. Or how 
the IETF should organize work around some emerging new topics.


Did we NOT discuss these topics because we had nothing to say, or 
because we had been exhausted by the standards ladder discussion?


Jari

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

Gen-ART LC review of draft-dusseault-http-patch-15.txt

[Brian E Carpenter]

I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-dusseault-http-patch-15.txt
Reviewer: Brian Carpenter
Review Date: 2009-11-12
IETF LC End Date: 2009-11-24
IESG Telechat date: 

Summary: Issue with transactional integrity


Comment:   


I have not had time to follow all the Last Call comments on the IETF list.
Apologies for any overlap.

Major issues:
-

As far as I can tell, the proposal places the burden for ensuring
atomicity entirely on the server. However, PATCH is explicitly not 
idempotent. If a client issues a PATCH, and the server executes the PATCH,
but the client then fails to receive an indication of success due to
an extraneous network glitch (and TCP reset?), then what prevents the client
issuing the same PATCH again? In other words, absent a two-phase commit,
there appears to be no transactional integrity.

If I have understood this correctly, PATCH is not only not safe in
the RFC2616 sense, it is not transactionally safe either, so the state
of the resource after {PATCH, lost response code, PATCH} is undefined.

I don't believe that the non-normative words starting "Clients wishing to 
apply a patch document to a known entity..." are anything like enough to 
fix this problem. I don't know enough to know whether some normative text
using ETag is sufficient (it's clear from the draft that If-Unmodified-Since
is insufficient). This doesn't seem easy to fix without adding a 
"ready to commit"/"commit" exchange, which also needs transaction IDs 
(perhaps based on strong ETags) and a new state machine at each end.

I'd be glad to learn that I'm missing something.___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: If you found today's plenary debate on standards track tedious...

[Loa Andersson]

Adrian,

I think both statements are true.

I've seen operators putting almost any RFC in RFPs, (actually done
it myself) STD, DS, PS, Informational, Experimental, Historic and
April 1st. An RFC is an RFC is an RFC!

On the other hand talking to folks active in other SDOs you very
often hear the "no standards" argument.

Renaming without changing definitions should part of the job.

/Loa



Adrian Farrel wrote:

Hi,

From the perspective of the world outside the IETF, this is already  
the case.  An RFC is an RFC is an RFC...


I don't think this is a truth universally acknowledged.

I have heard the IETF disparaged a number of times on account of "hardly 
having any standards". For example, a full Standard is equated by some 
people with an ITU-T Recommendation with the implication that a DS and 
PS are significantly inferior to a Recommendation.


Whatever we might think of the value of this statement and the motives 
of the people who make it, it is clear that the names of the different 
levels of RFC are perceived outside the IETF.


Over dinner this evening we wondered whether something as simple as 
looking again at the names of the stages in the three phase RFC process 
might serve to address both the perceptions and the motivations for 
progression.


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


--


Loa Andersson email: loa.anders...@ericsson.com
Sr Strategy and Standards Managerl...@pi.nu
Ericsson Inc  phone: +46 10 717 52 13
 +46 767 72 92 13
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Plenary Discussions

[Tony Hansen]

Didn't Harald put up a timer sometimes during open mike?

Tony Hansen

Russ Housley wrote:
I did not take the comment as disrespectful.  A timer might be a very 
good experiment.


Russ


At 05:53 AM 11/11/2009, Danny McPherson wrote:

Russ, Olaf, et al,
I was serious in my recommendation to experiment with limiting
question (comment) time at the microphone at plenaries.  I believe
it'll not only help mere mortals pay more attention, but will also
encourage those folks that have questions or comments to be more
concise, thereby keeping the audience better engaged.

I honestly mean no disrespect and appreciate the wealth of
institutional  knowledge that's on hand and frequently shared,
I just believe that it'd be more effective use of such precious
time (and encourage more discussions on this list :-).

-danny


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

Re: IETF Plenary Discussions

[Spencer Dawkins]

i am remembering that this is correct. i have a faint memory that the timer 
might have been per topic (so you cut off the followups and moved to the 
next question), at least once or twice.


i have a faint memory of a lot of things. harald? :-)

spencer

- Original Message - 
From: "Tony Hansen" 

To: "IETF Discussion" 
Sent: Thursday, November 12, 2009 11:11 AM
Subject: Re: IETF Plenary Discussions



Didn't Harald put up a timer sometimes during open mike?

Tony Hansen

Russ Housley wrote:
I did not take the comment as disrespectful.  A timer might be a very 
good experiment.


Russ


At 05:53 AM 11/11/2009, Danny McPherson wrote:

Russ, Olaf, et al,
I was serious in my recommendation to experiment with limiting
question (comment) time at the microphone at plenaries.  I believe
it'll not only help mere mortals pay more attention, but will also
encourage those folks that have questions or comments to be more
concise, thereby keeping the audience better engaged.

I honestly mean no disrespect and appreciate the wealth of
institutional  knowledge that's on hand and frequently shared,
I just believe that it'd be more effective use of such precious
time (and encourage more discussions on this list :-).

-danny


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


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

NroffEdit updated with new boilerplate

[Stefan Santesson]

Short informational notice.

A new update of NroffEdit is available (
http://aaa-sec.com/nroffedit/index.html ), supporting the boilerplate from
the new Trust Legal Provisions from September 2009.

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

Re: IETF Plenary Discussions

[Scott Brim]

Tony Hansen allegedly wrote on 11/12/2009 11:11 AM:
> Didn't Harald put up a timer sometimes during open mike?

See attached ...

Title: Discussion Timer

















TimeRemaining 
0:00






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

publishing some standards immediately at Draft-Standard status?

[Tony Hansen]

One idea discussed over various beverages last night was based on an 
observation about the high bar that most Proposed Standards have had to 
pass over in order to become RFCs: many of them would not have gotten to 
publication without having already gone through interoperability testing.


So the idea is that the shepherding files for such I-Ds could include 
interoperability reports indicating that they *are* already 
interoperable and have successful operational experience, and then be 
published directly at Draft Standard status.


Tony Hansen
t...@att.com

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

Re: Fix the Friday attendance bug: make the technicalplenary the last IETF session, like it was before

[George Michaelson]

I wish to add a specific point to this.

I also raised a proposal for over-weekend meetings a few years back. I feel 
that the attendees to US IETF, which have often predominated, but in the 
general sense the attendees to IETF who fly for more than 12h to get there, 
suffer a material disadvantage from the monday-friday timing.

We loose two weekends, every IETF.

the proposal to shift to mid-week start-end has the material advantage to these 
people that they now loose only one weekend, as does everyone else.

Therefore, from a Benthamite 'maximal good to maximal people' sense, this is a 
better model.

I recognize that very strongly held views, including faith-related issues, lie 
here. I do not wish to disrespect these beliefs.

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

Re: NAT Not Needed To Make Renumbering Easy

[Phillip Hallam-Baker]

Forgive me if I do not see botching the IPSEC spec so that it fails
through NAT as an argument against NAT.

Why don't we repair the damage instead? If we are serious about the
IPv6 transition then we should be insisting that IPSEC work
transparently over NAT46 and NAT64.


Its easy enough to solve the NAT issue in IPSEC.

Just extend the key agreement so that the endpoints inform each other
of the IP address that they believe to be in use and store that with
the key data required to check the MAC. Then consider fixing up the IP
address to be part of the verification function.

Problem solved - unless some patent troll has claimed this rather obvious fix.


The IETF can choose not to add it to the standard, and thus choose to
ensure that IPSEC connectivity remains fragile. But that is a really
lousy way to respect your customers.

Authenticating the IP address is totally unnecessary from a security
point of view, the data can only be checked at the security
association endpoint. So if the packet has got there the address can't
have been too far wrong. Further the binding of the key to the
security association is going to be keyed of the IP source and
destination addresses so it is rather hard to see how an attacker can
gain from manipulating the IP addresses.


Probably simpler to just declare some dummy algorithm identifiers for
HMAC-SHA256 ignoring the IP addresses.

And you can probably use the exact same hack to make the connection
NAT46/64 agnostic, though to be honest I have not thought the issue
through.

OK back to polishing the moulds for my robot.

On Mon, Nov 9, 2009 at 10:11 PM, Sabahattin Gucukoglu
 wrote:
> On 8 Nov 2009, at 16:22, Phillip Hallam-Baker wrote:
>>
>> There are two typical modes of deployment for IPSEC, the first is as a
>> lousy remote access protocol where the lack of NAT support makes it
>> far more effort than other solutions. SSL and SSH remote access just
>> works, IPSEC VPN may or may not work depending on the phase of the
>> moon. The third party clients are terrible, the built in support in
>> the O/S is unusable because it does not have the tweaks necessary to
>> get through the firewall. So we do not really have a standard for
>> IPSEC remote access.
>
> There's at least one product making actual money in this space, Hamachi (
> http://www.hamachi.cc/ ).  Basically third-party-mediated IPSec-lite that
> goes over NAT.  If you must use NAT, at least be aware of what can come back
> to your network due to NAT behaviour and internally initiated connections.
>  I don't think NAT is providing the right kind of security here.  But I must
> be careful not to start another flame war.
>
> But anyway, IPv6/Teredo does the same thing, and better; Microsoft is
> working on going that extra mile with IP over HTTPS, too, so soon we'll have
> peer-to-peer VPNs that really do "Just work".  In every case it is better
> than Hamachi's use of unassigned address space, and in no case better than
> fixing the trouble at the root, and shredding NAT.
>
> But, if NAT's your thing ...
>
> Cheers,
> Sabahattin
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: If you found today's plenary debate on standards track tedious...

[Phillip Hallam-Baker]

The same is true of SMTP. RFC822 is the 'standard',

We have a broken model. There are not enough hours in the day for the
IESG to spend time deciding whether HTTP has reached a sufficient
maturity level to be considered a full 'standard'. That may or may not
be a problem. But the RFC 2822/822 issue is much worse, we are telling
people to respect the wrong standards.


Now my recollection of last go around is not that 'we' didn't have the
stomach for it. On the contrary. What happened was that the debate
went off into a closed room for the decision to be made and the peons
were told that there would be neither change nor an explanation but
they were to continue to congratulate themselves for being part of an
organization with such a sterling tradition of transparency, openness
and consensus based decision making.




On Wed, Nov 11, 2009 at 4:57 PM, Spencer Dawkins
 wrote:
> As I begged at the mike last night, let's make sure that this problem
> actually causes pain before spending one more second discussing it.
>
> Just for completeness :-|
>
> There is also the question of standards where we DO NOT WANT people to
> implement the full standard and say they are through - without PS updates,
> disaster happens.
>
> You don't need to look further than TCP. The full standard (STD007) is only
> RFC 793, with no slow start, no congestion avoidance ... that stuff is all
> in PSes. And we can't even add them to STD007, because they aren't full
> standards.
>
> Does this matter? A company that I worked at several years ago thought they
> were supposed to implement the full standards for TCP and waiting for the
> other "in-process" standards to become full standards - that wouldn't work,
> but we were doing passive network monitoring and not transmitting any
> packets, so it would have been Mostly Harmless.
>
> John told me he had the same experience at HIS company (before he explained
> that our standards levels are usually meaningless), and they DID transmit
> packets - they've probably made hundreds of millions of UAs (guess which
> technology this is), and they would probably have made a pretty serious dent
> in the Internet if they made another few hundred million UAs that provided
> HTTP (for example) and implemented TCP without congestion avoidance or slow
> start.
>
> On the other hand, we didn't add congestion avoidance or slow start to TCP
> until the net actually collapsed LAST time, so maybe that's what it would
> take for us to decide that fixing the standards track is worth doing. But we
> need to decide how much pain the standards track as defined today causes
> first, or we'll go through another round of endless discussions and still
> have STD007.
>
> IMO.
>
> Spencer
>
>> Not THIS again.  Let's look at a few of the standards that are commonly
>> used today:
>>
>> HTTP: DS
>> SNTP: PS
>> SIP: PS
>> IPv6 Addressing Architecture: DS
>> SMTP: DS & Full standard
>> MPLS-VPNs: PS
>> BGPv4: DS
>> MIME: DS
>> XMPP: PS (although it seems the real work goes on elsewhere)
>> OSPF: Full standard
>> RIPv2: full standard
>> BFD: not to be found
>> VRRP: DS
>> Radius: DS
>> DNS base: full standard
>> DNS components: varying
>> SNMPv3: full (but long before anyone actually used it)
>>
>> And so you will forgive people who seem confused by our quaint notion that
>> there are flavors of standards.  We don't do a good job of describing
>> maturity with our standards levels.  Perhaps we do a good job of using the
>> standards levels to make a recommendation.  How much SNMPv1 and v2 is out
>> there still?  Apparently not many people are listening to that
>> recommendation.
>>
>> Does standard matter at all any more?  I think so.  A good number of the
>> base protocols that are run on the computer I type this from are actually
>> IETF standards.  Yeah (except for software and device management.  We blew,
>> and continue to blow that one).
>>
>> So let's get real.  John's draft was the right thing to do for NEWTRK. But
>> do we really have the stomach for it?  Last time out we did not.
>>
>> Eliot
>> ps: see you all in Orange County, where I'm sure this endless debate will
>> continue.
>>
>> On 11/11/09 5:04 PM, Adrian Farrel wrote:
>>>
>>> Hi,
>>>
 From the perspective of the world outside the IETF, this is already  the
 case.  An RFC is an RFC is an RFC...
>>>
>>> I don't think this is a truth universally acknowledged.
>>>
>>> I have heard the IETF disparaged a number of times on account of "hardly
>>> having any standards". For example, a full Standard is equated by some
>>> people with an ITU-T Recommendation with the implication that a DS and PS
>>> are significantly inferior to a Recommendation.
>>>
>>> Whatever we might think of the value of this statement and the motives of
>>> the people who make it, it is clear that the names of the different levels
>>> of RFC are perceived outside the IETF.
>>>
>>> Over dinner this evening we wondered whether something as simple as
>>> looking again at the names of th

Re: OK, final NAT66 argument (Was: NAT Not Needed To Make Renumbering Easy

[Phillip Hallam-Baker]

IPv6 is just fine. The problem is not the technology we would
transition to, it is the lack of transition strategy and refusal to
think about deployment strategy in some quarters.

While they were building the big dig in Boston they actually built an
entire interchange from scratch and then demolished it. The temporary
interchange was necessary because you can't stop traffic in Boston for
ten years while you build the permanent one. We need the same for
IPv6.

The problem with IPv4 address space exhaustion is that it is much less
of a problem for end users than some imagine. If you have an IPV4
address and someone else does not, that is their problem, not
something you want to spend money for.


On Mon, Nov 9, 2009 at 4:38 AM, Masataka Ohta
 wrote:
> Phillip Hallam-Baker wrote:
>
>> I assert that regardless of whether NAT66 is a good or a bad thing,
>> anything that layers on IPv6 must be NAT66 tolerant.
>
> Because IPv6 is a bad thing, there should be nothing on IPv6.
>
>> Observation: Without NAT44 the internet would already have run out of
>> address space.
>
> Observation: With NAT44 and unicast class E (and part of D) the
> IPv4 Internet would not run out of address space for the time
> being.
>
>> I think that it is
>> now very clear that the IPv6 transition will take at least another
>> decade
>
> Considering that development of IPv6 did not take so many years,
> it is better to have another IPng which is more easily deployable
> than IPv6.
>
>> If we accept these two observations we arrive at a proof that NAT66 is
>> unavoidable.
>
> Only if IPv6 were worth deploying.
>
>                                                        Masataka Ohta
>
>



-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: If you found today's plenary debate on standards track tedious...

[Phillip Hallam-Baker]

It is really hard to keep management backing for a standards process
that does not deliver standards.

I know that there are some people in the IETF who would very much like
to see the commercial entities banished. And to some extent that has
happened, there is a reason that IBM and Microsoft put more resources
into OASIS and W3C and I do not think it is because they have more
influence there.

We are also seeing fewer academics.


I don't think that you want participation in IETF activities to be
limited to the few people fortunate enough to have managers who
understand the nature of the organization and a few individuals of
private means.


On Wed, Nov 11, 2009 at 8:30 PM, Loa Andersson  wrote:
> Adrian,
>
> I think both statements are true.
>
> I've seen operators putting almost any RFC in RFPs, (actually done
> it myself) STD, DS, PS, Informational, Experimental, Historic and
> April 1st. An RFC is an RFC is an RFC!
>
> On the other hand talking to folks active in other SDOs you very
> often hear the "no standards" argument.
>
> Renaming without changing definitions should part of the job.
>
> /Loa
>
>
>
> Adrian Farrel wrote:
>>
>> Hi,
>>
>>> From the perspective of the world outside the IETF, this is already  the
>>> case.  An RFC is an RFC is an RFC...
>>
>> I don't think this is a truth universally acknowledged.
>>
>> I have heard the IETF disparaged a number of times on account of "hardly
>> having any standards". For example, a full Standard is equated by some
>> people with an ITU-T Recommendation with the implication that a DS and PS
>> are significantly inferior to a Recommendation.
>>
>> Whatever we might think of the value of this statement and the motives of
>> the people who make it, it is clear that the names of the different levels
>> of RFC are perceived outside the IETF.
>>
>> Over dinner this evening we wondered whether something as simple as
>> looking again at the names of the stages in the three phase RFC process
>> might serve to address both the perceptions and the motivations for
>> progression.
>>
>> Cheers,
>> Adrian
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>
> --
>
>
> Loa Andersson                         email: loa.anders...@ericsson.com
> Sr Strategy and Standards Manager            ...@pi.nu
> Ericsson Inc                          phone: +46 10 717 52 13
>                                             +46 767 72 92 13
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: If you found today's plenary debate on standards track tedious...

[Tony Hansen]

Yup, and most of those proposed standards and draft standards should 
have been declared full standards *long* ago.


What we *don't* do well is revising the levels of standards that got 
published, became fully interoperable and deployed without needing a rev 
of the document. Why is their status still marked 'proposed' or 'draft'? 
RFC 2026 does NOT require a rev to the document to move forward if there 
are no errata.


For those specs that everyone has implemented and deployed, but there 
are a number of errata that "everyone agrees" are required for the spec 
to be useful, here's an idea for a "revision lite" (the diet version of 
a revision): recycle the spec almost totally *as-is*, with a section 
added called "Verified Errata". Copy in such errata, attach the 
interoperability and deployment reports, and publish.


Tony Hansen
t...@att.com

Eliot Lear wrote:
Not THIS again.  Let's look at a few of the standards that are commonly 
used today:


HTTP: DS
SNTP: PS
SIP: PS
IPv6 Addressing Architecture: DS
SMTP: DS & Full standard
MPLS-VPNs: PS
BGPv4: DS
MIME: DS
XMPP: PS (although it seems the real work goes on elsewhere)
OSPF: Full standard
RIPv2: full standard
BFD: not to be found
VRRP: DS
Radius: DS
DNS base: full standard
DNS components: varying
SNMPv3: full (but long before anyone actually used it)

And so you will forgive people who seem confused by our quaint notion 
that there are flavors of standards.  We don't do a good job of 
describing maturity with our standards levels.  Perhaps we do a good job 
of using the standards levels to make a recommendation.  How much SNMPv1 
and v2 is out there still?  Apparently not many people are listening to 
that recommendation.


Does standard matter at all any more?  I think so.  A good number of the 
base protocols that are run on the computer I type this from are 
actually IETF standards.  Yeah (except for software and device 
management.  We blew, and continue to blow that one).


So let's get real.  John's draft was the right thing to do for NEWTRK.  
But do we really have the stomach for it?  Last time out we did not.


Eliot
ps: see you all in Orange County, where I'm sure this endless debate 
will continue.


On 11/11/09 5:04 PM, Adrian Farrel wrote:

Hi,

From the perspective of the world outside the IETF, this is already  
the case.  An RFC is an RFC is an RFC...


I don't think this is a truth universally acknowledged.

I have heard the IETF disparaged a number of times on account of 
"hardly having any standards". For example, a full Standard is equated 
by some people with an ITU-T Recommendation with the implication that 
a DS and PS are significantly inferior to a Recommendation.


Whatever we might think of the value of this statement and the motives 
of the people who make it, it is clear that the names of the different 
levels of RFC are perceived outside the IETF.


Over dinner this evening we wondered whether something as simple as 
looking again at the names of the stages in the three phase RFC 
process might serve to address both the perceptions and the 
motivations for progression.


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



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

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

Re: publishing some standards immediately at Draft-Standard status?

[Tony Hansen]

Raise the bar more? Not at all -- that's not what I said. I said that 
the bar has *already been raised* so high that many of our I-Ds have 
already become fully interoperable before they get an RFC number assigned.


What I said, is that if you *have* interoperability and deployment when 
you get the RFC number assigned, go ahead and get published at DS or FS 
status.


Unless there are errata, changing the status from PS to DS to FS should 
be an administrative task, not a wait-for-full-revision-taking-X-years 
chore.


And yes, the above statements are *fully* in line with "use the current 
process better."


Tony Hansen
t...@att.com

Carsten Bormann wrote:

On Nov 12, 2009, at 12:28, Tony Hansen wrote:


published directly at Draft Standard status


Raise the bar so they stay at I-D level for even longer?  A sizable part 
of the Internet is run on I-Ds, not on PS.


I think the right direction is to publish PS earlier.  If done right, 
it's only six months from there to the DS, you know.  (About half of 
that time the draft is stuck in the RFC finalization process anyway :-).


(My suggestion would be to stop talking about changing the rules and 
instead just find ways to use the current process better.)


Gruesse, Carsten

PS.: And you could spend some time during I-D time already to upgrade 
your downrefs to DS :-)



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

Re: publishing some standards immediately at Draft-Standard status?

[James M. Polk]

At 09:44 PM 11/11/2009, Carsten Bormann wrote:

On Nov 12, 2009, at 12:28, Tony Hansen wrote:


published directly at Draft Standard status


Raise the bar so they stay at I-D level for even longer?  A sizable
part of the Internet is run on I-Ds, not on PS.

I think the right direction is to publish PS earlier.  If done right,
it's only six months from there to the DS, you know.


err... I thought this was minimum of 18 months?

James


 (About half of
that time the draft is stuck in the RFC finalization process anyway :-).

(My suggestion would be to stop talking about changing the rules and
instead just find ways to use the current process better.)


+1

James



Gruesse, Carsten

PS.: And you could spend some time during I-D time already to upgrade
your downrefs to DS :-)

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


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

Re: publishing some standards immediately at Draft-Standard status?

[Tony Hansen]

RFC 2026 section 6.2:
6 months from PS => DS
4 months and 1 meeting for DS => FS.

As John notes though, the clock currently begins after RFC publication 
time. There's no allowance granted for time already spent in jail.


Tony Hansen
t...@att.com

James M. Polk wrote:

At 09:44 PM 11/11/2009, Carsten Bormann wrote:

I think the right direction is to publish PS earlier.  If done right,
it's only six months from there to the DS, you know.


err... I thought this was minimum of 18 months?


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

Updated logistics and agenda for Smart Grid Bar BOF at IETF 76

[Polk, William T.]

[As before, my apologies for the shotgun nature of this email.]

Folks,

I would like to provide an update to the logistics and agenda for tonight's 
Smart Grid Bar BOF.  

The Bar BOF will begin at 8:30 so that folks attending the plenary have a 
chance to grab dinner.  Note that the meeting room will be Acacia West (prior 
announcements indicated Acacia 1).

Here is the current agenda..

Smart Grid Bar BOF Agenda
8:30PM - ?, Acacia West
November 11, 2009

I. Agenda Bashing (5 minutes)
Tim Polk
II. Smart Grid Overview (15 minutes)
Jim St. Pierre/Tim Polk
III. Japanese Interest in Smart Grid (15 minutes)
Hiroshi Esaki
IV. Introduction to the IP Priority Action Plan (15 minutes)
Tim Polk
V. Discussion of draft-baker-ietf-core (15 minutes)
Fred Baker
see http://www.ietf.org/id/draft-baker-ietf-core-04.txt
VI. Is the IETF the right place to do this work?
Russ Housley
VII. How should the work be organized? (contingent on V.)
Ralph Droms

Slides will be available via webex for remote participants, but we will be 
using the IETF streaming audio feed for sound.  The URLs for webex access have 
been appended to this message.

The audio feed for this session will be streamed at the following URL:
 http://videolab.uoregon.edu/events/ietf/ietf762.m3u
Remote participants will not be able to speak, but can send comments and 
questions in the webex chat room.

Thanks,

Tim Polk

- webex access details -

Frederick Baker invites you to attend this online meeting.

Topic: Smart Grid Bar BOF in Hiroshima
Date: Thursday, November 12, 2009
Time: 8:00 pm, Japan Time (Tokyo, GMT+09:00)
Meeting Number: 205 017 176
Meeting Password: smartgrid


---
To join the online meeting (Now from iPhones too!)
---
1. Go to 
https://ciscosales.webex.com/ciscosales/j.php?ED=128776942&UID=1209736217&PW=NYTMxMDcxYzMw&RT=MiM0OQ%3D%3D
2. Enter your name and email address.
3. Enter the meeting password: smartgrid
4. Click "Join Now".

To view in other time zones or languages, please click the link:
https://ciscosales.webex.com/ciscosales/j.php?ED=128776942&UID=1209736217&PW=NYTMxMDcxYzMw&ORT=MiM0OQ%3D%3D

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

Re: publishing some standards immediately at Draft-Standard status?

[Carsten Bormann]

On Nov 12, 2009, at 12:28, Tony Hansen wrote:


published directly at Draft Standard status


Raise the bar so they stay at I-D level for even longer?  A sizable  
part of the Internet is run on I-Ds, not on PS.


I think the right direction is to publish PS earlier.  If done right,  
it's only six months from there to the DS, you know.  (About half of  
that time the draft is stuck in the RFC finalization process anyway :-).


(My suggestion would be to stop talking about changing the rules and  
instead just find ways to use the current process better.)


Gruesse, Carsten

PS.: And you could spend some time during I-D time already to upgrade  
your downrefs to DS :-)


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

Re: [76attendees] Smart Grid "Bar BOF" Slides

[Peter Saint-Andre]

Tim had some troubles setting up the WebEx conference, so we are using
audio streaming, along with a Jabber chatroom here:

xmpp:smartg...@conference.jabber.org?join

On 11/11/09 5:44 PM, Fred Baker wrote:
> FYI - the slide decks in use for the Smart Grid "Bar BOF" are available at:
> ftp://ftpeng.cisco.com/fred/IETF-SG/
> 
> We will be running webex tonight, and slides are of course visible there
> as well.
> 
> On Nov 11, 2009, at 1:29 PM, Polk, William T. wrote:
> 
>> [As before, my apologies for the shotgun nature of this email.]
>>
>> Folks,
>>
>> I would like to provide an update to the logistics and agenda for
>> tonight's Smart Grid Bar BOF.
>>
>> The Bar BOF will begin at 8:30 so that folks attending the plenary
>> have a chance to grab dinner.  Note that the meeting room will be
>> Acacia West (prior announcements indicated Acacia 1).
>>
>> Here is the current agenda..
>>
>> Smart Grid Bar BOF Agenda
>> 8:30PM - ?, Acacia West
>> November 11, 2009
>>
>> I. Agenda Bashing (5 minutes)
>>Tim Polk
>> II. Smart Grid Overview (15 minutes)
>>Jim St. Pierre/Tim Polk
>> III. Japanese Interest in Smart Grid (15 minutes)
>>Hiroshi Esaki
>> IV. Introduction to the IP Priority Action Plan (15 minutes)
>>Tim Polk
>> V. Discussion of draft-baker-ietf-core (15 minutes)
>>Fred Baker
>>see http://www.ietf.org/id/draft-baker-ietf-core-04.txt
>> VI. Is the IETF the right place to do this work?
>>Russ Housley
>> VII. How should the work be organized? (contingent on V.)
>>Ralph Droms
>>
>> Slides will be available via webex for remote participants, but we
>> will be using the IETF streaming audio feed for sound.  The URLs for
>> webex access have been appended to this message.
>>
>> The audio feed for this session will be streamed at the following URL:
>> http://videolab.uoregon.edu/events/ietf/ietf762.m3u
>> Remote participants will not be able to speak, but can send comments
>> and questions in the webex chat room.
>>
>> Thanks,
>>
>> Tim Polk
>>
>> - webex access details -
>>
>> Frederick Baker invites you to attend this online meeting.
>>
>> Topic: Smart Grid Bar BOF in Hiroshima
>> Date: Thursday, November 12, 2009
>> Time: 8:00 pm, Japan Time (Tokyo, GMT+09:00)
>> Meeting Number: 205 017 176
>> Meeting Password: smartgrid
>>
>>
>> ---
>> To join the online meeting (Now from iPhones too!)
>> ---
>> 1. Go to
>> https://ciscosales.webex.com/ciscosales/j.php?ED=128776942&UID=1209736217&PW=NYTMxMDcxYzMw&RT=MiM0OQ%3D%3D
>>
>> 2. Enter your name and email address.
>> 3. Enter the meeting password: smartgrid
>> 4. Click "Join Now".
>>
>> To view in other time zones or languages, please click the link:
>> https://ciscosales.webex.com/ciscosales/j.php?ED=128776942&UID=1209736217&PW=NYTMxMDcxYzMw&ORT=MiM0OQ%3D%3D
>>
>>
> 
> ___
> 76attendees mailing list
> 76attend...@ietf.org
> https://www.ietf.org/mailman/listinfo/76attendees


smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: publishing some standards immediately at Draft-Standard status?

[Alexey Melnikov]

Tony Hansen wrote:
One idea discussed over various beverages last night was based on an 
observation about the high bar that most Proposed Standards have had 
to pass over in order to become RFCs: many of them would not have 
gotten to publication without having already gone through 
interoperability testing.


So the idea is that the shepherding files for such I-Ds could include 
interoperability reports indicating that they *are* already 
interoperable and have successful operational experience,
Note that a short version of this is already included in the shepherding 
document.

and then be published directly at Draft Standard status.


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

Re: IETF Plenary Discussions

[Olaf Kolkman]

During previous technical sessions I mailed an announcement about the technical 
plenary and in those announcements I've asked something along the lines of:

> If you consider asking a question during the open-microphone session it
> would be helpful to send that question to the IAB in advance.
> In that way we may be able to think about the problem and answer your
> question effectively. Note that sending in a question is _not_ a
> requirement for asking one. 


I believe that submitting questions in advance will help to get concise 
questions asked (because some thought went into phrasing them) and get pointed 
answers (because some thought went into answering them). In fact the questions 
may be shared by the larger group and not just the individual opinions of the 
folk that are happen to be on stage.

FWIW, in the sessions I had asked this questions nobody walked up during the 
microphone. I just forgot to add the paragraph in this weeks announcement.

--Olaf

 

Olaf M. KolkmanNLnet Labs
   Science Park 140, 
http://www.nlnetlabs.nl/   1098 XG Amsterdam

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