Subject: [RAI] Reducing Delays

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 4 Mar 2009 10:08:32 +0200

Hi all, 

Henning, Markus and myself have compiled a document that discusses the
aspect of delays in the standardization process a bit:
http://www.ietf.org/internet-drafts/draft-tschofenig-rai-reducing-delays-00.
txt

We provide a couple of suggestions and would like to hear your opinion. 

Ciao
Hannes

---

From: Dean Willis <[email-masked]>
Date: Wed, 4 Mar 2009 12:17:12 -0600

hannes said:
>
> http://www.ietf.org/internet-drafts/draft-tschofenig-rai-reducing-delays-00.txt
>
>
>

Neat document.

You should also factor in the delay between the document completing  
last call to being sent to the IESG. This involves the shepherd  
(usually but not necessarily a chair) and the chair. The lag factor  
here is usually the time needed to do the proto writeup, which  
requires the shepherd to not-check, spell-check, abnf-grammar-check,  
xml validate, and detailed re-read the document, often catching errors  
in the process that require another go with the author. This has to be  
done for the "final" version, since errors are often introduced in the  
edits resulting from WGLC comments.

--
Dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 4 Mar 2009 13:21:31 -0500

Good point. However, I wonder if most of these checks can't be done  
earlier, and then just do a diff of the checked document against the  
WGLC document. While the formal parts (XML, etc.) sometimes change  
late in the game, they often do not or only in trivial ways.

Henning

On Mar 4, 2009, at 1:17 PM, Dean Willis wrote:

> xml validate, and detailed re-read the document, often catching  
> errors in the process that require another go with the author. This  
> has to be done for the "final" version, since errors are often  
> introduced in the edits resulting from WGLC comments.
>
> --
> Dean
>
> _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai
>

---

From: Eric Burger <[email-masked]>
Date: Wed, 4 Mar 2009 11:37:28 -0800

The frustrating thing is I almost always get documents that fail  
idnits, ABNF check, etc. I sometimes wonder if authors actually look  
at the idnits result that is supposed to happen at the submission tool.

On Mar 4, 2009, at 10:21 AM, Henning Schulzrinne wrote:

>> requires the shepherd to not-check, spell-check, abnf-grammar- 
>> check, xml validate, and detailed re-read the document, often  
>> catching errors in the process that require another go with the  
>> author. This has to be done for the "final" version, since errors  
>> are often introduced in the edits resulting from WGLC comments.
>>
>> --
>> Dean
>>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 4 Mar 2009 14:44:03 -0500

I do, but I also find that correcting the draft to pass the idnits is a black art of boilerplate text manipulation, or RFC/draft references updating.

Why we can't just take all the boilerplate overhead and use one URL to point to it, and make the references just RFC numbers and avoid typing out author names and such, is beyond me... but IANAL.

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
> Burger
> Sent: Wednesday, March 04, 2009 2:37 PM
> To: Henning Schulzrinne
> Cc: [email-masked]
> Subject: Re: [RAI] Reducing Delays
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 4 Mar 2009 21:55:37 +0200

Ideally, these things should have been done earlier. However, since the
document changed a lot the chair typically starts with it in the last
minute. The authors always say "everything is fine" because they are sick of
the document by the time it leaves the group. 

In some cases the checks aren't trivial and when the PROTO shepherd messes
things up then the IESG will point with the finger at him. Example: In
KEYPROV I have a document
http://www.ietf.org/internet-drafts/draft-ietf-keyprov-pskc-02.txt that
contains XML and some of the examples have crypto-stuff in there that need
to be verified. This is not done in a few minutes.  

Consequently, these things can take some time with larger and complex
documents. 

Ciao
Hannes

>From: Henning Schulzrinne [mailto:[email-masked]] 
>Sent: 04 March, 2009 20:22
>To: Dean Willis
>Cc: Hannes Tschofenig; [email-masked]
>Good point. However, I wonder if most of these checks can't be 
>done earlier, and then just do a diff of the checked document 
>against the WGLC document. While the formal parts (XML, etc.) 
>sometimes change late in the game, they often do not or only 
>in trivial ways.
>
>Henning
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 04 Mar 2009 15:38:59 -0600

Hadriel Kaplan wrote:
> Why we can't just take all the boilerplate overhead and use one URL to point to it

You get this automatically and for free if you use an up-to-date version 
of xml2rfc.

> , and make the references just RFC numbers and avoid typing out author names and such, is beyond me...

You can completely avoid this by defining external reference entities. 
For example, you put set up your DOCTYPE like this:

<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
  <!ENTITY rfc4660 PUBLIC '' 
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4660.xml'>
  <!ENTITY rfc5057 PUBLIC '' 
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5057.xml'>
  <!ENTITY draft-ietf-sip-gruu PUBLIC '' 
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sip-gruu-15.xml'>
]>

And then set up your references like this:

    <references title="Normative References">
      &rfc4483;
      &draft-ietf-sip-gruu;
    </references>
    <references title="Informative References">
      &rfc5057;
    </references>

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 4 Mar 2009 17:49:51 -0500

Oh that's cool!  I guess there really is some tangible value in using the xml format for IETF draft's (although one self-created by their policies).  I'm still stuck in WinWord land. :(

-hadriel

> From: Adam Roach [mailto:[email-masked]]
> Sent: Wednesday, March 04, 2009 4:39 PM
> To: Hadriel Kaplan
> Cc: Eric Burger; Henning Schulzrinne; [email-masked]

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 4 Mar 2009 17:02:43 -0600

You've got to leave the land of WinWord - believe me life is SO MUCH
easier. There are several free XML editors and you can use XMLMind if
you prefer WYSIWYG. Personally, I prefer to just use a basic XML editor.
MS has a free XML editor - Visual Web Developer Express.  

Mary.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Wednesday, March 04, 2009 4:50 PM
To: Adam Roach
Cc: [email-masked]
Subject: Re: [RAI] Reducing Delays

Oh that's cool!  I guess there really is some tangible value in using
the xml format for IETF draft's (although one self-created by their
policies).  I'm still stuck in WinWord land. :(

-hadriel

> > Why we can't just take all the boilerplate overhead and use one URL 
> > to
> point to it
>
> You get this automatically and for free if you use an up-to-date 
> version of xml2rfc.
>
> > , and make the references just RFC numbers and avoid typing out 
> > author
> names and such, is beyond me...
>
> 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-s
> ip-
> gruu-15.xml'>
> ]>
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 04 Mar 2009 17:10:29 -0600

> MS has a free XML editor - Visual Web Developer Express.  

The best one is called "emacs", or if you want to come in to
the 21st century, try "xemacs" :-)

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Eric Burger <[email-masked]>
Date: Wed, 4 Mar 2009 15:11:08 -0800

The most common failures are long lines (almost always an XML schema),  
out of date references, and ABNF typos for the documents I have to  
process.

That is beyond the poor writing (mostly by NATIVE English speakers).   
I have given up on that :-(

On Mar 4, 2009, at 2:49 PM, Hadriel Kaplan wrote:

>
> Oh that's cool!  I guess there really is some tangible value in  
> using the xml format for IETF draft's (although one self-created by  
> their policies).  I'm still stuck in WinWord land. :(
>
> -hadriel
>
>
>>> Why we can't just take all the boilerplate overhead and use one  
>>> URL to
>> point to it
>>
>> version

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 04 Mar 2009 15:23:24 -0800

> the 21st century, try "xemacs" :-)

I thought the best one was vi (or gvim in this century) :-)

-- 
Marc Petit-Huguenin
Home: [email-masked]
Work: [email-masked]

---

From: Theo Zourzouvillys <[email-masked]>
Date: Wed, 4 Mar 2009 23:40:20 +0000

On Wed, Mar 4, 2009 at 11:11 PM, Eric Burger <[email-masked]> wrote:

