Weekly posting summary for ietf@ietf.org

[Thomas Narten]

Total of 216 messages in the last 7 days.
 
script run at: Fri Oct 29 00:53:02 EDT 2010
 
Messages   |  Bytes| Who
+--++--+
 11.57% |   25 |  9.50% |   150177 | m...@sandelman.ca
  4.17% |9 |  6.68% |   105561 | hal...@gmail.com
  5.09% |   11 |  3.38% |53427 | d...@dcrocker.net
  2.78% |6 |  5.59% |88361 | a...@fdos.ca
  3.70% |8 |  3.97% |62836 | mo...@network-heretics.com
  2.31% |5 |  4.30% |68008 | mstjo...@comcast.net
  3.24% |7 |  3.24% |51188 | jmp...@cisco.com
  3.24% |7 |  2.64% |41686 | alh-i...@tndh.net
  3.70% |8 |  2.05% |32456 | s...@harvard.edu
  1.39% |3 |  4.20% |66441 | jon.peter...@neustar.biz
  2.31% |5 |  1.86% |29479 | ferna...@gont.com.ar
  1.85% |4 |  2.25% |35581 | rdroms.i...@gmail.com
  2.31% |5 |  1.42% |22519 | paul.hoff...@vpnc.org
  2.31% |5 |  1.39% |22016 | mo...@necom830.hpcl.titech.ac.jp
  1.85% |4 |  1.72% |27216 | f...@cisco.com
  1.39% |3 |  2.15% |33918 | lars.egg...@nokia.com
  1.39% |3 |  2.04% |32244 | ebur...@standardstrack.com
  1.39% |3 |  1.67% |26326 | y...@checkpoint.com
  1.39% |3 |  1.45% |22980 | hous...@vigilsec.com
  1.39% |3 |  1.38% |21794 | ted.i...@gmail.com
  1.39% |3 |  1.28% |20273 | rcal...@juniper.net
  1.39% |3 |  1.22% |19275 | l...@cisco.com
  1.39% |3 |  1.18% |18732 | j...@jlc.net
  1.39% |3 |  1.17% |18486 | rja.li...@gmail.com
  1.39% |3 |  1.08% |17090 | a...@shinkuro.com
  1.39% |3 |  1.07% |16848 | ned+i...@mauve.mrochek.com
  1.39% |3 |  0.91% |14422 | o...@cisco.com
  1.39% |3 |  0.88% |13951 | julian.resc...@gmx.de
  1.39% |3 |  0.81% |12791 | bra...@isi.edu
  0.93% |2 |  1.13% |17817 | jwkck...@ix.netcom.com
  0.93% |2 |  1.11% |17566 | denghu...@gmail.com
  0.93% |2 |  0.88% |13865 | tglas...@earthlink.net
  0.93% |2 |  0.84% |13217 | ero...@cisco.com
  0.93% |2 |  0.83% |13143 | d3e...@gmail.com
  0.93% |2 |  0.78% |12258 | john-i...@jck.com
  0.93% |2 |  0.76% |12046 | m...@sap.com
  0.93% |2 |  0.76% |11951 | eburge...@standardstrack.com
  0.93% |2 |  0.72% |11335 | bortzme...@nic.fr
  0.93% |2 |  0.68% |10814 | si...@josefsson.org
  0.93% |2 |  0.68% |10706 | alexandru.petre...@gmail.com
  0.93% |2 |  0.66% |10513 | barryle...@computer.org
  0.93% |2 |  0.61% | 9630 | t...@americafree.tv
  0.46% |1 |  1.01% |15966 | ron.even@gmail.com
  0.46% |1 |  0.99% |15616 | even.r...@huawei.com
  0.46% |1 |  0.98% |15507 | lcon...@insensate.co.uk
  0.46% |1 |  0.96% |15159 | stpe...@stpeter.im
  0.46% |1 |  0.94% |14891 | health...@hotmail.com
  0.46% |1 |  0.86% |13531 | taliskerm...@hotmail.co.uk
  0.46% |1 |  0.75% |11861 | rich...@shockey.us
  0.46% |1 |  0.67% |10594 | s...@resistor.net
  0.46% |1 |  0.52% | 8289 | twa...@juniper.net
  0.46% |1 |  0.48% | 7621 | m...@sabahattin-gucukoglu.com
  0.46% |1 |  0.44% | 6902 | daedu...@btconnect.com
  0.46% |1 |  0.43% | 6732 | joe...@bogus.com
  0.46% |1 |  0.42% | 6568 | bab...@baby-dragons.com
  0.46% |1 |  0.40% | 6381 | bernard_ab...@hotmail.com
  0.46% |1 |  0.39% | 6233 | dwor...@avaya.com
  0.46% |1 |  0.39% | 6205 | ray.bel...@nominet.org.uk
  0.46% |1 |  0.39% | 6193 | nar...@us.ibm.com
  0.46% |1 |  0.38% | 6045 | n...@gnutls.org
  0.46% |1 |  0.36% | 5725 | adr...@olddog.co.uk
  0.46% |1 |  0.36% | 5706 | ber...@ietf.hoeneisen.ch
  0.46% |1 |  0.36% | 5697 | brian.e.carpen...@gmail.com
  0.46% |1 |  0.36% | 5674 | berti...@bwijnen.net
  0.46% |1 |  0.35% | 5588 | j...@apple.com
  0.46% |1 |  0.34% | 5391 | david.kess...@nsn.com
  0.46% |1 |  0.34% | 5359 | scott.b...@gmail.com
  0.46% |1 |  0.34% | 5352 | s...@cs.columbia.edu
  0.46% |1 |  0.33% | 5209 | rog...@gmail.com
  0.46% |1 |  0.31% | 4844 | randy_pres...@mindspring.com
  0.46% |1 |  0.30% | 4777 | hkap...@acmepacket.com
  0.46% |1 |  0.30% | 4668 | hhelvo...@huawei.com
  0.46% |1 |  0.29% | 4662 | d...@xpasc.com
  0.46% |1 |  0.28% | 4436 | gl...@riveronce.com
  0.46% |1 |  0.28% | 4421 | lly...@civil-tongue.net
  0.46% |1 |  0.27% | 4229 | c...@a.org
  0.46% |1 |  0.26% | 4066 | jo...@iecc.com
  0.46% |1 |  0.25% | 4005 | a...@gulbrandsen.priv.no
