Subject: [ippm] draft-morton-ippm-rfc4148-obsolete-02: individual submission -> WG document?

From: <[email-masked]>
Date: Tue, 11 Jan 2011 23:17:40 +0100

Hi

I think that there is a misunderstanding. 

Henk considers that there is no formal requirement to have draft-morton-ippm-rfc4148-obsolete to be a WG document.
Lars says that draft-morton-ippm-rfc4148-obsolete is a WG document which was not renamed.

IMO, it is preferable to accept the I-D as a WG doc and do a WGLC on the WG doc again.

Regards
Emile

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Lars Eggert
Envoyé : mardi 11 janvier 2011 09:43
À : Tools Team Discussion; [email-masked] Development
Objet : [Tools-discuss] individual submission -> WG document?

Hi,

again, related to draft-morton-ippm-rfc4148-obsolete: This is actually a WG document in IPPM, it just was never renamed to draft-ietf-ippm-...

How can I indicate in the datatracker that it is a WG document? Otherwise, the last call text etc. are wrong.

Lars

--------------------------------------------------------

-----Message d'origine-----
De : Henk Uijterwaal [mailto:[email-masked]] 
Envoyé : lundi 3 janvier 2011 10:40
À : STEPHAN Emile RD-CORE-LAN
Cc : [email-masked]
Objet : Re: [ippm] WGLC for draft-morton-ippm-rfc4148-obsolete-02

Hi Emile,

> The RFC4148 should not be obsoleted until the IPPM WG proposes a replacement to
> the current registry.

I disagree.  Over the last 6 months, we failed to identify any users for the
current registry or a group of people interested in working on a replacement
(and with sufficient critical mass to ensure progress).  That says to me that
there is no need for this.

> Furthermore it can hardly be obsoleted before the publication of the RFC of the
> spatial composition.

I disagree again.  The registry will be frozen in the state that it has on
the day the document is published, metrics published before that day will
be in the registy, anything published after that day won't.

> To sum up I consider that the IPPM WGis going to fast on this point:
> 
> -      The first step should be to accept the
> I-D draft-morton-ippm-rfc4148-obsolete as aIPPM WG document.

There is no formal requirement for this.

I consider this matter closed, if you don't agree, feel free to appeal
this decision.

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.xs4all.nl/~henku
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

I confirm today what I denied yesterday.            Anonymous Politician.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 12 Jan 2011 09:26:11 +0200

Hi,

> IMO, it is preferable to accept the I-D as a WG doc and do a WGLC on the WG doc again.

OK, I surely am confused. Is draft-morton-ippm-rfc4148-obsolete *not* an IPPM document?

I mean, we had a WG last call on it and Henk sent me a publication request as WG chair. We don't need to do any of this for an individual document submission.

Lars

---

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 12 Jan 2011 08:23:03 +0100

All,

> Henk considers that there is no formal requirement to
> have draft-morton-ippm-rfc4148-obsolete to be a WG document.
> 

> WGLC on the WG doc again.

Not quite.  I said that draft-morton-... is a document which was never
renamed to draft-ietf-ippm-... but was nevertheless accepted by the WG.
As we have to do a couple of editorial changes anyway, would the problem
be solved if the next iteration was submitted as draft-ietf-ippm-...?

As it is right now, I fail to see what an approval round and second WGLC
would accomplish.

Henk

---

From: Lars Eggert <[email-masked]>
Date: Wed, 12 Jan 2011 10:27:12 +0200

On 2011-1-12, at 9:23, Henk Uijterwaal wrote:
> draft-morton-... is a document which was never

That's what I thought. Thanks for clarifying.

Lars