> That is beyond the poor writing (mostly by NATIVE English speakers).  I have
> given up on that :-(

alas, not all of us (native English speakers) went to school, so
didn't learn how to write properly - sorry :)

 ~ Theo

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 4 Mar 2009 15:52:37 -0800

MS Word and Windows users can try the ISI online tools developed by Joe Touch

http://tools.ietf.org/html/draft-touch-msword-template-v2.0-07

http://www.isi.edu/touch/tools/
Go to templates

I have just done two I-Ds without any problems and believe it is the fastest and most robust to writer's errors.

Henry

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 4 Mar 2009 19:19:43 -0500

Yeah I've been using that template for a while, though it's boilerplate is out of date (I'm not sure any tool can keep up with IETF boilerplate changes these days :)).
It's pretty good, but it still ends up with some quirks, such as printing to the generic text printer in XP appends a space char at the end of each line, which the ID-submission tool can't parse correctly.
-hadriel

________________________________
From: Henry Sinnreich [mailto:[email-masked]]
Sent: Wednesday, March 04, 2009 6:53 PM
To: Mary Barnes; Hadriel Kaplan; Adam Roach
Cc: [email-masked]; [email-masked]
Subject: Re: [RAI] Reducing Delays

Henry

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 04 Mar 2009 16:45:55 -0800

>    <references title="Informative References">

I found easier to use the xinclude extension, something like this:

<references title="Informative References"
xmlns:xi="http://www.w3.org/2001/XInclude">
	<xi:include
xi:href="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml"
/>
	<xi:include
xi:href="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml"
/>
	<xi:include
xi:href="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4677.xml"
/>
</references>

I store the "master" XML file without the version number (i.e.
without -00, etc...) in git, so I can retrieve any version later,
and I then use the attached scripts to build the .txt version and
.xml version without comments or xinclude, ready for upload.  The
name of the files generated is taken from the docName attribute in
the rfc element.

The script just had to be run with the name of the draft as
parameter, without extension.

-- 
Marc Petit-Huguenin
Home: [email-masked]
Work: [email-masked]
#!/bin/bash
name=$(xsltproc name.xslt $1".xml")
echo xsltproc -xinclude -o $name".xml" dup.xslt $1.xml
xsltproc -xinclude -o $name".xml" dup.xslt $1.xml
echo xml2rfc $name".xml" $name.txt
xml2rfc $name".xml" $name.txt
idnits $name.txt

---

From: Eric Burger <[email-masked]>
Date: Wed, 4 Mar 2009 17:49:57 -0800

No - your writing is pretty good. It's the NATIVE speakers that seem  
to write poorly.

On Mar 4, 2009, at 3:40 PM, Theo Zourzouvillys wrote:

> On Wed, Mar 4, 2009 at 11:11 PM, Eric Burger <[email-masked] 
> > wrote:
>

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 4 Mar 2009 17:54:05 -0800

Yes, the boilerplate is out of date, but this is no surprise.
The quirks have been fixed.

 1.  Just edit the I-D using MS Word and this template,
 2.  Print to text generating the .prn file on your desktop
 3.  Upload the .prn and get the .txt file back.

As simple as this.

I have tried the XML tools but could not find a matching XML editor. Anyone knows one?

Needles to say, if PDF would be admitted, any editors could be used to generate professional documents :-)
No flames on this please.

Henry

On 3/4/09 6:19 PM, "Hadriel Kaplan" <[email-masked]> wrote:

Henry

---

From: Eric Burger <[email-masked]>
Date: Wed, 4 Mar 2009 18:10:05 -0800

I currently use XMLmind <http://www.xmlmind.com/xmleditor/>.  Free for  
personal use. Really good, as Bill Fenner wrote a WYSIWYG xml2rfc  
module for it.

In the past, I also used Altova XMLspy <http://www.altova.com>.  If  
you ask, you can get a free license for IETF or W3C work.

On Mar 4, 2009, at 5:54 PM, Henry Sinnreich wrote:

> Just edit the I-D using MS Word and this template,
> Print to text generating the .prn file on your desktop
> Upload the .prn and get the .txt file back.
>
> As simple as this.
>
> Yeah I’ve been using that template for a while, though it’s  
> boilerplate is out of date (I’m not sure any tool can keep up with  
> IETF boilerplate changes these days J).
> It’s pretty good, but it still ends up with some quirks, such as  
> printing to the generic text printer in XP appends a space char at  
> the end of each line, which the ID-submission tool can’t parse  
> correctly.
> -hadriel
>
>
>
> I have just done two I-Ds without any problems and believe it is the  
> fastest and most robust to writer’s errors.
>
> Henry
>
>
>

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 4 Mar 2009 20:29:40 -0600

And, Microsoft's Visual Web Editor Developer Express Edition is free and
it's very, very similar to XMLSpy. 
http://www.microsoft.com/express/vwd/

From: Eric Burger [mailto:[email-masked]] 
Sent: Wednesday, March 04, 2009 8:10 PM
To: Henry Sinnreich
Cc: Hadriel Kaplan; Barnes, Mary (RICH2:AR00); Adam Roach; [email-masked];
[email-masked]
Subject: Re: [RAI] Reducing Delays

I currently use XMLmind <http://www.xmlmind.com/xmleditor/>.  Free for
personal use. Really good, as Bill Fenner wrote a WYSIWYG xml2rfc module
for it. 

In the past, I also used Altova XMLspy <http://www.altova.com>.  If you
ask, you can get a free license for IETF or W3C work.

	
	As simple as this.
	
	I have tried the XML tools but could not find a matching XML
editor. Anyone knows one?
	
	Needles to say, if PDF would be admitted, any editors could be
used to generate professional documents :-)
	No flames on this please.
	
	Henry

	On 3/4/09 6:19 PM, "Hadriel Kaplan" <[email-masked]>
wrote:

		Yeah I've been using that template for a while, though
it's boilerplate is out of date (I'm not sure any tool can keep up with
IETF boilerplate changes these days :-)).  
		It's pretty good, but it still ends up with some quirks,
such as printing to the generic text printer in XP appends a space char
at the end of each line, which the ID-submission tool can't parse
correctly.
		-hadriel

		

		MS Word and Windows users can try the ISI online tools
developed by Joe Touch

		
		I have just done two I-Ds without any problems and
believe it is the fastest and most robust to writer's errors.
		
		Henry

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Wed, 4 Mar 2009 21:36:23 -0500

Hmmm...

You including native-American speakers in that?  :)

Mike

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Theo
> Zourzouvillys
> Sent: Wednesday, March 04, 2009 6:40 PM
> To: Eric Burger
> Cc: rai; Hadriel Kaplan

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 05 Mar 2009 09:12:37 +0200

Hi,

note that you do not even need an XML editor. You can use any text 
editor (I myself use emacs, for example, and some people use 'vi'). You 
could even use MS WORD if you then save the document in text format.

Cheers,

Gonzalo

---

From: Tom Taylor <[email-masked]>
Date: Thu, 05 Mar 2009 08:31:57 -0500

For years I've used the free version of Notetab. It has a macro capability which 
includes a library for XML. I've added custom macros for the high-runners: <p>, 
<section>, <xref>, and <list>. The others I assemble using the generic <element> 
and <attribute> macros.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 05 Mar 2009 09:31:05 -0600

> I found easier to use the xinclude extension, something like this:
[...]

I am curious: what do y'all do when there is no Internet
connectivity and you want to compile the .xml of a draft?  In
such cases, xml2rfc simply hangs trying to get to the
external reference entities.

In the past, I've downloaded the external entities locally
and then I use a local URL to refer to them in my .xml file.  This
allows xml2rfc to at least continue compiling and not hang
if I don't have Internet connectivity.

Are there other tips and techniques?

Thanks,

- vijay

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 05 Mar 2009 08:02:04 -0800

> Are there other tips and techniques?

Whith xinclude you can use a local copy with something like this:

<xi:include
xi:href="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
  <xi:fallback>
    <xi:include
xi:href="file:/home/petithug/xml2rfc/reference.RFC.2629.xml" />
    </xi:fallback>
</xi:include>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 05 Mar 2009 10:09:57 -0600

> xi:href="file:/home/petithug/xml2rfc/reference.RFC.2629.xml" />

Right; I can also do so by setting DOCTYPE as follows:

  <!ENTITY rfc2629 PUBLIC ''reference.RFC.2629.xml'>

instead of

  <!ENTITY rfc2629 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>

But that still means I have to have reference.RFC.2629.xml locally.

I was more interested in whether xml2rfc could be made more
intelligent in that it cached the external reference entities
locally, and IFF there is no Internet connectivity, it reverts
to the cache, thus allowing the compile to proceed.

When you compile next with Internet connectivity, the cache is
refreshed.

I suspect that if getting copies of documents locally is the only
way out, then we should inform the xml2rfc tools team if they
could implement a caching scheme as I describe above...

Thanks,

- vijay

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 05 Mar 2009 08:41:21 -0800

