Subject: Protest: Complexity running rampant

From: Harald Alvestrand <[email-masked]>
Date: Mon, 19 Feb 2007 10:55:28 +0100

My attention has recently been drawn to this set of documents:

- draft-legg-xed-asd
- draft-legg-xed-asd-gserei
- draft-legg-xed-asd-xerei
- draft-legg-xed-rxer
- draft-legg-xed-rxer-ei

It's, as far as I can tell, an attempt at a complete reimplementation of 
ASN.1 using XML.

I was very strongly reminded of a 1992 quip by Marshall Rose:
> ASN.1 is probably the greatest failure of the OSI effort, it led
> hundreds of engineers, including myself, to devise data structures that
> were far too complicated for their own good. 
Now, what has changed in the last 15 years that:

- Makes this complexity valuable, where before it was harmful
- Makes the IETF community the right place to standardize this complexity?

The deadline for comments is theoretically passed:

> The IESG has received a request from an individual submitter to consider
> the following documents:
>
> - 'Abstract Syntax Notation X (ASN.X) Representation of Encoding 
>    Instructions for the XML Encoding Rules (XER) '
>    <draft-legg-xed-asd-xerei-03.txt> as a Proposed Standard
> - 'Encoding Instructions for the Robust XML Encoding Rules (RXER) '
>    <draft-legg-xed-rxer-ei-04.txt> as a Proposed Standard
> - 'Abstract Syntax Notation X (ASN.X) Representation of Encoding 
>    Instructions for the Generic String Encoding Rules (GSER) '
>    <draft-legg-xed-asd-gserei-03.txt> as a Proposed Standard
> - 'Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One 
>    (ASN.1) '
>    <draft-legg-xed-rxer-07.txt> as a Proposed Standard
> - 'Abstract Syntax Notation X (ASN.X) '
>    <draft-legg-xed-asd-07.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2007-02-14. Exceptionally, 
> comments may be sent to [email-masked] instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-legg-xed-asd-xerei-03.txt
> http://www.ietf.org/internet-drafts/draft-legg-xed-rxer-ei-04.txt
> http://www.ietf.org/internet-drafts/draft-legg-xed-asd-gserei-03.txt
> http://www.ietf.org/internet-drafts/draft-legg-xed-rxer-07.txt
> http://www.ietf.org/internet-drafts/draft-legg-xed-asd-07.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=10739&rfc_flag=0
>
>
>   
But it is not yet approved by the IESG, so it's not too late to comment.

Let the arguments begin...

                 Harald

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

on, 19 Feb 2007 10:51:14 +0100 (CET)
Date: Mon, 19 Feb 2007 10:55:28 +0100
From: Harald Alvestrand <[email-masked]>
To: [email-masked]
Subject: Protest: Complexity running rampant

My attention has recently been drawn to this set of documents:

- draft-legg-xed-asd
- draft-legg-xed-asd-gserei
- draft-legg-xed-asd-xerei
- draft-legg-xed-rxer
- draft-legg-xed-rxer-ei

It's, as far as I can tell, an attempt at a complete reimplementation of 
ASN.1 using XML.

I was very strongly reminded of a 1992 quip by Marshall Rose:
> ASN.1 is probably the greatest failure of the OSI effort, it led
> hundreds of engineers, including myself, to devise data structures that
> were far too complicated for their own good. 
Now, what has changed in the last 15 years that:

- Makes this complexity valuable, where before it was harmful
- Makes the IETF community the right place to standardize this complexity?

The deadline for comments is theoretically passed:

> The IESG has received a request from an individual submitter to consider
> the following documents:
>
> - 'Abstract Syntax Notation X (ASN.X) Representation of Encoding 
>    Instructions for the XML Encoding Rules (XER) '
>    <draft-legg-xed-asd-xerei-03.txt> as a Proposed Standard
> - 'Encoding Instructions for the Robust XML Encoding Rules (RXER) '
>    <draft-legg-xed-rxer-ei-04.txt> as a Proposed Standard
> - 'Abstract Syntax Notation X (ASN.X) Representation of Encoding 
>    Instructions for the Generic String Encoding Rules (GSER) '
>    <draft-legg-xed-asd-gserei-03.txt> as a Proposed Standard
> - 'Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One 
>    (ASN.1) '
>    <draft-legg-xed-rxer-07.txt> as a Proposed Standard
> - 'Abstract Syntax Notation X (ASN.X) '
>    <draft-legg-xed-asd-07.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2007-02-14. Exceptionally, 
> comments may be sent to [email-masked] instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-legg-xed-asd-xerei-03.txt
> http://www.ietf.org/internet-drafts/draft-legg-xed-rxer-ei-04.txt
> http://www.ietf.org/internet-drafts/draft-legg-xed-asd-gserei-03.txt
> http://www.ietf.org/internet-drafts/draft-legg-xed-rxer-07.txt
> http://www.ietf.org/internet-drafts/draft-legg-xed-asd-07.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=10739&rfc_flag=0
>
>
>   
But it is not yet approved by the IESG, so it's not too late to comment.

Let the arguments begin...

                 Harald

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

---

From: Fred Baker <[email-masked]>
Date: Mon, 19 Feb 2007 02:40:15 -0800

On Feb 19, 2007, at 1:55 AM, Harald Alvestrand wrote:
> It's, as far as I can tell, an attempt at a complete  
> reimplementation of ASN.1 using XML.

Stepping away from the details of the implementation, let me ask what  
the result is? (note that I am not an apps person, and have no skin  
the the game, and therefore am asking a question trying to get to the  
root here)

There are any number of structured data representations around; ASN.1  
and XML are two, and one could consider the structure used in RFC  
2445 as a third example. People have shied away from ASN.1 citing  
complexity. Whatever its warts, XML is pretty readily understood.

Having not read the above and not really caring much what happens in  
the layers up in the stratosphere as long as its designers don't by  
its sheer weight make the application unusable, is it a bad thing to  
provide the expressive nature of ASN.1 in a human-readable and  
popular data representation?

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 19 Feb 2007 11:45:22 +0100

--On 19. februar 2007 02:40 -0800 Fred Baker <[email-masked]> wrote:

> Stepping away from the details of the implementation, let me ask what the
> result is? (note that I am not an apps person, and have no skin the the
> game, and therefore am asking a question trying to get to the root here)
>
> There are any number of structured data representations around; ASN.1 and
> XML are two, and one could consider the structure used in RFC 2445 as a
> third example. People have shied away from ASN.1 citing complexity.
> Whatever its warts, XML is pretty readily understood.

I'd challenge that.... but there is experience that people are using XML 
successfully in applications. So I guess XML has proven itself.

> Having not read the above and not really caring much what happens in the
> layers up in the stratosphere as long as its designers don't by its sheer
> weight make the application unusable, is it a bad thing to provide the
> expressive nature of ASN.1 in a human-readable and popular data
> representation?

With the "expressive nature of ASN.1" comes every single piece of the 
complexity of ASN.1 that people have shied away from. And to this 
complexity, there is added the complexity of XML.

I have nothing against such things being published. Let foolishness fail on 
its own.

I have significant issues with using IETF cycles on developing and (not 
least) maintaining such a complex beast.

              Harald

---

From: John C Klensin <[email-masked]>
Date: Mon, 19 Feb 2007 09:49:02 -0500

--On Monday, February 19, 2007 11:45 +0100 Harald Tveit 
Alvestrand <[email-masked]> wrote:

>> Having not read the above and not really caring much what
>> happens in the layers up in the stratosphere as long as its
>> designers don't by its sheer weight make the application
>> unusable, is it a bad thing to provide the expressive nature
>> of ASN.1 in a human-readable and popular data representation?
>
> With the "expressive nature of ASN.1" comes every single piece
> of the complexity of ASN.1 that people have shied away from.
> And to this complexity, there is added the complexity of XML.
>
> I have nothing against such things being published. Let
> foolishness fail on its own.
>
> I have significant issues with using IETF cycles on developing
> and (not least) maintaining such a complex beast.

Let me add an observation to Harald's...

(1) "More options" is rarely A Good Thing for the Internet. 
This is something of a marginal case in terms of how strongly 
that principle applies because it presumably does not involve 
multiple options within the same protocol.  It does, however, 
imply less code reuse and more work in other respects.   While 
XML is probably easier to read than ASN.1, much of the ASN.1 
complexity involves understanding and working with the model. 
As far as I can tell from skimming these documents, that 
requirement doesn't change here: this is just a syntax 
translation of ASN.1 into XML.  IMO, for standards-track, there 
should be a stronger demonstration of why this is needed -- and 
enough better than the alternatives -- to justify an additional 
option.

