Subject: [Idr] comment on draft-ietf-idr-as4bytes-10.txt

From: Paul Jakma <[email-masked]>
Date: Fri, 19 Aug 2005 14:44:42 +0100 (IST)

Hi,

Some comments regarding your draft-ietf-idr-as4bytes-10.txt text:

I am curious why you chose to overload the syntax of the existing 
AS_PATH attribute according to whether two peers are or are not 4byte 
ASN capable?

My primary concern of this aspect of the draft is that it will become 
impossible to parse AS_PATH without external reference. This would 
have implications for protocol analysers which are asked to observe a 
BGP session in mid-flow (they'll have no way of parsing AS_PATH) and 
also for 'old' analysers which are asked to observe a session between 
new peers (at best, such an analyser would produce syntactically 
incorrect results), as well as implications for modularity of code in 
BGP implementations.

Would it maybe be better to leave the syntax of AS_PATH alone and 
simply mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH for 
2byte (you could even make AS_PATH optional and NEW_AS_PATH 
well-known between new speakers, so that AS_PATH slowly dies out 
during the transition period)?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Nearly every complex solution to a programming problem that I
have looked at carefully has turned out to be wrong.
 		-- Brent Welch

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Russ White <[email-masked]>
Date: Fri, 19 Aug 2005 11:22:56 -0400

Another option is to store the path in extended communities, as in 
draft-ward...

:-)

Russ

Paul Jakma wrote:
> impossible to parse AS_PATH without external reference. This would have 
> implications for protocol analysers which are asked to observe a BGP 
> session in mid-flow (they'll have no way of parsing AS_PATH) and also 
> for 'old' analysers which are asked to observe a session between new 
> peers (at best, such an analyser would produce syntactically incorrect 
> results), as well as implications for modularity of code in BGP 
> implementations.
> 
> Would it maybe be better to leave the syntax of AS_PATH alone and simply 
> mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH for 2byte (you 
> could even make AS_PATH optional and NEW_AS_PATH well-known between new 
> speakers, so that AS_PATH slowly dies out during the transition period)?
> 
> regards,

- -- 
[email-masked] CCIE <>< Grace Alone

---

From: Russ White <[email-masked]>
Date: Fri, 19 Aug 2005 11:54:41 -0400

Never mind, that draft didn't ever get published....

:-)

Russ

Russ White wrote:
>> simply mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH for 2byte 
>> (you could even make AS_PATH optional and NEW_AS_PATH well-known 
>> between new speakers, so that AS_PATH slowly dies out during the 
>> transition period)?
>>
>> regards,
> 
> 

- --

---

From: Enke Chen <[email-masked]>
Date: Fri, 19 Aug 2005 10:33:52 -0700

Hi, Paul:

Thanks for your comments. My comments are inlined.

> incorrect results), as well as implications for modularity of code in 

These protocol analysis tools need to be augmented to support the 4-byte 
AS numbers regardless. Without the knowledge of whether the 4-byte AS 
capability is supported over a session,  there are a couple of options 
for the tools:

     o introduce a button/knob to allow a user to specify whether the 
session is doing 4-byte or 2-byte.
     o or parse the AS_PATH using 2-byte encoding first, if there is an 
error, parse it using the 4-byte encoding (this may not be as robust as 
the previous one).

> between new speakers, so that AS_PATH slowly dies out during the 

One of the consideration was to avoid mandating another attribute.  Also 
it seems to be more consistent to use the AS_PATH attribute across the 
board.

Regards,

-- Enke

---

From: Paul Jakma <[email-masked]>
Date: Fri, 19 Aug 2005 18:47:10 +0100 (IST)

On Fri, 19 Aug 2005, Enke Chen wrote:

> These protocol analysis tools need to be augmented to support the 
> 4-byte AS numbers regardless.

Yes they would indeed. But by overloading AS_PATH you turn the case 
of an old analyser showing syntactically correct values, eg:

 	AS_PATH <AS_TRANS>

or simply not finding an AS_PATH at all if it isn't there, into it 
showing complete gibberish.