> could implement a caching scheme as I describe above...

Using a local HTTP proxy (e.g. squid) can be a solution.  No need to
have to deal with the complexities of caching in xml2rfc in this
casde.  This has the side effect to accelerate xml2rfc or xinclude
for the subsequent executions.  It does not solve the problem if
there is no Internet and you want to add a reference that is not
already in the cache.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 05 Mar 2009 10:48:33 -0600

Marc Petit-Huguenin wrote:
> casde.  

Squid does not help if I am in a plane, for instance, with
no Internet connectivity, or in a hotel where I do not want
to pay to access the Internet and am too lazy to go to a free
public WLAN hotspot.

> This has the side effect to accelerate xml2rfc or xinclude

What I have resorted to doing is to specify a local url and
just wget all the resources while I am connected.  That way, I
can get xml2rfc to compile anywhere, regardless of connectivity
(of course, I have to create a dummy local resource for
a newly added reference, but that is still okay ...)

Thanks,

- vijay

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 5 Mar 2009 12:27:45 -0800

>Have you reloaded it lately? I updated it last week. The .dot file
>should be dated Feb 26, 2009, and reflects the latest boilerplate.

Ah, thanks!

BTW: The old IPR statement validity ends this month.
There is a notice to that effect if you check a .txt document using the tool at
http://tools.ietf.org/tools/idnits/

Henry

On 3/5/09 11:14 AM, "Joe Touch" <[email-masked]> wrote:

> Yes, the boilerplate is out of date, but this is no surprise.

Have you reloaded it lately? I updated it last week. The .dot file
should be dated Feb 26, 2009, and reflects the latest boilerplate. As
others noted, changing the boilerplate is easy enough - just replace it.
It's highlighted (colored background) for your convenience, but
otherwise isn't special.

Joe

>     Yeah I?ve been using that template for a while, though it?s
>     boilerplate is out of date (I?m not sure any tool can keep up with
>     It?s pretty good, but it still ends up with some quirks, such as
>     the end of each line, which the ID-submission tool can?t parse
>     correctly.
>     -hadriel
>
>
>
>     ------------------------------------------------------------------------
>
>     *From:* Henry Sinnreich [mailto:[email-masked]]
>     *Sent:* Wednesday, March 04, 2009 6:53 PM
>     *To:* Mary Barnes; Hadriel Kaplan; Adam Roach
>     *Cc:* [email-masked]; [email-masked]
>     *Subject:* Re: [RAI] Reducing Delays
>
>     fastest and most robust to writer?s errors.
>
>     Henry
>
>

---

From: Dean Willis <[email-masked]>
Date: Thu, 5 Mar 2009 17:02:13 -0600

> No - your writing is pretty good. It's the NATIVE speakers that seem  

What'n hell you tawkin 'bout, city boy? Just causen yous and yourn  
doan speek proper, you thenk you ken go and say stuff liken dat 'bout  
dose of us who tawk and rite reel good? I jes doan no how fokes ken  
git all tinsed up like that!  Now, you 'pollergize, for'n my momma  
teks after you wid a skillet!

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 5 Mar 2009 19:40:07 -0500

> From: Joe Touch [mailto:[email-masked]]
> Sent: Thursday, March 05, 2009 12:14 PM
>
> Henry Sinnreich wrote:

Oh funny - you were right - *your* boilerplate was the latest and mine was an older one.  I had only skimmed yours and since it looked different than mine (which I know was new in January), I figured you still had the older one so I kept using mine.  But now I see your's is an even newer boilerplate and the I-D submit tool allowed mine but deep in the I-D nits it warned it was slightly old.

Anyway I'll send you my docs separately, to see if you can figure out why the submit tool is still having parser angst.

-hadriel
p.s. yes Henry - I'd prefer submitting PDF too!  It really is WYSIWYG, and then we could drop ascii-art (for which I recommend Jave, btw)

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 5 Mar 2009 18:39:04 -0800

>p.s. yes Henry - I'd prefer submitting PDF too!  It really is WYSIWYG, and then we could drop ascii-art (for which I recommend Jave, btw)

It can include A/V clips besides graphics, is searchable by Google, signatures, and has a lifecycle feature that could come handy in the personal and IETF editing processes. Is accepted by most governments and courts of law because the markups are strictly standard and it can be produced with a variety of tools.

My apology for this line :-)

Henry

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Fri, 6 Mar 2009 18:19:17 -0600

On Mar 5, 2009, at 8:39 PM, Henry Sinnreich wrote:

> >p.s. yes Henry - I'd prefer submitting PDF too!  It really is  
> WYSIWYG, and then we could drop ascii-art (for which I recommend  
> Jave, btw)
>
> It can include A/V clips besides graphics, is searchable by Google,  
> signatures, and has a lifecycle feature that could come handy in the  
> personal and IETF editing processes. Is accepted by most governments  
> and courts of law because the markups are strictly standard and it  
> can be produced with a variety of tools.

I've been doing the IT support for the softarmor site for quite a  
while now, and have also accumulated a digital  documentation record  
stretching back to the late 70s. Yep, there are 8" floppies around the  
house somewhere.

I've got PDFs I can't read, DOC files I can't read, WPS files I cant  
read, and all sorts of other bizarre word processor formats I can't  
even remember, plus the latest faux XML from Microsoft (which I can't  
read). The only documents I can still read from the 80s are ones I've  
painstakingly updated at every change in software. Oddly enough, I can  
still read the earliest text RFCs without difficulty, even on my cell  
phone.

I also have a wiki built on mediawiki, which uses a MySQL database  
backend. Now, MySQL is a fine database, but it's really difficult to  
port content out of the wiki  to somewhere else. Backing up is also a  
bit tricky; I have to do some rather complex periodic database dumps,  
and restoration requires more than just copying the files off a backup  
tape. But my old static HTML and text files move around really easily,  
and backups and recoveries using rsync are a snap. . This is in large  
part why I haven't moved onto the tools-team wiki; it's just too hard.

PDF might someday become a reasonable archival format, but I don't  
think it's one now.

--
Dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 6 Mar 2009 20:01:13 -0500

You might want to check out

http://en.wikipedia.org/wiki/PDF/A

---

From: Greg Herlein <[email-masked]>
Date: Fri, 6 Mar 2009 18:18:38 -0800

Henry, I respect your position, and I might be a very old fashioned
guy... but I can read a text RFC on any machine I own including my
PDA.    I don't need to install special software.  I would expect that
I can read a text file in 20 years on anything available.    If I have
an old PC and I live in Africa I know I can read the RFC.  Could I
read PDF/A?  Maybe not.

If the move was to a binary format I suppose that PDF/A would be a
contender.  Bu my old-fashioned mind still thinks text is better -
certainly if we want the developing world to read the standards too.

Greg

On Fri, Mar 6, 2009 at 5:01 PM, Henning Schulzrinne <[email-masked]> wrote:
>> PDF might someday become a reasonable archival format, but I don't think
>> it's one now.
>>
>> --
>> Dean
>>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 7 Mar 2009 11:44:41 +0200

This discussion thread shows another issue that can often be observed in
IETF discussion. 

There is a problem that has to be solved (often a more difficult technical
aspect, in our case it is more about problems that showed up in the way we
work). A discussion is started. 

It does not take too long until the discussion derails and the entire group
spends a fair amount of time discussing something else (often related). 

Particularly problematic is the case when a document is about to get
finished but then some other new proposal comes along and the entire group
focuses their time on the new hot topic instead of completing the previous
document. Ads and chairs often try to control this behavior by saying that
no new work gets added to the group unless the existing stuff is finished
but typically that does not help. We get distracted far too easily. 

Coming back to previous topic: 
http://www.ietf.org/internet-drafts/draft-tschofenig-rai-reducing-delays-00.
txt

Is the analysis about the reasons for delay roughly correct? Anything
missing? Something wrong? 

Regarding the suggestions: Do you have additional ideas? 
Many of the suggestions are currently targeting working group chairs and
area directors. What could **YOU** contribute?

I am surprised not to hear more comments given that in my work in the Nomcom
I got a lot of feedback about folks being unhappy with the current way of
working. I would like to hear what should be done to improve things. 

Ciao
Hannes

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 7 Mar 2009 12:26:57 -0500

> Hannes Tschofenig
> Sent: Saturday, March 07, 2009 4:45 AM
>