+--++--+
100.00% |  216 |100.00% |  1581046 | Total
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: An elephant in the room (was IETF processes (was Re: draft-housley-two-maturity-levels))

[Dave CROCKER]

On 10/28/2010 11:45 AM, Dave CROCKER wrote:

On 10/28/2010 11:41 AM, Ted Hardie wrote:

I think that any review of our use of standards designations or
how they relate to formal process needs to have some consideration of
the I-D aspects

...

Since you raised this, I'll point to the proposal that was circulated 6 years
ago. [1]

...

[1] 



This citation concerns snapshots of working group documents.

I meant to also include:

  

Which is an alternate 2-stage standards label proposal from back then...

d/

--

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

Re: Gen-ART review of draft-ietf-l3vpn-mvpn-spmsi-joins-01

[James M. Polk]

BTW Eric, my views here are just comments and shouldn't be taken as 
if these are showstoppers for your doc's progression.


James

At 02:38 PM 10/28/2010, James M. Polk wrote:

At 02:06 PM 10/28/2010, Eric Rosen wrote:


James> perhaps this needs to be stated (that the Type 4 is created by this
James> doc for your purpose)?

I think the doc already makes this clear, maybe I'm not sure what you are
asking.


you may be right (that I'm not being clear). This is all about the 
wording in Section 3. You doc creates and IANA registers this Type 4 
message (in the second paragraph), but you state in the doc that


   '...(this) may be used to assign a v6 customer to a P-tunnel in 
a PIMv4 SP.'


To me, and this has been beaten into me over the 340+ IDs I've 
written, that anytime one uses lowercase "may", it actually needs to 
be replaced with "can". If I do that in my head, this usage of a 
Type 4 is wishy-washy, in other words, something else is obviously 
available to do the same thing, otherwise the "can" meaning would 
have been stronger - like a "SHOULD be used to" or "MUST be used to" 
or even "will be used to", or the easiest "is used to".


And yes, I see that in the first paragraph you state that in some other doc a

   '...Type 1 may be used to to assign a v4 customer to a P-tunnel 
in a PIMv4 SP.'


so the wording is consistent, but I still don't like the lowercase 
use of a 2119 word, especially "may", because that means there are 
alternatives known, but here, they are not stated.




James> You can probably imagine how many SIP and RSVP protocol extensions
James> there are (70+ and about 20 respectively off the top of my head), and
James> yet every one of them have to state "Session Initiation Protocol
James> (SIP)" and "ReSource ReserVation Protocol (version-1) (RSVPv1)" the
James> first time they appear, no matter how big the community of interest
James> is.

And this makes sense to you?


no, but it is the way it has been and continues to be, at least in 
the areas I'm authoring in.  So you can take this one with the grain 
of salt, because those of mine that have slipped through to the 
RFC-Editor have always been caught there, but now that I've pointed this out...




Okay, I will expand the occurrence of "S-PMSI" in the abstract.

On the issue of the maximum UDP packet size, I think that is an
implementation issue and I don't think it is appropriate to raise it in this
document.


It would normally be ok, but your doc says effectively "go ahead and 
stick as many Joins as you want and something/where else will deal 
with the consequences"... and that doesn't make a good spec to 
me.  I recommend that at least a warning of link MTU causing 
fragmentation be mentioned as a potential inefficient side effect.


James



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

Re: Gen-ART review of draft-ietf-l3vpn-mvpn-spmsi-joins-01

[James M. Polk]

At 02:06 PM 10/28/2010, Eric Rosen wrote:


James> perhaps this needs to be stated (that the Type 4 is created by this
James> doc for your purpose)?

I think the doc already makes this clear, maybe I'm not sure what you are
asking.


you may be right (that I'm not being clear). This is all about the 
wording in Section 3. You doc creates and IANA registers this Type 4 
message (in the second paragraph), but you state in the doc that


   '...(this) may be used to assign a v6 customer to a P-tunnel in a 
PIMv4 SP.'


To me, and this has been beaten into me over the 340+ IDs I've 
written, that anytime one uses lowercase "may", it actually needs to 
be replaced with "can". If I do that in my head, this usage of a Type 
4 is wishy-washy, in other words, something else is obviously 
available to do the same thing, otherwise the "can" meaning would 
have been stronger - like a "SHOULD be used to" or "MUST be used to" 
or even "will be used to", or the easiest "is used to".


And yes, I see that in the first paragraph you state that in some other doc a

   '...Type 1 may be used to to assign a v4 customer to a P-tunnel 
in a PIMv4 SP.'


so the wording is consistent, but I still don't like the lowercase 
use of a 2119 word, especially "may", because that means there are 
alternatives known, but here, they are not stated.




James> You can probably imagine how many SIP and RSVP protocol extensions
James> there are (70+ and about 20 respectively off the top of my head), and
James> yet every one of them have to state "Session Initiation Protocol
James> (SIP)" and "ReSource ReserVation Protocol (version-1) (RSVPv1)" the
James> first time they appear, no matter how big the community of interest
James> is.

And this makes sense to you?


no, but it is the way it has been and continues to be, at least in 
the areas I'm authoring in.  So you can take this one with the grain 
of salt, because those of mine that have slipped through to the 
RFC-Editor have always been caught there, but now that I've pointed this out...




Okay, I will expand the occurrence of "S-PMSI" in the abstract.

On the issue of the maximum UDP packet size, I think that is an
implementation issue and I don't think it is appropriate to raise it in this
document.


It would normally be ok, but your doc says effectively "go ahead and 
stick as many Joins as you want and something/where else will deal 
with the consequences"... and that doesn't make a good spec to me.  I 
recommend that at least a warning of link MTU causing fragmentation 
be mentioned as a potential inefficient side effect.


James


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

RE: Gen-ART review of draft-ietf-l3vpn-mvpn-spmsi-joins-01

[Mr. James W. Laferriere]

Hello All ,

On Thu, 28 Oct 2010, Adrian Farrel wrote:

Hi,

There is a list of acronyms at
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt

Those marked with a star do not need to be expanded in any new I-D or RFC.

Those not marked need to be expanded on first use in the Abstract and in the
main body of the text (the Abstract is supposed to be free-standing).

Over time, the RFC Editor adds stars. I suspect they are susceptible to
lobbying.


	May I suggest that if any doucument at any stage of publication has 
Acronyms/Abbreviations that are susceptible to non-expansion at the time of that 
publication MUST have this url in the document .
	Sure might aleave the need for my & others requests for 'What's this ... 
mean?' questions on this and many other lists .


Hth ,  JimL


-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Eric
Rosen
Sent: 28 October 2010 20:07
To: James M. Polk
Cc: ietf@ietf.org; i...@cisco.com; t...@multicasttech.com; da...@tcb.net;
y...@cisco.com; ero...@cisco.com
Subject: Re: Gen-ART review of draft-ietf-l3vpn-mvpn-spmsi-joins-01


James> perhaps this needs to be stated (that the Type 4 is created by
James> this doc for your purpose)?

I think the doc already makes this clear, maybe I'm not sure what you are

asking.


James> You can probably imagine how many SIP and RSVP protocol
James> extensions there are (70+ and about 20 respectively off the top
James> of my head), and yet every one of them have to state "Session
James> Initiation Protocol (SIP)" and "ReSource ReserVation Protocol
James> (version-1) (RSVPv1)" the first time they appear, no matter how
James> big the community of interest is.

And this makes sense to you?

Okay, I will expand the occurrence of "S-PMSI" in the abstract.

On the issue of the maximum UDP packet size, I think that is an implementation
issue and I don't think it is appropriate to raise it in this document.

___
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



--
+--+
| James   W.   Laferriere | SystemTechniques | Give me VMS |
| Network&System Engineer | 3237 Holden Road |  Give me Linux  |
| bab...@baby-dragons.com | Fairbanks, AK. 99709 |   only  on  AXP |
+--+
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: An elephant in the room (was IETF processes (was Re: draft-housley-two-maturity-levels))

[Julian Reschke]

On 28.10.2010 20:45, Dave CROCKER wrote:



On 10/28/2010 11:41 AM, Ted Hardie wrote:

I think that any review of our use of standards designations or
how they relate to formal process needs to have some consideration of
the I-D aspects



Since you raised this, I'll point to the proposal that was circulated 6
years ago. [1]


Oh my, that's over six months old. We're not supposed to look at that.

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

RE: Gen-ART review of draft-ietf-l3vpn-mvpn-spmsi-joins-01

[Adrian Farrel]

Hi,

There is a list of acronyms at
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt

Those marked with a star do not need to be expanded in any new I-D or RFC.

Those not marked need to be expanded on first use in the Abstract and in the
main body of the text (the Abstract is supposed to be free-standing).

Over time, the RFC Editor adds stars. I suspect they are susceptible to
lobbying.

Cheers,
Adrian

> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Eric
> Rosen
> Sent: 28 October 2010 20:07
> To: James M. Polk
> Cc: ietf@ietf.org; i...@cisco.com; t...@multicasttech.com; da...@tcb.net;
> y...@cisco.com; ero...@cisco.com
> Subject: Re: Gen-ART review of draft-ietf-l3vpn-mvpn-spmsi-joins-01
> 
> 
> James> perhaps this needs to be stated (that the Type 4 is created by
> James> this doc for your purpose)?
> 
> I think the doc already makes this clear, maybe I'm not sure what you are
asking.
> 
> James> You can probably imagine how many SIP and RSVP protocol
> James> extensions there are (70+ and about 20 respectively off the top
> James> of my head), and yet every one of them have to state "Session
> James> Initiation Protocol (SIP)" and "ReSource ReserVation Protocol
> James> (version-1) (RSVPv1)" the first time they appear, no matter how
> James> big the community of interest is.
> 
> And this makes sense to you?
> 
> Okay, I will expand the occurrence of "S-PMSI" in the abstract.
> 
> On the issue of the maximum UDP packet size, I think that is an implementation
> issue and I don't think it is appropriate to raise it in this document.
> 
> ___
> 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: Gen-ART review of draft-ietf-l3vpn-mvpn-spmsi-joins-01

[Eric Rosen]

James> perhaps this needs to be stated (that the Type 4 is created by this
James> doc for your purpose)?

I think the doc already makes this clear, maybe I'm not sure what you are
asking.

James> You can probably imagine how many SIP and RSVP protocol extensions
James> there are (70+ and about 20 respectively off the top of my head), and
James> yet every one of them have to state "Session Initiation Protocol
James> (SIP)" and "ReSource ReserVation Protocol (version-1) (RSVPv1)" the
James> first time they appear, no matter how big the community of interest
James> is.

And this makes sense to you?

Okay, I will expand the occurrence of "S-PMSI" in the abstract.  

On the issue of the maximum UDP packet size, I think that is an
implementation issue and I don't think it is appropriate to raise it in this
document.

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

Re: An elephant in the room (was IETF processes (was Re: draft-housley-two-maturity-levels))

[Dave CROCKER]

On 10/28/2010 11:41 AM, Ted Hardie wrote:

I think that any review of our use of standards designations or
how they relate to formal process needs to have some consideration of
the I-D aspects



Since you raised this, I'll point to the proposal that was circulated 6 years 
ago. [1]


d/

[1] 

--

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

An elephant in the room (was IETF processes (was Re: draft-housley-two-maturity-levels))

[Ted Hardie]

On Thu, Oct 28, 2010 at 10:56 AM, Dave CROCKER  wrote:
>
> As a metric, once a working group has decided to issue a new Internet Draft,
> it takes almost no time to issue it.  Assuming no format hiccups, it's
> minutes.

The reality is that Internet-Drafts have become an archival series.  While they
expire from consideration, they remain extant and can be easily
referenced and retrieved.

Participants in the IETF commonly want a clear specification, on which there is
general agreement and which is available to all.  Sometimes they get that long
before something is made a standard at any level through the formal process
("The Internet runs on Internet-drafts") by simply adopting some I-D and running
with it.  Certainly lots of the creation of running code for
participants and their
organizations is created at this stage.

There is value in using the standards process to identify which specifications
have achieved that general agreement, but with I-Ds as an archival series,
there is no real way we can drive activity (such as demanding interoperable
implementations) based on access to the standards designations.

I think that any review of our use of standards designations or
how they relate to formal process needs to have some consideration of
the I-D aspects; this is a failure in my own proposal, and it may be important
to consider in any of them.

regards,

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

Re: An archive for nerdy t-shirts

[Ole Jacobsen]

Probably just folks who benefit from the fact that Dave Meyer and Lucy 
Lynch live there!

:-)


Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj



On Thu, 28 Oct 2010, Donald Eastlake wrote:

> These are unemployed engineers, right?
> 
> Donald
> 
> On Thu, Oct 28, 2010 at 2:23 PM, Lucy Lynch  wrote:
> > On Thu, 28 Oct 2010, Paul Hoffman wrote:
> >
> >> 
> >>
> >> Those of you with a good collection of old IETF t-shirts (and other
> >> schwag; did anyone keep the phone cards MCI gave us at IETF 34?) might
> >> consider having them archived by Jason.
> >
> > I always get a small jolt when I see some homeless guy in Eugene
> > wearing a NANOG or IETF shirt - maybe I should start documenting my sitings?
> >
> > - Lucy
> ___
> 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: An archive for nerdy t-shirts

[Donald Eastlake]

These are unemployed engineers, right?

Donald

On Thu, Oct 28, 2010 at 2:23 PM, Lucy Lynch  wrote:
> On Thu, 28 Oct 2010, Paul Hoffman wrote:
>
>> 
>>
>> Those of you with a good collection of old IETF t-shirts (and other
>> schwag; did anyone keep the phone cards MCI gave us at IETF 34?) might
>> consider having them archived by Jason.
>
> I always get a small jolt when I see some homeless guy in Eugene
> wearing a NANOG or IETF shirt - maybe I should start documenting my sitings?
>
> - Lucy
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF processes (was Re: draft-housley-two-maturity-levels)

[Eliot Lear]

Bob,

>
> Metrics? Examples? Comparisons with experience with other SDOs?

Ran brought up the LISP working group as a positive example of using
EXPERIMENTAL, so let's look at it.  To get even close to being finished,
the group has had to handle 113 issues, some 59 of which were opened by
one person who applied the PS standard to opening an issue (or higher). 
I certainly have seen many MANY PS docs go through with FAR fewer
issues.  As far as I'm concerned, I wouldn't advise someone who wanted
to get to PS to start with Experimental.  And quite frankly, most of the
work done in the IETF is far FROM experimental, but coded and sold.

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

Re: An archive for nerdy t-shirts

[Lucy Lynch]

On Thu, 28 Oct 2010, Paul Hoffman wrote:




Those of you with a good collection of old IETF t-shirts (and other 
schwag; did anyone keep the phone cards MCI gave us at IETF 34?) might 
consider having them archived by Jason.


I always get a small jolt when I see some homeless guy in Eugene
wearing a NANOG or IETF shirt - maybe I should start documenting my 
sitings?


- Lucy


--Paul Hoffman, Director
--VPN Consortium
___
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: An archive for nerdy t-shirts

[Ole Jacobsen]

http://www.yikes.com/~ole/store/MCI-IETF34.jpg


Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj



On Thu, 28 Oct 2010, Paul Hoffman wrote:

> 
> 
> Those of you with a good collection of old IETF t-shirts (and other 
> schwag; did anyone keep the phone cards MCI gave us at IETF 34?) 
> might consider having them archived by Jason.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> ___
> 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

An archive for nerdy t-shirts

[Paul Hoffman]

Those of you with a good collection of old IETF t-shirts (and other schwag; did 
anyone keep the phone cards MCI gave us at IETF 34?) might consider having them 
archived by Jason.

--Paul Hoffman, Director
--VPN Consortium
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF processes (was Re: draft-housley-two-maturity-levels)

[Dave CROCKER]

On 10/28/2010 10:43 AM, Bob Braden wrote:

On 10/28/2010 10:29 AM, Dave CROCKER wrote:

1. Getting /any/ RFC through the IETF process is very high overhead,
including Experimental.

...

Excuse me, but just what do you mean by "very high overhead"?


Quite a lot of work, with unpredictable and unbounded delay, for some of the 
steps.



Metrics? Examples? Comparisons with experience with other SDOs?


Comparing with other SDOs is irrelevant to this thread.

As a metric, once a working group has decided to issue a new Internet Draft, it 
takes almost no time to issue it.  Assuming no format hiccups, it's minutes.


In the IETF, to get that same document issued as Experimental requires the full 
IETF approval process with reviews, Last Call, AD support, IESG discussion 
cycles, IESG approval (with the variability of resolving Discusses), and RFC 
editing and approval.


At its very best, this is perhaps a couple of months, with extremely aggressive 
management support.  But it never is at its best.  More typical is 3-6 months.


The only implied criticism in my list is the variability of IESG approval.  All 
of the other components are expensive by design but usually proceed well.


Besides the delay in time, I'd guess that the aggregate cost in people's working 
time is some number of person-weeks. I would not be surprised if it proved more 
meaningful to cast it in terms of person-months.


In other words, as I said, high overhead.

A key point, here, is that the IETF really does not treat Experimental 
differently from Standards Track.  The presumption is that AD evaluation 
criteria are looser, but the default assumption should be that they are not, 
since the IESG has never been that structured or consistent in what prompts a 
Discuss.


d/
--

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

Re: IETF processes (was Re: draft-housley-two-maturity-levels)

[Scott Brim]

On 10/28/2010 12:22 EDT, RJ Atkinson wrote:
> On Weds, 27th October 2010, at 13:56:25 -0700, Bob Braden wrote in part:
>> In this environment, the only thing that seems to make sense 
>> is for WGs to start usually at Experimental (someone else
>> suggested this, I apologize for not recalling who it was).
> 
> Agreed.
> 
> Most times it would be better if IETF WGs initially create 
> an Experimental status RFC, possibly doing so quite rapidly, 
> and then later revise that (based on at experience) and 
> publish the revision on the IETF standards-track.

Given how many WGs these days in fact seem to start from "let's develop
something and see if we can make it useful", this wouldn't be too bad.

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

Re: IETF processes (was Re: draft-housley-two-maturity-levels)

[Bob Braden]

On 10/28/2010 10:29 AM, Dave CROCKER wrote:




1. Getting /any/ RFC through the IETF process is very high overhead,
including Experimental.


Dave,

Excuse me, but just what do you mean by "very high overhead"?

Metrics? Examples? Comparisons with experience with other SDOs?

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

Re: IETF processes (was Re: draft-housley-two-maturity-levels)

[Dave CROCKER]

On 10/28/2010 9:22 AM, RJ Atkinson wrote:

ost times it would be better if IETF WGs initially create
an Experimental status RFC, possibly doing so quite rapidly,
and then later revise that (based on at experience) and
publish the revision on the IETF standards-track.



1. Getting /any/ RFC through the IETF process is very high overhead, including 
Experimental.


2. Why does what you've suggested not qualify for the IRTF rather than the IETF? 
 Shouldn't a standards process be able to sit down and do a standard, rather 
than iterate on experimental designs?


d/
--

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

IETF processes (was Re: draft-housley-two-maturity-levels)

[RJ Atkinson]

On Weds, 27th October 2010, at 13:56:25 -0700, Bob Braden wrote in part:
> In this environment, the only thing that seems to make sense 
> is for WGs to start usually at Experimental (someone else
> suggested this, I apologize for not recalling who it was).

Agreed.

Most times it would be better if IETF WGs initially create 
an Experimental status RFC, possibly doing so quite rapidly, 
and then later revise that (based on at experience) and 
publish the revision on the IETF standards-track.

Indeed, this is what the LISP WG appears to be doing.
It also is how HIP started out (initially an IRTF HIP RG,
then an IETF HIP WG with Experimental RFCs, now the
IETF HIP WG is working on standards-track RFCs).
I am trying to follow that model with ILNP, which the
IRTF Routing RG has offered to the IRSG for publication
on the IRTF track, as a set of Experimental RFCs of course.

On Weds, 27th October 2010, at 14:48:22 -0700, Bob Braden wrote in part:
> I note that there seems to be some correlation between
> the degradation of the IETF process and the disappearance
> of the Internet research community from the IETF
> (the US government decided that no further R&D funding
> was required, since the Internet was "done".)

Agreed.  

There seems to be strong correlation between those events.  

I believe that the USG (and other research funding bodies 
elsewhere -- to be geographically neutral) were confused 
when they erroneously thought either that the Internet 
was "done" or that "industry would do any research that
might be needed in future".

The IAB's RFC-3869 expressed this concern in 2004, providing
several concrete examples of areas that industry wasn't solving 
and that needed more research.

Yours,

Ran

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

Re: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22 TransportOver IP' to Informational RFC

[Avygdor Moise]

The following text was added to the abstract:
  "This document was created by technical experts of the ANSI C12.22/IEEE 
1703/MC12.22 and ANSI C12.19/IEEE 1377/MC12.19 Standards working groups, based 
on their first hand knowledge of existing C12.22 implementations for the 
Internet. It is not an official and approved submission on behalf of the 
ANSI/IEEE or MC working groups. The content of this document is an expression 
of the aggregate experience of known implementations of ANSI C12.22/IEEE 
1703/MC12.22 for the SmartGrid using the Internet."

  I think it addresses the concerns you raise.
Regarding your assertion that "pretty much all Informational RFCs bear the 
following notation: This document is not an Internet Standards Track 
specification;"
  We are not an expects on the subject of IETF RFC front matter. I am confident 
that the correct front matter and copyrights material will be added by the RFC 
Editor. This material is not normally proided by the Authors since it is boiler 
plate machine generated text.
Otherwise, I am not very clear about what you are driving at, primarily because 
I do not have a clear context for your reasoning or your background with 
C12.22. I would recommend that if you are aware of proprietary implementations 
of C12.22 over IP that differ substantially from the documented framework in 
this RFC, then by all means bring them forward to our attention and we can 
review them for compliance first with IEEE 1703 / ANSI C12.22 / MC12.22 then 
this RFC and identify gaps, if any.

Thank You
Avygdor Moise


  - Original Message - 
  From: Michael StJohns 
  To: Avygdor Moise ; Ralph Droms 
  Cc: Ralph Droms ; Jonathan Brodkin ; IETF Discussion ; IESG IESG 
  Sent: Wednesday, October 27, 2010 3:58 PM
  Subject: Re: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22 
TransportOver IP' to Informational RFC


  I beg to differ  pretty much all Informational RFCs bear the following 
notation:

This document is not an Internet Standards Track specification;

This is clearly an example of an RFC stating what it is not.

  For the rest:

  "all known" is different than "all implementations known of by the authors 
and anyone they consulted (which could be a pretty limited group)" which is 
what you're trying to claim is an equivalence.  :-)  To use your own term "all 
known" is "rather strong".  

   "proprietary" simply means not publicly owned/produced/developed so not sure 
what you mean by "several proprietary C12.22... implementations" being "rather 
strong".  As far as I know, there are no non-proprietary implementations since 
there are no non-proprietary standards for this.  To be even more specific, the 
publication of this document will not create a non-proprietary standard - its 
just documenting existing proprietary specifications/implementations, and 
publication in and of itself doesn't change that status.



  At 02:50 AM 10/27/2010, Avygdor Moise wrote:

Dear Mr. St. Johns,

Respectfully, I think that it is not the purpose of the RFC to state what 
it is not.
The term "all known" cleanly relates to the authors' knowledge of known 
implementations. Certainly there may be a few implementations that do not 
follow this RFC, but the same is true nearly for any known Standard.
Also the term "several proprietary C12.22 over IP implementations" is 
rather strong in view of the history of the C12 Standards and the manner in 
which they are implemented.

Avygdor Moise

- Original Message - From: "Michael StJohns" 
To: "Ralph Droms" ; "Avygdor Moise" 
Cc: "Ralph Droms" ; "Jonathan Brodkin" 
; "IETF Discussion" ; "IESG IESG" 

Sent: Tuesday, October 26, 2010 4:24 PM
Subject: Re: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22 
TransportOver IP' to Informational RFC



  Hi Ralph -

  Exactly what I was getting at.  But a slight change in the wording you 
suggested to make things clear.

  Instead as the first paragraph of the abstract or as an RFC editor note I 
suggest:

  "This document is not an official submission on behalf of the ANSI C12.19 
and C12.22 working groups.  It was created by participants in those groups 
building on knowledge of several proprietary C12.22 over IP implementations.  
The content of this document is an expression of a consensus aggregation of 
those implementations."


  This, unlike your formulation, doesn't beg the question of whether or not 
"existing implementations"  and "all known" means "every single one including 
ones not publicly announced"

  Thanks, Mike


  At 05:34 PM 10/26/2010, Ralph Droms wrote:

Combining an excellent suggestion from Donald and Avygdor's 
clarification as to the official status of this document, I suggest an RFC 
Editor note to add the following text as a new last paragraph in the 
Introduction:

 This document was created by technical experts of the ANSI C12.22
 and ANSI C12.19 Standards, base

Re: what is the problem bis

[Keith Moore]

On Oct 28, 2010, at 5:05 AM, Yoav Nir wrote:

> That the labels can be updated is a good thing, but you would have to start 
> with something. 
> 
> People are complaining about the length of time it takes to get anything 
> published. Adding these extra steps of "protocol quality review", 
> "applicability review" etc. will only make that process even longer.

Much of this is already being done as part of internal review by IESG and the 
document shepherd.  So no, merely assigning these labels shouldn't make the 
process longer.

Actually (based on my long ago experience in IESG, which might or might not be 
informative of the situation today) part of the reason the current process may 
take so long might be that IESG is essentially trying to shoehorn a number of 
different concerns into a binary decision of whether something should be 
Proposed or not - and that decision often involves a lot of angst.  (e.g. when 
a WG has labored for years to produce a protocol which describes a good idea, 
but describes it poorly.)   Maybe the IESG could instead do its review, and 
assign values to these various labels.  If it doesn't think the document yet 
meets the threshold criteria for standards track, it could offer the WG or 
author the option to publish as Informational - but still with these labels.  
That way, readers could get a sense of the relative quality of the document and 
protocol and have some improved basis with which to judge whether they should 
implement it and whether it would work well for them.

Or - here's an idea - what if all that were holding up a document were stale 
references or normative references to non-standard documents?   The review 
could come back with Protocol-Quality=good, Applicability=wide, 
Document-Quality=good, Completeness=incomplete (with the reason given as: 
references to nonstandard material).  It might still not yet be labeled as 
standards-track but implementors would know that the document had generally met 
with favorable reviews.  

Keith

> Yoav
> 
> On Oct 28, 2010, at 3:57 AM, Keith Moore wrote:
> 
>> 
>> On Oct 27, 2010, at 8:58 AM, Yoav Nir wrote:
>> 
>>> This comes back to the question or why have maturity levels at all. 
>>> Ideally, an implementer should prefer to implement a mature standard over a 
>>> less-mature one. In practice, adopting the more advanced standard may give 
>>> you an obsolete protocol, rather than a more stable one. IOW the 
>>> standardization level of a document does not give a potential implementer 
>>> any signal as to whether or not this standard is in any sense of the word 
>>> "good".
>> 
>> Mostly agree.  The distinction between an older, well-tested, 
>> widely-deployed version of a protocol vs. a newer less-tested, 
>> less-widely-deployed version with more features is a useful distinction to 
>> make.  but the difference between (RFC X, full) and (RFC Y, proposed) where 
>> Y >> X only conveys the barest hint of that, and even less in the way of 
>> guidance.  I'm thinking specifically of email standards here, where in 
>> practice you need to be able to accept RFC 822 messages (because even new 
>> mail readers have to be able to deal with old messages) but you should 
>> generate messages that conform to 5322 and MIME.
>> 
>>> And if it doesn't signal anything to the "customers" of the documents, 
>>> what's the point of having these levels at all?
>> 
>> That's why I think we need a different set of labels, e.g.
>> 
>> Protocol-Quality.  We need a statement about the perceived quality of the 
>> protocol described in the document.   (Is this protocol well-designed for 
>> the anticipated use cases, or does it have significant flaws (including 
>> security flaws)?)
>> Applicability.  We need a statement about the current applicability of the 
>> protocol described in the document.  (Is this protocol recommended for 
>> general use, not recommended except in specific corner cases, not 
>> recommended at all, or strongly discouraged?)
>> Document-Quality.  We need a statement about the perceived quality of the 
>> document itself and whether the protocol description seems to be 
>> sufficiently precise to permit implementations to interoperate.   (along 
>> with a pointer to errata.)
>> Maturity.  We need a statement about the amount of actual implementation and 
>> deployment experience that the protocol enjoys. 
>> Completeness.  We need a statement about how accurately the document 
>> reflects what is currently believed to be good practice for 
>> implementation/use of that protocol, or whether effective implementation 
>> requires information not included or referenced in the document.  (e.g. 
>> effective implementation of SMTP generally requires some expertise in 
>> dealing with heavy loads caused by spam, looping, and denial-of-service 
>> attacks which aren't really dealt with in any of the relevant RFCs).
>> Last-Review-Date.  Date of the last review of these labels for this document.
>> 
>> These would go alo

Re: what is the problem bis

[Yoav Nir]

That the labels can be updated is a good thing, but you would have to start 
with something.

People are complaining about the length of time it takes to get anything 
published. Adding these extra steps of "protocol quality review", 
"applicability review" etc. will only make that process even longer.

Yoav

On Oct 28, 2010, at 3:57 AM, Keith Moore wrote:


On Oct 27, 2010, at 8:58 AM, Yoav Nir wrote:

This comes back to the question or why have maturity levels at all. Ideally, an 
implementer should prefer to implement a mature standard over a less-mature 
one. In practice, adopting the more advanced standard may give you an obsolete 
protocol, rather than a more stable one. IOW the standardization level of a 
document does not give a potential implementer any signal as to whether or not 
this standard is in any sense of the word "good".

Mostly agree.  The distinction between an older, well-tested, widely-deployed 
version of a protocol vs. a newer less-tested, less-widely-deployed version 
with more features is a useful distinction to make.  but the difference between 
(RFC X, full) and (RFC Y, proposed) where Y >> X only conveys the barest hint 
of that, and even less in the way of guidance.  I'm thinking specifically of 
email standards here, where in practice you need to be able to accept RFC 822 
messages (because even new mail readers have to be able to deal with old 
messages) but you should generate messages that conform to 5322 and MIME.

And if it doesn't signal anything to the "customers" of the documents, what's 
the point of having these levels at all?

That's why I think we need a different set of labels, e.g.

Protocol-Quality.  We need a statement about the perceived quality of the 
protocol described in the document.   (Is this protocol well-designed for the 
anticipated use cases, or does it have significant flaws (including security 
flaws)?)
Applicability.  We need a statement about the current applicability of the 
protocol described in the document.  (Is this protocol recommended for general 
use, not recommended except in specific corner cases, not recommended at all, 
or strongly discouraged?)
Document-Quality.  We need a statement about the perceived quality of the 
document itself and whether the protocol description seems to be sufficiently 
precise to permit implementations to interoperate.   (along with a pointer to 
errata.)
Maturity.  We need a statement about the amount of actual implementation and 
deployment experience that the protocol enjoys.
Completeness.  We need a statement about how accurately the document reflects 
what is currently believed to be good practice for implementation/use of that 
protocol, or whether effective implementation requires information not included 
or referenced in the document.  (e.g. effective implementation of SMTP 
generally requires some expertise in dealing with heavy loads caused by spam, 
looping, and denial-of-service attacks which aren't really dealt with in any of 
the relevant RFCs).
Last-Review-Date.  Date of the last review of these labels for this document.

These would go alongside the existing Updates and Obsoletes labels.  An 
Applicability-Statement could also be included.

It strikes me that we could establish such a set of labels on an experimental 
basis, using some sort of community review process for existing RFCs, without 
making any immediate changes to our proposed/draft/full system of labeling of 
standards.  IESG could assign the initial labels for new RFCs - the document 
reviewers are almost doing that anyway.  The existing errata process could be 
extended to allow (moderated) user comments on these labels, and the labels 
could be subject to periodic review based on those comments.

If that labeling system turned out to be adequate or could be fixed with some 
tweaking, we could maybe drop back to two document classes:  Informational, and 
Standards-Track.  Standards-track would encompass any  former proposed, draft, 
or full standard which was still in use and for which periodic reviews were 
still being done.   Former Experimental documents would be reclassified as 
Informational with appropriate descriptive labels.  Former Historic documents 
would be reclassified as Informational with Applicability set to Historic.   
Standards-track documents would expected to have periodic review of these 
labels; Informational documents could have some of those labels set to 
"Undetermined".

Keith


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