Then there is the second issue, which would affect both 'new' and 
'old' analysers, which is that it will be impossible to analyse a BGP 
stream and be able to reliably interpret AS_PATH without having 
observed the OPEN. Because the only time the information as to which 
kind of overloaded AS_PATH is being sent is present on the wire will 
be at OPEN.

This would be an issue during the transition period particularly, 
where there would be no safe default assumption one could make of 
what size ASN's are used in an AS_PATH.

> Without the knowledge of whether the 4-byte AS capability is 
> supported over a session, there are a couple of options for the 
> tools:

>    o introduce a button/knob to allow a user to specify whether the session 
> is doing 4-byte or 2-byte.
>    o or parse the AS_PATH using 2-byte encoding first, if there is an error, 
> parse it using the 4-byte encoding (this may not be as robust as the previous 
> one).

Not sure either of these are ideal. I'd concur that latter could not 
be done reliably: I'm reasonably sure you could construct a byte 
stream which, syntactically, would be both a valid 2 and 4 byte 
AS_PATH.

> One of the consideration was to avoid mandating another attribute.

But the draft must anyway, NEW_AS_PATH. So given it can not be 
avoided, let's use it properly :).

> Also it seems to be more consistent to use the AS_PATH attribute 
> across the board.

I'd say it's more consistent to *not* overload the on-wire syntax of 
an existing attribute (particularly not according to a once-off 
capability negotation), and just use the old for 2byte and the new 
for 4byte.

Indeed, add a 'ASN bytes' field to the NEW_AS_PATH so we never, ever, 
ever, have to worry about sizeof (ASN) again ;).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
You've been telling me to relax all the way here, and now you're telling
me just to be myself?
 		-- The Return of the Secaucus Seven

---

From: Enke Chen <[email-masked]>
Date: Sun, 21 Aug 2005 22:00:03 -0700

Hi, Paul:

One general comment first: The 4-byte AS scheme was spec'ed in 2001 
after several design iterations (particular on transition). The spec has 
been stable for more than four years.  As I understand, there have been 
more than one implementations, and some have been deployed for years.  
As of last IETF, the implementation report is already under way.  At 
this stage the issue you pointed out on using old  tools over  4-byte  
peers does not seem to be significant enough for us to consider a change 
on the attribute to carry the AS_PATH info. You are 4-5 years too late :-)

On the technical details, I dig up some old notes, and found out that we 
actually discussed the idea of using the AS_PATH attribute between old 
peers, and using of the NEW_AS_PATH attribute between new peers.  The 
scheme would work - however the idea was dropped, and primarily because 
of the following considerations based on my recollection (Yakov, Qv and 
other - please correct me for any inaccuracies):

     o Only one transition. If both the AS_PATH attribute and the 
NEW_AS_PATH were carried, a second transition would be necessary to get 
rid of one of them.
     o Minimize/eliminate duplicate and inconsistent info.  Between the 
new peers if the NEW_AS_PATH were made mandatory, and the AS_PATH 
optional, then we would have to deal with the scenario that both 
attributes are present, and possibly inconsistent.

More comments are inlined.

Paul Jakma wrote:

> Yes they would indeed. But by overloading AS_PATH you turn the case of 
> an old analyser showing syntactically correct values, eg:
>
>     AS_PATH <AS_TRANS>
>

Even if we mandated the use of the NEW_AS_PATH attribute, the old tool 
would still not work for new peers (that is, would not produce correct 
result) as the AS_PATH attribute would not exist and would be flagged as 
a fatal error.  (Assuming that AS_PATH and NEW_AS_PATH would not be 
carried at the same time for the purpose of avoiding a second transition.)

> where there would be no safe default assumption one could make of what 
> size ASN's are used in an AS_PATH.

It is not clear to me if there is an issue here: old tools would 
continue to work for old sessions, and the tools need to be updated to 
analyze new peers anyway.

>> supported over a session, there are a couple of options for the tools:
>
>
>> error, parse it using the 4-byte encoding (this may not be as robust 
>> as the previous one).
>
>
> stream which, syntactically, would be both a valid 2 and 4 byte AS_PATH.