Yes, that is a problem.  What I don't know is whether it's because of the "shiny new toy" aspect, or whether it's because the previous document problem/solution no longer has interest/relevance.  For example sip-outbound - I liked that draft's goal a lot when it started.  We dragged on for years arguing over it (myself included).  My company even implemented running code for it, to test at Sipit.  But the interest level is weak among the endpoint vendors, and without them doing it, it's useless.  So in that case I don't think it's the new hot topic problem - it's an interest/relevance problem.

> area directors. What could **YOU** contribute?

I like most of the proposals in your draft.  The number of review stages is scary.  I think the current model works correctly for IP-Routing protocols, because those really do have to be thought through extremely carefully, and any changes there really should take a long time.  But for application layer things it's nuts.  I know this may sound obnoxious, but I fail to see how the IESG and directorates and IETF last call adds anything to the quality of our output, in general.  We've produce errors and bad RFC's, to be sure, but I haven't seen it prevented or improved once it gets past the AD's. (it could be, I just can't remember it happening)

As for delegating work to other SDO's, I don't know.  I know we don't have many interested folks in the 3GPP-type solutions.  I personally think their architecture is broken (and I know that's funny coming from a guy who works for an SBC vendor, but afaict we're the sane ones in comparison).  But I find it really scary that's it not even just one other SDO - there's an SDO for specific countries, and specific markets!  And most of them have very few actual SIP protocol experts.  I don't know how to prevent it or mitigate it, but I don't like the idea of giving up. :(

-hadriel
p.s. these views are my own and not necessarily my employer's

---

From: "Mary Barnes" <[email-masked]>
Date: Sat, 7 Mar 2009 13:22:43 -0600

Hadriel,

Just one comment below [MB].  I haven't read Hannes' document in detail
yet, so I can't really make any more constructive comments at this time.
And, I imagine the reason why many likely haven't read the doc in detail
is due to the document deadlines rather than lack of interest or concern
in addressing the issues in RAI. 

Mary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Saturday, March 07, 2009 11:27 AM
To: Hannes Tschofenig; [email-masked]
Subject: Re: [RAI] Back to the topic : Reducing Delays

> finished but then some other new proposal comes along and the entire 
> group focuses their time on the new hot topic instead of completing 
> the previous document. Ads and chairs often try to control this 
> behavior by saying that no new work gets added to the group unless the

> existing stuff is finished but typically that does not help. We get
distracted far too easily.

Yes, that is a problem.  What I don't know is whether it's because of
the "shiny new toy" aspect, or whether it's because the previous
document problem/solution no longer has interest/relevance.  For example
sip-outbound - I liked that draft's goal a lot when it started.  We
dragged on for years arguing over it (myself included).  My company even
implemented running code for it, to test at Sipit.  But the interest
level is weak among the endpoint vendors, and without them doing it,
it's useless.  So in that case I don't think it's the new hot topic
problem - it's an interest/relevance problem.

> Many of the suggestions are currently targeting working group chairs 
> and area directors. What could **YOU** contribute?

I like most of the proposals in your draft.  The number of review stages
is scary.  I think the current model works correctly for IP-Routing
protocols, because those really do have to be thought through extremely
carefully, and any changes there really should take a long time.  But
for application layer things it's nuts.  I know this may sound
obnoxious, but I fail to see how the IESG and directorates and IETF last
call adds anything to the quality of our output, in general.  We've
produce errors and bad RFC's, to be sure, but I haven't seen it
prevented or improved once it gets past the AD's. (it could be, I just
can't remember it happening)

[MB] I tend to disagree on this point having worked with Gen-ART for
going on 5 years. The stats show that docs actually get through a bit
quicker due to these review teams because far more issues get raised at
IETF LC time (before it gets to the IESG) and more docs are ready at the
time of the IESG reviews. Certainly, the majority of the reviews only
find minor issues, but I could produce the stats as to how many did
identify issues which did normatively impact the document. And, the
sec-dir reviews in particular can result in far better security
requirements and clarity wrt solutions. The two most recent docs that I
have run through the process have had the quality improved as a result
of post-WG reviews (i.e., AD reviews, secdir, Gen-Art and APPS).  And,
there have been others like yourself that think the additional reviews
result in additional delays. However, the don't' the directorate reviews
are done in parallel with IETF LC and often are the ONLY comments
received on a document during IETF LC. 
[/MB]

As for delegating work to other SDO's, I don't know.  I know we don't
have many interested folks in the 3GPP-type solutions.  I personally
think their architecture is broken (and I know that's funny coming from
a guy who works for an SBC vendor, but afaict we're the sane ones in
comparison).  But I find it really scary that's it not even just one
other SDO - there's an SDO for specific countries, and specific markets!
And most of them have very few actual SIP protocol experts.  I don't
know how to prevent it or mitigate it, but I don't like the idea of
giving up. :(

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 7 Mar 2009 14:54:46 -0500

Fair enough - I got an offline email from someone with experience in that area who said the same thing, that parallelizing reduce the delay.

-hadriel
p.s., and yes, I agree people are busy right now - this email thread is letting me procrastinate updating some drafts. :)

> From: Mary Barnes [mailto:[email-masked]]
> Sent: Saturday, March 07, 2009 2:23 PM
> To: Hadriel Kaplan; Hannes Tschofenig; [email-masked]
> Subject: RE: [RAI] Back to the topic : Reducing Delays
>
> Hadriel,
>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 07 Mar 2009 14:14:07 -0800

At Thu, 05 Mar 2009 10:09:57 -0600,
> could implement a caching scheme as I describe above...

Well, you *can* use bibxml2rfc, which has the additional benefit
of making references much simpler:

https://svn.resiprocate.org/rep/ietf-drafts/ekr/bibxml2rfc

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Thu, 05 Mar 2009 09:14:22 -0800

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 05 Mar 2009 09:16:00 -0800

Hadriel Kaplan wrote:
> Yeah I?ve been using that template for a while, though it?s boilerplate
> is out of date (I?m not sure any tool can keep up with IETF boilerplate
> changes these days J).  
> 
> printing to the generic text printer in XP appends a space char at the
> end of each line, which the ID-submission tool can?t parse correctly.

I've used it recently, and had no problems with the ID-submission tool.
If you're having any problems, please email me your:

	.doc file
	.prn file
	.txt file

I'll be glad to update the processing script to strip trailing spaces
off the line if that's causing problems, but I haven't seen any such
issues yet.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 05 Mar 2009 12:44:23 -0800

> http://tools.ietf.org/tools/idnits/

The current template has the latest IDR statement. I just submitted an
ID, and got no warnings at all. If you do get warnings, please send me
info. and I'll be glad to look into it. I do try to keep the template up
to date (though, FWIW, sometimes the info on what to change is vague).

Joe

---

From: Eric Burger <[email-masked]>
Date: Sun, 8 Mar 2009 09:06:13 -0400

I would have bet $50,000 that in 15 years it will be difficult to find  
a PDF/A reader, whereas an ASCII text reader will be quite available.

On the other hand, with the amount of legal text going PDF, there may  
be a shot for PDF/A.

On Mar 6, 2009, at 9:18 PM, Greg Herlein wrote:

> On Fri, Mar 6, 2009 at 5:01 PM, Henning Schulzrinne <[email-masked] 
> > wrote:
>>> think

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 8 Mar 2009 11:47:34 -0400

You can still find WordStar emulators and file readers/convertors, and it's been almost 30 years since it came out, and it didn't have the usage PDF does.

PDF is too widespread to go away - think of all the official docs published in it.  Everything from IRS tax forms to ITU docs, not to mention manuals, books, etc.

But anyway this topic is dead, 'cause we ain't gonna change. :)

-hadriel

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 9 Mar 2009 12:08:37 +0200

Here is a snippet of feedback that I got when I resisted making an IMHO
almost random change* to a document during the IETF Last Call for a simple
protocol extension that took more than 4 1/2 years of IETF standardization
work, where other SDOs are waiting for the outcome and that has been
implemented in the meanwhile (strange; some people don't want to wait
forever):  

The suggestion was made to change the boilerplate of I-Ds to:

"
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time unless somebody somewhere has written some code implementing the
protocol described therein. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in progress"
except if you really feel like it.
"

And my reluctance to change the specification (and the code) was commented
in the following way:

"
... but we're not arguing about
the 30 minutes it would take the lightning-fingered Mr. Tschofenig to
generate a new version of the draft any more, we're talking about the 30
minutes it would take to change a bit of code.
"