In addition, while it may be just a personal bias, I  believe 
that, in this century, if we are going to standardize another 
one of these, we should be looking at something that can express 
semantics (not just syntax, however elaborate) in a clear way. 
If that method uses an XML or XML-like syntax, so much the 
better.  But this doesn't seem to me to add enough value to 
clutter the standards-track landscape.

For the record, I would have no problems with Informational or 
Experimental publication of this collection -- it is the 
proposed decision to standardize that bothers me.

     john

---

From: "Tim Bray" <[email-masked]>
Date: Mon, 19 Feb 2007 09:15:35 -0800

> proposed decision to standardize that bothers me.

Exactly.   Under no circumstances should it ever be OK to use IETF
reputational leverage to pressure someone to use something as (to be
charitable) unproven as this.

 -Tim

---

From: Dave Crocker <[email-masked]>
Date: Mon, 19 Feb 2007 10:49:29 -0800

Fred Baker wrote:
>  is it a bad thing to provide
> the expressive nature of ASN.1 in a human-readable and popular data 
> representation?

The one thing IETF standardization certainly ought to imply is that there is a 
real constituency interesting in using the specification in the near-term.

Who wants to use this spec, now, and why?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Bob Braden <[email-masked]>
Date: Mon, 19 Feb 2007 11:30:22 -0800

>
>The one thing IETF standardization certainly ought to imply is that there 
>is a real constituency interesting in using the specification in the near-term.

Dave,

Why is "near term" an essential requirement?  If the Internet designers had 
opted for the
"near term", we would all be running some flavor of X.25 today.

Bob Braden

---

From: Dave Crocker <[email-masked]>
Date: Mon, 19 Feb 2007 14:31:20 -0800

Bob Braden wrote:
> Why is "near term" an essential requirement?  If the Internet designers 
> had opted for the

Research vs. engineering.

Standards are for engineering.  When they don't solve near-term problems they 
tend not to solve any problems at all.

d/

-- 

   Dave Crocker

---

From: Andy Bierman <[email-masked]>
Date: Mon, 19 Feb 2007 20:20:46 -0800

Dave Crocker wrote:
> The one thing IETF standardization certainly ought to imply is that 
> there is a real constituency interesting in using the specification in 
> the near-term.
> 

I almost sent an email asking this question when I read the drafts.
My reaction was "This seems like a lot of stuff to put on the
standards track without being the output of a WG."

I didn't, because I figured there must be some significant
constituency that wants this standardized.  So, is there or not?

> d/

Andy

---

From: Ted Hardie <[email-masked]>
Date: Tue, 20 Feb 2007 10:49:38 -0800

At 9:49 AM -0500 2/19/07, John C Klensin wrote:
>
>For the record, I would have no problems with Informational or Experimental publication of this collection -- it is the proposed decision to standardize that bothers me.

When I first discussed publication of this with the IESG, I pointed out that the
author had asked for Proposed Standard, but I was more likely to support
Informational or Experimental.  At the time, Sam asked that it remain
under consideration for standards track (at least up until the ballot discussion).
One point raised was how easy it would be to reference these as encodings
if they were informational or experimental, but I believe Sam had other
points as well.  Given the ongoing discussion, I asked Russ to Defer this document;
that will give Sam a chance to come back from vacation and enter the discussion,
and all of us a chance to continue it.  My current take-away from the discussion
is that the broader community would prefer we start with Informational or
Experimental and consider the need to deal with downrefs as signals that this
has sufficient constituencies to need standardization.

Another point made in private was that many of the reviewers of this document
to date have been familiar enough with ASN.1 that those aspects of this encoding
were not surprising or difficult; that may be why the model issues were not
raised earlier.  I'm happy that in the case the Last Call discussion has raised the
point, and if Russ's defer does not give us enough time to terminate the discussion,
I'll withdraw the document.  If we can conclude on a community recommendation
(e.g. for Informational or Experimental) before that, though, it would be nice
for my successor, who will otherwise need to take these on.

			regards,
				Ted