The first approach seems to be very reasonable, and should be simple to do.

> capability negotation), and just use the old for 2byte and the new for 
> 4byte.
>

Another consideration was to minimize changes to the protocol.

BTW, Geoff Huston has recently written a nice article on the AS number, 
which includes some discussions on various alternatives. Here is a pointer:

     http://www.potaroo.net/ispcol/2005-08/as.html

Regards,

-- Enke

---

From: Tulip Rasputin <[email-masked]>
Date: Mon, 22 Aug 2005 01:22:07 -0400 (EDT)

> on the attribute to carry the AS_PATH info. You are 4-5 years too late :-)

Strange. 

If this is the case, then why do we still have such 'drafts' for which we're too late to comment
on still in the "draft" stage and hanging off the IDR WG shelf for review?

Why dont we take them off and publish 'em as RFCs and standards?

Tulip

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: Enke Chen <[email-masked]>
Date: Sun, 21 Aug 2005 22:26:18 -0700

>on still in the "draft" stage and hanging off the IDR WG shelf for review?

I did not say "too late for comment".  It is just too late to change 
encoding.

>Why dont we take them off and publish 'em as RFCs and standards?

That was the plan, and should happen soon.

-- Enke

---

From: Paul Jakma <[email-masked]>
Date: Mon, 22 Aug 2005 13:33:28 +0100 (IST)

On Sun, 21 Aug 2005, Enke Chen wrote:

> after several design iterations (particular on transition). The 
> spec has been stable for more than four years.  As I understand, 
> there have been more than one implementations, and some have been 
> deployed for years.

As I understand it, there's one implementation I've heard mentioned 
by name (at the GRO WG), and there's a possible second 
implementation, which I've not heard anyone mention by name. Indeed, 
at GRO (i think), Bill Fenner was only aware of one implementation. 
But by time of IDR WG, people seemed to know of two.

I am intending to add a 3rd implementation (Quagga), but it was in 
starting to do so that I ran into the 'external reference' problem: 
You have to push knowledge of peer capabilities all the way down into 
your AS_PATH parsing code (which is slightly icky).

Now, /my/ as-path parsing is icky too, so i have to go clean it up. 
And I'd really much much rather key the decision whether to parse 
with 2 or 4 byte ASNs with information local to the attribute (ie the 
attribute type).

> As of last IETF, the implementation report is already under way.

I must have missed that. What I heard at the last IETF was "we need 
implementations".

> At this stage the issue you pointed out on using old tools over 
> 4-byte peers does not seem to be significant enough for us to 
> consider a change on the attribute to carry the AS_PATH info. You 
> are 4-5 years too late :-)

That's a shame.

> On the technical details, I dig up some old notes, and found out 
> that we actually discussed the idea of using the AS_PATH attribute 
> between old peers, and using of the NEW_AS_PATH attribute between 
> new peers.  The scheme would work - however the idea was dropped, 
> and primarily because of the following considerations based on my 
> recollection (Yakov, Qv and other - please correct me for any 
> inaccuracies):
>
>    o Only one transition. If both the AS_PATH attribute and the NEW_AS_PATH 
> were carried, a second transition would be necessary to get rid of one of 
> them.

There will always be two transitions, you can't avoid it.

NEW -> OLD: You'll have to check AS_PATH isn't 4byte, and rewrite it
OLD -> NEW:
 	- NEW_AS_PATH present: Cross-check with AS_PATH and 'merge'
 		               to get full path information

>    o Minimize/eliminate duplicate and inconsistent info.  Between the new 
> peers if the NEW_AS_PATH were made mandatory, and the AS_PATH optional, then 
> we would have to deal with the scenario that both attributes are present, and 
> possibly inconsistent.

You already have this scenario with OLD->NEW peers in the current 
draft though. For OLD->NEW you must deal with it. For NEW->NEW (if 
NEW is mandatory and AS_PATH is discretionary) you can simply 
cross-check and it can be an error condition (for that UPDATE anyway) 
for them to not be consistent.