Ciao
Hannes

*: To me the request for change falls more into the philosophical area --
but not at all an uncommon request authors would get during IETF Last Call
from people.

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 9 Mar 2009 10:10:15 -0000

----- Original Message From: "Hannes Tschofenig"
> spends a fair amount of time discussing something else (often related).

I find that even when discussions stay on topic they often just seem to 
fizzle out with out a real conclusion.  I think it would really help if each 
major thread ended with an email that attempts to capture consensus.  I 
guess it would fall to a chair to either write, or (more likely) invite one 
of the participants to write up a consensus on the discussion.  This would 
have to include what each party thought, where there was agreement, where 
there was disagreement, and possibly what the road ahead was.

I would suggest that such e-mails have [Consensus Proposal] in the subject 
line.  If necessary that could be argued over, and when all parties are 
happy (which may involve the e-mail recording their unhappiness!), a final 
e-mail is submitted with the subject line including [Consensus].  Among 
other things, I think this would greatly help finding conclusions to 
discussions in the mail archives at a later date.

I think it could also be a useful tool for chairs to bring discussions back 
on topic.

On a related matter, I was wondering if you can use xml2rfc's <cref> tag to 
include explanatory text in addition to author questions.  For example, you 
could then do something like <cref>See "[Consensus] Impossible Problem" on 
SIP list dated 10 Feb 1998</cref> to record why a particular approach has 
been taken.  This could then be displayed in the working drafts, but not in 
the final RFC.  Or maybe it would be better to use a different tag with the 
same functionality but having a different semantic meaning.

HTH,

Pete Cordell

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 9 Mar 2009 16:11:02 +0200

Hi Pete, 
 
>> It does not take too long until the discussion derails and 
>the entire 
>> group spends a fair amount of time discussing something else (often 
>> related).
>
>I find that even when discussions stay on topic they often 
>just seem to fizzle out with out a real conclusion.  I think 
>it would really help if each major thread ended with an email 
>that attempts to capture consensus.  I guess it would fall to 
>a chair to either write, or (more likely) invite one of the 
>participants to write up a consensus on the discussion.  This 
>would have to include what each party thought, where there was 
>agreement, where there was disagreement, and possibly what the 
>road ahead was.
>
>I would suggest that such e-mails have [Consensus Proposal] in 
>the subject line.  If necessary that could be argued over, and 
>when all parties are happy (which may involve the e-mail 
>recording their unhappiness!), a final e-mail is submitted 
>with the subject line including [Consensus].  Among other 
>things, I think this would greatly help finding conclusions to 
>I think it could also be a useful tool for chairs to bring 
>discussions back on topic.

This is indeed a very good point. In most discussions nobody seems to be
responsible for providing a summary and conclusion. 
I would hope that this is not entirely the responsibility of the working
group chair but also of the document authors/editors. 

>
>On a related matter, I was wondering if you can use xml2rfc's 
><cref> tag to include explanatory text in addition to author 
>questions.  For example, you could then do something like 
><cref>See "[Consensus] Impossible Problem" on SIP list dated 
>10 Feb 1998</cref> to record why a particular approach has 
>been taken.  This could then be displayed in the working 
>drafts, but not in the final RFC.  Or maybe it would be better 
>to use a different tag with the same functionality but having 
>a different semantic meaning.

I saw this type of thing being done by the APPs guys. See, for example, 
http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-11.xml

More documents of that style are at: 
http://greenbytes.de/tech/webdav/

Ciao
Hannes

>> It does not take too long until the discussion derails and 
>the entire 
>> group
>> I am surprised not to hear more comments given that in my 
>work in the 
>> Nomcom

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 10 Mar 2009 00:44:05 +0100

In SIP by default, we expect the editor's to be doing this function. 

We'll only take it out of their hands if there is some major issue.

I suspect SIPPING is the same.

regards

Keith

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hannes Tschofenig
> Sent: Monday, March 09, 2009 2:11 PM
> To: 'Pete Cordell'; [email-masked]
> just seem to 
> >fizzle out with out a real conclusion.  I think it would 
> really help if 
> >each major thread ended with an email that attempts to capture 
> >consensus.  I guess it would fall to a chair to either 
> write, or (more 
> >likely) invite one of the participants to write up a 
> consensus on the 
> >discussion.  This would have to include what each party 
> thought, where 
> >there was agreement, where there was disagreement, and possibly what 
> >the road ahead was.
> >
> >I would suggest that such e-mails have [Consensus Proposal] in the 
> >subject line.  If necessary that could be argued over, and when all 
> >parties are happy (which may involve the e-mail recording their 
> >unhappiness!), a final e-mail is submitted with the subject line 
> >including [Consensus].  Among other things, I think this 
> would greatly 
> >help finding conclusions to discussions in the mail archives 
> at a later 
> >date.
> >
> This is indeed a very good point. In most discussions nobody 
> seems to be responsible for providing a summary and conclusion. 
> I would hope that this is not entirely the responsibility of 
> the working group chair but also of the document authors/editors. 
> 
> 
> >
> >On a related matter, I was wondering if you can use xml2rfc's <cref> 
> >tag to include explanatory text in addition to author 
> questions.  For 
> >example, you could then do something like <cref>See "[Consensus] 
> >Impossible Problem" on SIP list dated 10 Feb 1998</cref> to 
> record why 
> >a particular approach has been taken.  This could then be 
> displayed in 
> >the working drafts, but not in the final RFC.  Or maybe it would be 
> >better to use a different tag with the same functionality 
> but having a 
> >different semantic meaning.
>

---

From: Fred Baker <[email-masked]>
Date: Mon, 9 Mar 2009 17:47:26 -0700

I maintain a copy of the include libraries locally and use <?rfc  
'include=reference.RFC.1234' ?>

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 9 Mar 2009 20:31:24 -0500

Yes, in SIPPING, in general, the expectation is that the editor is the
one that would summarize the problem and potential solution options,
along with a proposed way forward.  And, that's what I've done as editor
in other WGs for the most part - there are occasions when a chair or
someone else involved in the discussion will do so.  So, I don't think
this is necessarily the issue in my experience. In my experience, the
issue is that even after that is done and an editor and some WG
members/chairs *think* an issue is resolved, folks still bring the same
issue up again. So, IMHO, the bigger issue is when consider a problem
closed and NOT allow it to be re-opened unless there's a really
compelling reason. In my experience, this typically happens when person
x didn't have time to follow the discussion previously and now the topic
is back on their radar.  So, I think this relates to the suggestion that
we don't strive for perfection in the documents but rather accept "good
enough".

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
DRAGE, Keith (Keith)
Sent: Monday, March 09, 2009 6:44 PM
To: Hannes Tschofenig; 'Pete Cordell'; [email-masked]
Subject: Re: [RAI] Back to the topic : Reducing Delays

regards

Keith

> This is indeed a very good point. In most discussions nobody seems to 
> be responsible for providing a summary and conclusion.
> I would hope that this is not entirely the responsibility of the 
> working group chair but also of the document authors/editors.
> 
> 
> >

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 10 Mar 2009 09:36:44 -0000

Well, I'm afraid that I just don't see this happening.  Sure the easy issues 
rapidly reach a conclusion and we move on.  But there are a number of issues 
that run a bit, fizzle out and then much later are re-opened again.  It's 
those sorts of issues that it would be good to nail down better.

Thinking about it, I don't think the chair has to do anything here.  If a 
thread seems to have fizzled out, then anybody that is following the thread 
should be able to take it upon themselves as a good IETF citizen to ask if 
it is time to write up a consensus proposal for that thread.  What they need 
is a mandate to be able to make such a request without being told where to 
go, which suggests some sort of agreed process to me!

And I don't even think the editors/authors need to write up the consensus 
either.  Anyone can, the most vocal being the main candidates.  It just 
makes sense that the editors/authors get to see the consensus and, possibly 
by their silence, agree to it.

And when I say "write up" I'm not expecting a book on the subject.  In most 
cases it need be no longer than my addition here.

As to re-opening issues, I think by including some well know flag in the 
subject line (such as [Consensus Proposal] or [Conclusion Proposal]) it will 
prompt those people that have an interest, but are looking elsewhere, to 
take a look.  And if an issue is re-opened, then having an e-mail that 
includes in the subject line [Consensus] or [Conclusion] will help pick up 
the debate from the last point a lot quicker, rather than re-hashing the 
same material again.