However, the only reason I can think of for NEW peers to originate 
AS_PATH (if the draft specified NEW_AS_PATH between NEW always) would 
be if some kind of per-peer AS_PATH signature solution were deployed. 
Hence they should be capable of it, but it should not be the default 
imho.

Essentially, yes: there's extra work to do - during the transition 
period. And within the NEW world there'd simply be /no/ need for 
AS_PATH. The only reason to originate it to NEW peers would be to 
allow, eg, S-BGP to be deployed in an OLD and NEW world.

> Even if we mandated the use of the NEW_AS_PATH attribute, the old 
> tool would still not work for new peers (that is, would not produce 
> correct result) as the AS_PATH attribute would not exist and would 
> be flagged as a fatal error. (Assuming that AS_PATH and NEW_AS_PATH 
> would not be carried at the same time for the purpose of avoiding a 
> second transition.)

The old tool will still produce syntactically correct results if 
AS_PATH is present though between NEW peers and not overloaded. If it 
isn't present, the tool won't try parse it.

However, if AS_PATH syntax is overloaded as in the current draft, the 
tool will, in the best case, produce an error or pure garbage.

> continue to work for old sessions, and the tools need to be updated 
> to analyze new peers anyway.

Yes, they need to be updated anyway. If you overload AS_PATH they 
*definitely* need to be updated. Even if updated, the tool will have 
no way to reliably tell whether AS_PATH is 2 or 4 bytes, unless it 
captured the OPEN.

And this isn't just about tools, it's about modularity too. It simply 
will be impossible to decode an AS_PATH attribute without having the 
context of a peer (and its capabilities particularly).

> The first approach seems to be very reasonable, and should be 

It still causes 'OLD' analysers to either produce utter gibberish or 
worse, crash - that could be an issue for IDS' btw, though one hopes 
an IDS would be robust. If you don't overload AS_PATH, then all 
existing BGP decoding software will simply continue to work. It may 
not give you a full picture anymore, becase BGP has been extended, 
but it will still give you semantically correct results.

> Another consideration was to minimize changes to the protocol.

And redefining the syntax of an existing and well-known attribute 
constitutes a 'minimal change'? As opposed to extending BGP with a 
new attribute (which you must introduce anyway for the transition 
period) and deprecating the existing attribute.

> BTW, Geoff Huston has recently written a nice article on the AS number, which 
> includes some discussions on various alternatives. Here is a pointer:
>

Aye, saw it. Very interesting and good article.

So it's impossible to change this draft then?

A real shame, as I don't really see any difference between 
overloading AS_PATH or using NEW_AS_PATH other than that latter 
doesn't have the unfortunate property of making AS_PATH unparseable 
without external reference.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Whistler's Law:
 	You never know who is right, but you always know who is in charge.

---

From: Paul Jakma <[email-masked]>
Date: Mon, 22 Aug 2005 14:19:31 +0100 (IST)

> 		               to get full path information

To clarify: The above is how the current draft specifies things.

I would propose:

NEW -> OLD: synthesise AS_PATH if required (or add your ASN as
             normal)
NEW <- OLD: 'merge' NEW_AS_PATH if present, as current draft
 	    specifies

NEW -> NEW:
 	Originate:
 		- NEW_AS_PATH contains canonical path information
 		- AS_PATH is optional, prefered to not include it
 	  	  implementation /MAY/ originate it (eg because some
 		  kind of secure BGP may be deployed which requires
 	          AS_PATH to be maintained, while OLD world still
 	          exists)
 	Pass on:
 		- NEW_AS_PATH -> add yourself to path
 		- AS_PATH (if present only) -> add your mapped ASN to path

NEW <- NEW: NEW_AS_PATH mandatory, AS_PATH discretionary
 	- NEW_AS_PATH is loop checked, it is the canonical
 	  information
 	- AS_PATH is checked for consistency with NEW_AS_PATH
 	  (taking mapping into account)
 	  if not consistent: Invalid UPDATE, ignore

So during the transition period we would see both attributes, and 
we'd have to do extra work at the boundaries between OLD and NEW.