(And often threads split and split and split without changing the subject 
line, making threads difficult to follow.  So I've changed the subject line 
here!)

Pete

----- Original Message ----- 
From: "Mary Barnes" <[email-masked]>
To: "DRAGE, Keith (Keith)" <[email-masked]>; "Hannes Tschofenig" 
<[email-masked]>; "Pete Cordell" <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, March 10, 2009 1:31 AM
Subject: RE: [RAI] Back to the topic : Reducing Delays

Mary.

-----Original Message-----

regards

Keith

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 10 Mar 2009 10:15:30 -0000

BTW - if such a process were thought to be useful I'm prepared to write up a 
short ID on it.  That way people new to RAI would know about it and would be 
more able to contribute without first having to learn secret handshakes etc.

Pete

----- Original Message ----- 
From: "Pete Cordell" <[email-masked]>
To: "Mary Barnes" <[email-masked]>; "DRAGE, Keith (Keith)" 
<[email-masked]>; "Hannes Tschofenig" <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, March 10, 2009 9:36 AM
Subject: Re: [RAI] Recording Consensus (was: Back to the topic : 
ReducingDelays)

>
> Well, I'm afraid that I just don't see this happening.  Sure the easy 
> issues rapidly reach a conclusion and we move on.  But there are a number 
> of issues that run a bit, fizzle out and then much later are re-opened 
> again.  It's those sorts of issues that it would be good to nail down 
> better.
>
> thread seems to have fizzled out, then anybody that is following the 
> thread should be able to take it upon themselves as a good IETF citizen to 
> ask if it is time to write up a consensus proposal for that thread.  What 
> they need is a mandate to be able to make such a request without being 
> told where to go, which suggests some sort of agreed process to me!
>
> makes sense that the editors/authors get to see the consensus and, 
> possibly by their silence, agree to it.
>
> And when I say "write up" I'm not expecting a book on the subject.  In 
> most cases it need be no longer than my addition here.
>
> subject line (such as [Consensus Proposal] or [Conclusion Proposal]) it 
> will prompt those people that have an interest, but are looking elsewhere, 
> to take a look.  And if an issue is re-opened, then having an e-mail that 
> line, making threads difficult to follow.  So I've changed the subject 
> line here!)
>
> Pete
>

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 10 Mar 2009 08:35:04 -0500

There is already a document on consensus gathering:
http://tools.ietf.org/id/draft-dusseault-consensus-00.txt  
It doesn't explicitly deal with how to bring an issue to a consensus
call, so perhaps you can contribute your suggestion to that document.

I personally believe topic fizzle out over time and that's for a number
of reasons (and not because no one over brought forth a call for
consensus). In some cases, the problem may be a corner case that isn't
deemed high enough priority to resolve at that time. Sometimes, the
problem can't be solved due to some fundamentals in the protocol (e.g.,
early media). Sometimes the reasons are philosophical (e.g., whether or
not B2BUAs are recognized in the architecture). And, some are due to too
much flexibility and not enough structure in the protocol (e.g., INFO).
Or, the problem can't be solved in a way to please everyone (this is
really where the document above fits in).  And, sometimes, folks just
get tired of a topic that isn't progressing and no one has the energy
(or time) to focus on it. 

So, I don't think it's a process sort of issue, per se. The process is
already such that anyone that feels they have something constructive to
add should feel free to do as you suggest.  This can be difficult for
people new to RAI either way. 

Mary. 

-----Original Message-----
From: Pete Cordell [mailto:[email-masked]] 
Sent: Tuesday, March 10, 2009 5:16 AM
To: Barnes, Mary (RICH2:AR00); DRAGE, Keith (Keith); Hannes Tschofenig;
[email-masked]

BTW - if such a process were thought to be useful I'm prepared to write
up a short ID on it.  That way people new to RAI would know about it and
would be more able to contribute without first having to learn secret
handshakes etc.

Pete

----- Original Message -----
From: "Pete Cordell" <[email-masked]>
To: "Mary Barnes" <[email-masked]>; "DRAGE, Keith (Keith)" 
<[email-masked]>; "Hannes Tschofenig"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, March 10, 2009 9:36 AM
Subject: Re: [RAI] Recording Consensus (was: Back to the topic : 
ReducingDelays)

> issues rapidly reach a conclusion and we move on.  But there are a 
> number of issues that run a bit, fizzle out and then much later are 
> re-opened again.  It's those sorts of issues that it would be good to 
> nail down better.
>
> Thinking about it, I don't think the chair has to do anything here.  
> If a thread seems to have fizzled out, then anybody that is following 
> the thread should be able to take it upon themselves as a good IETF 
> citizen to ask if it is time to write up a consensus proposal for that

> thread.  What they need is a mandate to be able to make such a request

> without being told where to go, which suggests some sort of agreed
process to me!
>
> And I don't even think the editors/authors need to write up the 
> consensus either.  Anyone can, the most vocal being the main 
> candidates.  It just makes sense that the editors/authors get to see 
> the consensus and, possibly by their silence, agree to it.
>

> As to re-opening issues, I think by including some well know flag in 
> the subject line (such as [Consensus Proposal] or [Conclusion 
> Proposal]) it will prompt those people that have an interest, but are 
> looking elsewhere, to take a look.  And if an issue is re-opened, then

> having an e-mail that includes in the subject line [Consensus] or 
> [Conclusion] will help pick up the debate from the last point a lot 
> quicker, rather than re-hashing the same material again.
>
> (And often threads split and split and split without changing the 
> subject line, making threads difficult to follow.  So I've changed the

> subject line here!)

> along with a proposed way forward.  And, that's what I've done as 
> editor in other WGs for the most part - there are occasions when a 
> chair or someone else involved in the discussion will do so.  So, I 
> don't think this is necessarily the issue in my experience. In my 
> experience, the issue is that even after that is done and an editor 
> and some WG members/chairs *think* an issue is resolved, folks still 
> bring the same issue up again. So, IMHO, the bigger issue is when 
> consider a problem closed and NOT allow it to be re-opened unless 
> there's a really compelling reason. In my experience, this typically 
> happens when person x didn't have time to follow the discussion 
> previously and now the topic is back on their radar.  So, I think this

> relates to the suggestion that we don't strive for perfection in the 
> documents but rather accept "good enough".
>
> Mary.
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 10 Mar 2009 10:30:35 -0500

Hi, Mary,

I may have misunderstood, but where I thought this thread was headed was 
that topics fizzle off with no resolution, AND THEN UN-FIZZLE back into 
existance at the most inopportune times ("five minutes after requesting 
publication", etc.)

My question (to the group) is whether we think we're really going to treat 
these posted "conclusions" like they matter. We have a tradition that it's 
never too late to raise technical objections to a document. A working group 
chair might be able to get away with saying, "but we already discussed that 
and decided X", but I think that is a change to our tradition.

If we make that change to our tradition, I'd be a lot more excited about 
formalizing topic conclusions on the mailing list!

Thanks,

Spencer

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 10 Mar 2009 18:22:04 +0200

There are a couple of issues: 

* It is probably good that we do not formalize every decision making process
since otherwise we will delay things for ever. My example:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-sip-lo-retransmission
-02.txt written in response to an open issue in SIP Location Conveyance.
Might be the only way to deal with a difficult group but certainly adds huge
delays. 

* If a document takes 5 years then I believe it is not surprising that some
of the issues get re-opened because a completely new generation of
standardization people look at it and the world has changed entirely during
these years.

* From Mary's and Keith's response I could get the impression that things
are fine with the way how discussions are summarized. Maybe that's not a
problem. Don't know -- waiting for community feedback. 

So, I wonder why some of documents the group cares about still have a hard
time. To cite the often mentioned examples: SIP Outbound, GRUU

It remains difficult to figure out what the main source of the problem is
and what steps could help to improve the situation. 

Ciao
Hannes

PS: Two other things I wanted to mention: 

A) We tried to phrase the ECRIT agenda this time in a slightly different
fashion, see http://www.ietf.org/proceedings/09mar/agenda/ecrit.txt

Typically, documents are listed in the agenda and nobody really knows in
detail what shall be accomplished during the meeting. 

B) In updating a document in the IPSECME WG I found the usage of the issue
tracker by them quite useful. Take a look at it: 
http://tools.ietf.org/wg/ipsecme/ and http://tinyurl.com/bazw38. 

>From: Spencer Dawkins [mailto:[email-masked]] 
>Sent: 10 March, 2009 17:31
>To: Mary Barnes; Pete Cordell; DRAGE, Keith (Keith); Hannes 
>Tschofenig; [email-masked]
>Subject: Re: [RAI] Recording Consensus (was: Back to the topic 
>:ReducingDelays)
>
>Hi, Mary,
>
>I may have misunderstood, but where I thought this thread was 
>headed was that topics fizzle off with no resolution, AND THEN 
>UN-FIZZLE back into existance at the most inopportune times 
>("five minutes after requesting publication", etc.)
>
>My question (to the group) is whether we think we're really 
>going to treat these posted "conclusions" like they matter. We 
>have a tradition that it's never too late to raise technical 
>objections to a document. A working group chair might be able 
>to get away with saying, "but we already discussed that and 
>decided X", but I think that is a change to our tradition.
>
>If we make that change to our tradition, I'd be a lot more 
>excited about formalizing topic conclusions on the mailing list!
>
>Thanks,
>
>Spencer
>
>
>> I personally believe topic fizzle out over time and that's for a 
>> number of reasons (and not because no one over brought forth a call 
>> for consensus). In some cases, the problem may be a corner case that 
>> isn't deemed high enough priority to resolve at that time. 
>Sometimes, 
>> the problem can't be solved due to some fundamentals in the protocol 
>> (e.g., early media). Sometimes the reasons are philosophical (e.g., 
>> whether or not B2BUAs are recognized in the architecture). And, some 
>> are due to too much flexibility and not enough structure in 
>the protocol (e.g., INFO).
>> already such that anyone that feels they have something constructive 
>> to add should feel free to do as you suggest.  This can be difficult 
>> for people new to RAI either way.
>>
>> Mary.
>>
>> To: Barnes, Mary (RICH2:AR00); DRAGE, Keith (Keith); Hannes 
>> Tschofenig; [email-masked]
>> BTW - if such a process were thought to be useful I'm prepared to 
>> write up a short ID on it.  That way people new to RAI would know 
>> about it and would be more able to contribute without first 
>having to 
>> learn secret handshakes etc.
>>
>> Pete
>>
>Behalf Of 
>>>> ><cref>

---

From: Dean Willis <[email-masked]>
Date: Tue, 10 Mar 2009 19:50:11 -0500

> and what steps could help to improve the situation.

Sometimes, problems are just hard. We often start with a hard problem,  
then complicate it to insanity. Building a safe, reliable, inexpensive  
tricycle for toddlers to ride around the park is hard. Then we add 2- 
ton cargo panniers and a hypersonic aerodynamic stabilizer to the  
configuration and wonder what happened.

As a chair, when I think we have a tractable problem and a reasonable  
conclusion on the table, I push hard for a consensus around that  
conclusion. But once something gets out-of-hand, pushing in it for  
conclusion is counterproductive. Letting people think about it until  
there's a consensus we didn't really NEED the 2-ton panniers and  
hypersonic stabilizer is sometimes a better thing for the community.

GRUU and Outbound and many of their kin are in the unenviable position  
of trying to make the tricycle work AFTER it has already been fitted  
with panniers and stabilizer, as well as a few hundred other  
complications. This makes them Really Hard Problems, with lots and  
lots of triggerwork needed to make the solutions work at all.   
Consequently, several things happen:

1) Many people understand neither the requirements nor solution, but  
want to (or think they do) leading us around in circles.  Others  
understand things mostly, but still wander off into the woods  
occasionally, and we follow, more of a backtrack than a circle.

2) Others quite rationally see that the resulting aggregate will be  
Very Hard to Build, not because of GRUU or Outbound themselves but  
because of the underlying complexity which those (or similar)  
documents must address. These people try, and generally fail, to lead  
us back to simpler solutions, again causing circular migration.

3) The people leading the charge and pushing the solutions burn out  
from either fighting the incredible complexity or the enervating  
distractions raised by #1 and #2.   This happens nine months to two  
years after a document is introduced -- any author who continues to  
have energy after this time I hereby decree to be a Mythic Hero.

This is all aggravated by the churn of personnel, and by competition  
with new complexities.

My solution?

Simplify where possible. Exclude that which can be excluded. Build a  
community focused around that which remains, and keep that community  
focused until the work concludes. Be prepared to terminate the  
exercise if it reaches the hypersonic stabilizer vs. two-ton-pannier  
stage,  long before it decides to include both.

In practice, this means short-lived working groups with narrow, fixed  
charters, a high sense of urgency, a commitment to simplicity, and  
reasonable proof of feasibility  as evidenced by a working example,  
i.e. running code. If we can't build the specification and proof that  
the spec works in a reasonably short period of time, then we're trying  
to build something too complicated to get off the ground safely.

An old saying goes that the proper way to eat an elephant is one  
spoonful at a time. If we keep chewing more than we can swallow, we  
need smaller spoons and more teamwork. Or just maybe we need a  
smaller, fresher elephant, since they do tend to go a bit "off" after  
they've been nibbled on awhile. Also, keep in mind that spoons wear  
out and need to be replaced from time to time.

--
Dean

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 10 Mar 2009 18:22:31 -0700

Auguste Rodin was asked what is the secret of his sculptures. He answered something like this:

"Take away all the unnecessary marble until you finally get the statue".

Henry

On 3/10/09 7:50 PM, "Dean Willis" <[email-masked]> wrote:

My solution?

--
Dean

---

From: Richard Bennett <[email-masked]>
Date: Tue, 10 Mar 2009 18:38:13 -0700

Actually, that was Michaelangelo. By Rodin's time, the expression was 
received wisdom.

RB

Henry Sinnreich wrote:
> “Take away all the unnecessary marble until you finally get the statue”.
>
> Henry
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 11 Mar 2009 11:06:52 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
> Willis
> Sent: Tuesday, March 10, 2009 8:50 PM
> 