Eventually, when everyone is NEW, the only thing we should see is 
NEW_AS_PATH (and NEW_AGGREGATOR).

Ancillary BGP tools continue to work during transition, whether they 
know of NEW_AS_PATH or not. None will produce garbage, none will need 
user-specified knobs in order to decide how to parse *_PATH 
information, they can use the attribute type code as is normal in 
parsing attributes.

> software will simply continue to work. It may not give you a full picture 
> anymore, becase BGP has been extended, but it will still give you 
> semantically correct results.

Syntactically even. And the semantics also stand a chance of coming 
across (eg AS_PATH between NEW->OLD or OLD-OLD would have full 
hop-count information, even if NEW_AS_PATH is present. The path 
itself may be semantically correct, particularly if there are no 
AS_TRANS numbers in it, and even then a human can still recognise 
AS_TRANS for what it is).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
A citizen of America will cross the ocean to fight for democracy, but
won't cross the street to vote in a national election.
 		-- Bill Vaughan

---

From: Paul Jakma <[email-masked]>
Date: Mon, 22 Aug 2005 15:53:28 +0100 (IST)

Hi Enke,

See:

 	http://hibernia.jakma.org/~paul/as4bytes.diff

for the changes I would like to see made to the draft.

(For full version see: 
http://hibernia.jakma.org/~paul/draft-ietf-idr-as4bytes-11.txt)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Everything can be filed under "miscellaneous".

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 22 Aug 2005 13:58:46 -0400

In message <[email-masked]>
Tulip Rasputin writes:
> If this is the case, then why do we still have such 'drafts' for which
> we're too late to comment on still in the "draft" stage and hanging
> off the IDR WG shelf for review?
>  

We got here because IESG refused to advance anything until RFC1771 got
updated.  What we are doing is dusting them drafts off and advancing
them now that the bottleneck (rfc1771 update) has cleared.

Curtis

---

From: Enke Chen <[email-masked]>
Date: Mon, 22 Aug 2005 11:28:00 -0700

Hi, Paul:

Thanks - but I hope it will not be needed :-)

To change the encoding and mandating the NEW_AS_PATH, we would have to 
deprecate and re-allocate all the code points, including 4-byte AS 
Capability, NEW_AS_PATH, and NEW_AGGREGATOR in order to not break 
existing deployments.

Based on our discussion it seems to me that the differences between 
re-using the AS_PATH attribute or the NEW_AS_PATH attribute for new 
peers are mainly the following:  (Let us call the proposals P1 and P2 
respectively)

    1) "standalone" tools:
         P1:  would require a new parameter to parse UPDATES for a new 
session.
                 old tool works for old peers.
                 old tool would generate error in parsing UPDATES for a 
new session.
         
         P2:  no new parameter is needed to parse an UPDATE for a new 
session.
                 old tool works for old peers.
                 old tool flags new update as "fatal error - missing 
AS_PATH", and no useful AS_PATH info.

   2) At the end of transition:

         P1:  possibly reclaim NEW_AS_PATH, NEW_AGGREGATOR.
         P2:  possibly reclaim AS_PATH,  AGGREGATOR.

These differences seem to be minor, and I do not think they are 
compelling enough for us to change the encoding at this late stage.

Regards,

-- Enke

---

From: Paul Jakma <[email-masked]>
Date: Mon, 22 Aug 2005 20:19:03 +0100 (IST)

On Mon, 22 Aug 2005, Enke Chen wrote:

> To change the encoding and mandating the NEW_AS_PATH, we would have 
> to deprecate and re-allocate all the code points, including 4-byte 
> AS Capability, NEW_AS_PATH, and NEW_AGGREGATOR in order to not 
> break existing deployments.

Exactly how many existing non-laboratory deployments are there? :) Do 
I need one or two hands to count them on, if any at all? :)

Breaking drafts, if for a good reason, is quite possible. 
Particularly one marked still with intended status of experimental:

 	https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=6498

or not?

> peers are mainly the following:  (Let us call the proposals P1 and 
> P2 respectively)