If we're going to pick on specific drafts, GRUU doesn't seem that complicated to me.  It has a couple extra bells/whistles, but really I think it's clever and clean.  It's just not working right in all cases, partly due to deployment architectures (evil SBC's), partly due to the proliferation of B2BUA's of various flavors, and partly due to implementations which are using older-draft param names.  And not everyone thinks they need GRUU, yet.

Outbound is another matter.  We should have pulled out the redundant-outbound-proxy thing early on, and just focused on a single connection to the proxy/registrar through NATs.  I don't know if that would have made it get done faster - I seem to recall we spent a lot of time on the keepalive mechanism to use (remember PING vs STUN?) - but we did also debate the whole primary/secondary/backup stuff and DNS for that and such for a long time, which we could have avoided by splitting it out.

history = hindsight = 20/20; 
while (history) {
	Mistakes++;
	cout << "You did it again" << endl;
	if (Mistakes.learn()) break;
}

-hadriel

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 11 Mar 2009 17:59:16 +0200

>Outbound is another matter.  We should have pulled out the 
>redundant-outbound-proxy thing early on, and just focused on a 
>single connection to the proxy/registrar through NATs.  I 
>don't know if that would have made it get done faster - I seem 
>to recall we spent a lot of time on the keepalive mechanism to 
>use (remember PING vs STUN?) - but we did also debate the 
>whole primary/secondary/backup stuff and DNS for that and such 
>for a long time, which we could have avoided by splitting it out.
>

When I looked at the SIP outbound document this redundancy topic also looked
like something that is going too far for me.
Why was it introduced in the first place?  

Ciao
Hannes

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 11 Mar 2009 12:19:41 -0400

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Wednesday, March 11, 2009 11:59 AM
> 

It was there from draft-00 (in fact from the first individual submission).  

If I recall right, there was debate about moving it out, but there was no consensus to do so (there were a few people who held strongly to keeping it in, if I remember right - but that was a long time ago and my memory's not that good).

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Wed, 11 Mar 2009 23:36:07 -0500

On Mar 11, 2009, at 3:13 AM, Pete Cordell wrote:
>
> The e-mail archives are like a trail of bread crumbs recording where  
> we've been.  But once we've criss-crossed a few times, and back  
> tracked it gets hard to work out where we've been from those bread  
> crumbs.  If we could occasionally put in some big arrows I think it  
> would help.
>

I could start carrying a crossbow to meetings. If we put a few arrows  
in people who bring up old topics, it might help keep said topics from  
coming back up.

But it probably wouldn't make the specifications any more implementable.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 11 Mar 2009 23:39:13 -0500

On Mar 11, 2009, at 11:19 AM, Hadriel Kaplan wrote:

> If I recall right, there was debate about moving it out, but there  
> was no consensus to do so (there were a few people who held strongly  
> to keeping it in, if I remember right - but that was a long time ago  
> and my memory's not that good).

It was also put there because some Really Big Operator somewhere  
wanted it, and it was turning up on RFPs all over the place.

For some reason, it was though unacceptable to have an average 30  
minute blackout period for every phone behind a NAT whenever that NAT  
rebooted. I can't see why that would matter, myself, but some people  
seem to want two-nines reliability or even better.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 12 Mar 2009 01:05:52 -0400

> From: Dean Willis [mailto:[email-masked]]
> Sent: Thursday, March 12, 2009 12:39 AM
> To: Hadriel Kaplan
> 

That issue was solved years ago, without requiring outbound.  In fact the means by which it was solved ended up providing coverage for more failure cases than that.

The morale is: the market has a tendency to find solutions faster than the IETF, when it's possible to do so.  Which in some ways is yet another problem.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Thu, 12 Mar 2009 00:23:50 -0500

On Mar 12, 2009, at 12:05 AM, Hadriel Kaplan wrote:

> That issue was solved years ago, without requiring outbound.  In  
> fact the means by which it was solved ended up providing coverage  
> for more failure cases than that.
>

Perhaps. Although I neglected the "faster than average 30 minute  
before recovery when the massive proxy/softswitch serving tens of  
thousands of subscribers reboots, and oh by the way, what about the  
reregistration storm" aspect of the problem.

Are you seriously saying we should abandon Outbound? If so, let's get  
that discussion going. I'm all in favor of not writing a spec nobody  
needs. But let;s do that on the SIP list.

--
Deam

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 12 Mar 2009 02:24:14 -0400

> Sent: Thursday, March 12, 2009 1:24 AM
> To: Hadriel Kaplan
> 

The "avalanche storm" problem is a fascinating one really.  There are multiple dimensions to it, and I don't know about other folks, but I admit it took at us several real events in the wild until we were able to "solve" it generically. (and sadly to this day some people still haven't turned on the protections or upgraded age-old releases in deployed systems, but eventually they all will) 

The thing is you really have to solve it generically - you can't make assumptions about UA's supporting outbound or following any guidelines, because some just don't. (in fact *many* don't, afaict) 

I put "solve" in quotes, because while the storm problem can be controlled to keep all the equipment happy and return everything to steady-state, the only issue that wasn't solved back then is the rate at which UA's can be registered truly anew, in real catastrophic failures like long-lived power outages to cities/regions.  In other words if all the registrar DB's can only be updated at X UA's per second, then it takes #UA's/X seconds to get all the UA's into the DB's from scratch and get them all service again.  Solutions to that problem are only now getting implemented and deployed, but again without outbound. 

In fact, outbound will not help with the power-outage problem.  It would have helped with some other problems, at the cost of twice the equipment, which not-surprisingly operators didn't want to pay for.  So the market found alternative solutions.

> needs. But let;s do that on the SIP list.

Not at all!  I never said that!  I said that, in hindsight, we should have split out the redundancy stuff from the NAT stuff to get things done faster.  The two were orthogonal issues even from the start, and we all knew it, but people wanted to solve both problems in one go.  Outbound still has value - both because some people may prefer its redundancy model over the alternatives, and because even without the redundancy piece some people may prefer its NAT-traversal mechanism over the alternatives.  I, for one, prefer outbound's NAT traversal mechanism, and its backoff mechanics.  But I don't know what the market will do.  I have no crystal ball.

And I'm only speaking as one vendor among many, and the world is full of different folks with different deployment architectures, many without SBC's or stateful-anything's, etc.  For example I have been conversing with one provider recently that did things in a very different unique way, using homegrown server code, and I think they would like outbound for redundancy and/or NAT traversal and the IETF should definitely provide it.

-hadriel

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 12 Mar 2009 14:24:38 +0100

I did not claim I was fine with the way things are summarised - to often we find out what the concensus decision was when it ends up in the new version of the draft. My claim is that the first port of call to do this in the SIP WG is the document editor.

regards

Keith

> Sent: Tuesday, March 10, 2009 4:22 PM
> To: 'Spencer Dawkins'; 'Mary Barnes'; 'Pete Cordell'; DRAGE,
> Keith (Keith); [email-masked]
> Subject: RE: [RAI] Recording Consensus (was: Back to the
> topic :ReducingDelays)
>
> * It is probably good that we do not formalize every decision
> making process since otherwise we will delay things for ever.
> My example:
> Might be the only way to deal with a difficult group but
> certainly adds huge delays.
>
> * If a document takes 5 years then I believe it is not
> surprising that some of the issues get re-opened because a
> completely new generation of standardization people look at
> it and the world has changed entirely during these years.
>
> * From Mary's and Keith's response I could get the impression
> that things are fine with the way how discussions are
> summarized. Maybe that's not a problem. Don't know -- waiting
> for community feedback.
>
> So, I wonder why some of documents the group cares about
> still have a hard time. To cite the often mentioned examples:
> SIP Outbound, GRUU
>
> It remains difficult to figure out what the main source of
> the problem is and what steps could help to improve the situation.
>
> Ciao
> Hannes
>
> A) We tried to phrase the ECRIT agenda this time in a
> slightly different fashion, see
> http://www.ietf.org/proceedings/09mar/agenda/ecrit.txt
>
> Typically, documents are listed in the agenda and nobody
> really knows in detail what shall be accomplished during the meeting.
>
> B) In updating a document in the IPSECME WG I found the usage
> of the issue tracker by them quite useful. Take a look at it:
> Tschofenig;
> >I may have misunderstood, but where I thought this thread was headed
> >was that topics fizzle off with no resolution, AND THEN
> UN-FIZZLE back
> >into existance at the most inopportune times ("five minutes after
> >requesting publication", etc.)
> >
> >My question (to the group) is whether we think we're really going to
> >treat these posted "conclusions" like they matter. We have a
> tradition
> >that it's never too late to raise technical objections to a
> document. A
> >working group chair might be able to get away with saying, "but we
> >already discussed that and decided X", but I think that is a
> change to
> >our tradition.
> >
> >If we make that change to our tradition, I'd be a lot more excited
> >about formalizing topic conclusions on the mailing list!
> >
> >Thanks,
> >
> >Spencer
> >
> >
> >>> And when I say "write up" I'm not expecting a book on the
> subject.
> >>> In
> >>
> >>> subject line, making threads difficult to follow.  So
> I've changed
> >>> the
> >>
> >>> subject line here!)
> >>>
> >>> Pete
> >>>
> >>> Yes, in SIPPING, in general, the expectation is that the
> editor is
> >>> the
> >>
> >>>> From: [email-masked] [mailto:[email-masked]]
> On Behalf
> >>>> Of
> >>
> >>>> Hannes Tschofenig
> >>>> This is indeed a very good point. In most discussions
> nobody seems
> >>>> to
> >>

---

From: Theo Zourzouvillys <[email-masked]>
Date: Fri, 13 Mar 2009 01:27:39 +0000

> And I'm only speaking as one vendor among many, and the world is full of different folks with different deployment architectures, many without SBC's or stateful-anything's, etc.  For example I have…

i'm actually going to hold a company party when outbound and gruu
finally gets published.  I'm hoping it won't be so close to Christmas
that it'll merge it into the same one :-)

It's a fundamental part (along with GRUU & ICE) of SPs being able to
offer an SBC free network, something i've been aiming toward for the
last 5 years.

We (mostly) have everything ready for devices to start supporting it -
but every vendor i try and cajole into adding support says "hu?
they're not RFCs, well, pffffft to that!  In the editor queue? so?"
even getting the project managers, marketing or sales people in said
vendors drunk only results in agreement they might actually add it one
day, rather than just try to tell me to forget about SBC free networks
and talk to Hadriel instead.

I'd be happy to pull the redundancy out [1] (or put in a separate
doc), i'd also be happy to have instance defined separately if it
would speed up other things.  But i'd most certainly not be happy if i
don't get my party sometime soon :/

 ~ Theo

1 - It's perfectly possible to implement multi-site redundancy without
a UA supporting it.  yes - even over TLS when the client is behind
NAT.  It just means you can't pick-n-mix your edge vendors and might
have to "homegrow" your server code ;)