>                old tool would generate error in parsing UPDATES for a new 
> session.

That is the "at best" result. Much worse could occur, particularly in 
tools which are not well-designed, from crashes to vulnerabilities 
(far fetched in this case, granted but not impossible).

>                old tool flags new update as "fatal error - missing AS_PATH", 
> and no useful AS_PATH info.

Or just continues on parsing the other attributes. The tool need not 
be attempting to validate the UPDATE.

>        P2:  possibly reclaim AS_PATH,  AGGREGATOR.

I'm not sure how you could reclaim either, least not any time soon. 
But no difference either way, no.

> These differences seem to be minor, and I do not think they are compelling 
> enough for us to change the encoding at this late stage.

Conceptually, it's not minor. Overloading is simply quite ugly. It is 
going to be a stain on the BGP protocol for as long as the version == 
4. As a matter of practicality, it's likely not going to make any 
difference to common BGP speakers, agreed, but it is going to have an 
effect on tools and their users ("So, exactly what am I supposed to 
do with that ASN-size knob again?").

So I'd say this depends on existing implementation and deployment. 
And a month ago at GRO there was only one known /implementation/. ;)

If there are no deployments, it is quite possible to address this 
matter. It's A very small nit in a way yes, but it's still easy to 
polish out at this stage, so why not?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
"Bye, witches! Thanks for not eating me!"

 	--Ralph Wiggum
 	  Treehouse of Horror VIII (Episode 5F02)

---

From: Enke Chen <[email-masked]>
Date: Mon, 22 Aug 2005 12:34:09 -0700

Paul Jakma wrote:

>> to deprecate and re-allocate all the code points, including 4-byte AS 

You will be surprised. AFAIK there are at least hundreds of routers in 
the field that supports the 4-byte AS.

Just FYI - There are at least two implementations, and the 
implementation report is being worked on (see the IDR WG minutes).

Regards,

-- Enke

---

From: Paul Jakma <[email-masked]>
Date: Mon, 22 Aug 2005 20:49:04 +0100 (IST)

On Mon, 22 Aug 2005, Enke Chen wrote:

> You will be surprised. AFAIK there are at least hundreds of routers 
> in the field that supports the 4-byte AS.

Ah, by far more than I would have thought. However, still 
insignificant to the number of routers which still need to be 
upgraded to support this draft. ;)

> Just FYI - There are at least two implementations, and the implementation 
> report is being worked on (see the IDR WG minutes).

Ok, well, if you have a look at the changes I suggested (some of 
which apply to either 'method') there is another consideration, see 
security consideration:

Overloading AS_PATH very likely will be, during a transition period, 
incompatible with any future BGP security specification which 
attempts to attest AS_PATH.

However, if you do not overload AS_PATH, you do still have the 
possibility of having AS_PATH attestation working. (NEW speakers can 
originate and attest to authenticity of both).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
I always turn to the sports pages first, which record people's accomplishments.
The front page has nothing but man's failures.
 		-- Chief Justice Earl Warren

---

From: Bill Fenner <[email-masked]>
Date: Mon, 22 Aug 2005 15:49:35 -0400

>...Particularly one marked still with intended status of experimental:
>

Paul,

  Looks like you found a bug in the I-D Database interface -- as4bytes
doesn't have any intended status recorded, so it seems to have defaulted
to Experimental, but it's indeed intended to be Standards track.

  Bill

---

From: Paul Jakma <[email-masked]>
Date: Mon, 22 Aug 2005 22:19:34 +0100 (IST)

> implementation report is being worked on (see the IDR WG minutes).

Ok, I didn't remember that. But it was there in the doc status 
update.

FWIW, my comments arise directly of out of attempting to implement 
this draft.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Married men should forget their mistakes; there's no use in two people
remembering the same thing!

---

From: "Alok" <[email-masked]>
Date: Mon, 22 Aug 2005 17:52:24 +0530

I wonder why too :-)

Wonder why they have an open WG at all when they do not want to take things
forward

> If this is the case, then why do we still have such 'drafts' for which
we're too late to comment