Subject: Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC

From: Pekka Savola <[email-masked]>
Date: Tue, 13 Mar 2007 07:47:59 +0200 (EET)

On Mon, 12 Mar 2007, The IESG wrote:
> A URL of this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-legg-xed-asd-07.txt
...
> Working Group Summary
>
> This document set was not produced by an IETF working group, but by an
> individual.  IETF Last Call produced no comments, and solicited reviewers
> were basically positive.

This writeup was not updated or comments were not duly processed.  I 
see 14 Last Call comments (retaining the subject line) on 
[email-masked], as well as 12 comments under the 'Protest: Complexity 
running rampant' thread.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

---

From: John C Klensin <[email-masked]>
Date: Tue, 13 Mar 2007 09:04:52 -0400

--On Tuesday, 13 March, 2007 07:47 +0200 Pekka Savola
<[email-masked]> wrote:

>> This document set was not produced by an IETF working group,
>> but by an individual.  IETF Last Call produced no comments,
>> and solicited reviewers were basically positive.
> 
> This writeup was not updated or comments were not duly
> processed.  I see 14 Last Call comments (retaining the subject
> line) on [email-masked], as well as 12 comments under the
> 'Protest: Complexity running rampant' thread.

Agreed... I was about to send a similar note when I saw this
one. 
I would add  that few of the 14 comments were really positive
about this specification.  In addition, several of the comments
on both threads asked for specific clarification of the need to
introduce the complexities inherent in an additional syntax for
accomplishing the underlying functionality.  The document has
not been modified to reflect those concerns.

If the IESG is going to claim a silent majority in favor of
approving this document, so be it.  But to claim that there were
no Last Call comments and that those that were solicited were
positive is deeply problematic.    It even leads one to wonder
whether the IESG has ignored critical comments in other cases,
but I trust that has not occurred.

    john

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Mar 2007 15:11:20 +0100

I saw almost no technical comments on the documents. Most of
the last call comments I saw were on a side track about
copyright issues.

The one somewhat technical comment that I logged, from Tom Yu,
didn't result in any changes but was certainly influential on
me in agreeing to the documents being reclassified from standards
track to Experimental. This could have been acknowledged in
the writeup, I guess.

     Brian

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 13 Mar 2007 15:54:58 +0100

> [email-masked], as well as 12 comments under the 'Protest: Complexity

Thanks for pointing this out.

I believe the protocol is not possible to implement due to the
copyright issue, because the ASN.1 schema specifically says that the
IETF copying conditions apply to it:

   -- Copyright (C) The IETF Trust (2006). This version of
   -- this ASN.1 module is part of RFC XXXX; see the RFC itself
   -- for full legal notices.

I registered this as last call comment in

http://article.gmane.org/gmane.ietf.general/23684

where I also suggested a way to solve this problem.

I believe the IETF should not specify protocols that require that you
violate a copyright notice to implement.

Further, the copyright notice in the document appears to be both
incorrect and to violate the IETF process.  Typically copyrights on
document text are not transferred to the IETF Trust, and I see no
signs that this happened here.  The notice violates the requirements
set forth by RFC 3978 section 5.4 (as updated by RFC 4748) which says:

5.4.  Copyright Notice (required for all IETF Documents)

   (Normally placed at the end of the IETF Document.)

      "Copyright (C) The IETF Trust (year).

      This document is subject to the rights, licenses and restrictions
      contained in BCP 78, and except as set forth therein, the authors
      retain all their rights."

   Additional copyright notices are not permitted in IETF Documents
...

The notice in the document doesn't match the required notice, and is
thus not permitted under RFC 3978.  Or am I missing something?

I suppose an appeal is one way to bring this up formally, although if
this can be resolved in a better way that would be preferable.

/Simon

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 13 Mar 2007 08:09:35 -0700

I agree that there were no technical comments but the summary states 'no comments'.

Arguments on complexity are too easy to make. Every time a proposal is made I hear the complexity argument used against it. Everything we do is complex. Computers are complex. Committee process usually increases complexity somewhat.

If an argument can always be used what is the discrimination power?

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Tuesday, March 13, 2007 10:11 AM
> To: John C Klensin
> Cc: [email-masked]; Pekka Savola; [email-masked]
> Subject: Re: Document Action: 'Abstract Syntax Notation X 
> (ASN.X)' to Experimental RFC
> 
> The one somewhat technical comment that I logged, from Tom 
> Yu, didn't result in any changes but was certainly 
> influential on me in agreeing to the documents being 
> reclassified from standards track to Experimental. This could 
> have been acknowledged in the writeup, I guess.
> 
>      Brian
> 
> >>> This document set was not produced by an IETF working 
> group, but by 
> >>> an individual.  IETF Last Call produced no comments, and 
> solicited 
> >>> reviewers were basically positive.
> processed.  I 
> >> see 14 Last Call comments (retaining the subject
> > Agreed... I was about to send a similar note when I saw this one.
> > I would add  that few of the 14 comments were really positive about 
> > this specification.  In addition, several of the comments on both 
> > threads asked for specific clarification of the need to 
> introduce the 
> > complexities inherent in an additional syntax for accomplishing the 
> > underlying functionality.  The document has not been modified to 
> > reflect those concerns.
> > 
> approving 
> > this document, so be it.  But to claim that there were no Last Call 
> > comments and that those that were solicited were
> > whether the IESG has ignored critical comments in other 
> cases, but I 
> > trust that has not occurred.
> > 
> >     john
> > 
> >

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 13 Mar 2007 16:22:31 +0100

On Tue, Mar 13, 2007 at 08:09:35AM -0700,
 Hallam-Baker, Phillip <[email-masked]> wrote 
 a message of 76 lines which said:

> Everything we do is complex. 

There are degrees in complexity. Compare RFC 3912 with 3981, both
written by your co-workers :-)

So, I do not think that the "complexity argument" should be
dismissed. Sometimes, standards are too complicated and one of the
things I like about IETF protocols, is that they are typically simpler
than standards produced by most other organisations.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 13 Mar 2007 08:47:54 -0700

At 7:47 AM +0200 3/13/07, Pekka Savola wrote:
>This writeup was not updated or comments were not duly processed.  I see 14 Last Call comments (retaining the subject line) on [email-masked], as well as 12 comments under the 'Protest: Complexity running rampant' thread.

You are correct; sorry about that.  The Last call commentscame in quite
late, and I simply forgot to update the write-up after the discussion took place. 
The result of those was the updated status, to experimental (rather
than standards track), so they were heard; I just didn't track them correctly
into the write-up.  Again, my apologies,
			regards,
				Ted Hardie

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 13 Mar 2007 16:58:47 +0100

"Hallam-Baker, Phillip" <[email-masked]> writes:

> Arguments on complexity are too easy to make. Every time a proposal
> is made I hear the complexity argument used against it. Everything
> we do is complex. Computers are complex. Committee process usually
> increases complexity somewhat.
>

How about using answers to the question "Is this complexity needed?"
as a discriminator?

Sometimes, there is no better solution than one with certain
complexity.  That isn't inherently bad.

I'm not sure the need for this particular complex solution was
demonstrated.  I don't recall anyone defending it.  The experimental
track thus seems appropriate, if it should be published at all.

/Simon

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 13 Mar 2007 09:09:57 -0700

> From: Simon Josefsson [mailto:[email-masked]] 
> > Arguments on complexity are too easy to make. Every time a 
> proposal is 
> > made I hear the complexity argument used against it. 
> Everything we do 
> > is complex. Computers are complex. Committee process 
> usually increases 
> > complexity somewhat.
> >
> I'm not sure the need for this particular complex solution 
> was demonstrated.  I don't recall anyone defending it.  The 
> experimental track thus seems appropriate, if it should be 
> published at all.

Define 'need'.

Define 'complexity'.

>From my point of view a device that has two parser stacks on it is more complex than a device that can do it all with a single stack. Thus translating SNMP into XML makes excellent sense and reduces complexity overall.

I don't think it makes sense to translate every ASN.1 protocol into XML, particularly if there is an XML infrastructure for the purpose. But I would certainly prefer to be able to support SNMP on an XML centric device without having to provide an ASN.1 stack. Further I would like there to be consistency in the way that SNMP/XML and LDAP/XML to map to the traditional ASN.1 versions.

It's a legitimate architectural approach and the IETF should not take sides against it.

---

From: Tom Yu <[email-masked]>
Date: Tue, 13 Mar 2007 14:56:55 -0400

>>>>> "pbaker" == Hallam-Baker, Phillip <[email-masked]> writes:

pbaker> I agree that there were no technical comments but the summary
pbaker> states 'no comments'.  Arguments on complexity are too easy to
pbaker> make. Every time a proposal is made I hear the complexity
pbaker> argument used against it. Everything we do is
pbaker> complex. Computers are complex. Committee process usually
pbaker> increases complexity somewhat.

pbaker> If an argument can always be used what is the discrimination power?

I find that it's not useful to consider complexity as an abstract
concept in this context.  The world is complex.  What is important is
how we manage that complexity.  I think that it is much more useful to
evaluate complexity from a functional perspective.

More later.

---Tom

---

From: John C Klensin <[email-masked]>
Date: Tue, 13 Mar 2007 18:13:10 -0400

--On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson
<[email-masked]> wrote:

>> proposal is made I hear the complexity argument used against
>> it. Everything we do is complex. Computers are complex.
>> Committee process usually increases complexity somewhat.
>> 
> How about using answers to the question "Is this complexity
> needed?" as a discriminator?
> 
> demonstrated.  I don't recall anyone defending it.  The

But that was precisely where the other thread, if I recall, came
out.  It wasn't an argument against complexity.  It was an
argument about introducing another optional way of doing things
because we _know_ that many options lead to worse
interoperability.  And it was a suggestion/ request that, before
this document was published in _any_ form, that it at least
acquire a clear discussion as to when one would select this form
over the well-established ASN.1 form for which there is existing
deployment, existing tools, etc.  Put differently, we all know
that this _can_ be done but, if there is another solution
already out there, widely deployed, and in active use, a clear
explanation about _why_ it should be done and under what
circumstances it is expected to useful is in order.

That suggestion about an explanation was a specific request
about the document, not idle theorizing about the character of
ASN.1 or the nature of complexity.

And, again, pretending that the discussion didn't occur
impresses me as a little strange.

     john

---

From: Andy Bierman <[email-masked]>
Date: Tue, 13 Mar 2007 16:01:35 -0700

> impresses me as a little strange.

I was going to raise this issue, but I deleted the mail when I realized
this is going to be an Experimental RFC (according to the subject line).

I don't think it harms interoperability to introduce an experiment
into the mix.  If deployment and useful tools follow, then maybe
a later revision can move to the standards track.

>      john

Andy

---

From: Ned Freed <[email-masked]>
Date: Tue, 13 Mar 2007 16:13:11 -0700 (PDT)

> interoperability.

Yes, and I thought I sent in a note saying I supported this view but I cannot
find it. I also strongly opposed standards-track publication and think
experimental is a far better choice.

> And it was a suggestion/ request that, before
> deployment, existing tools, etc.

This suggestion was at the very least strongly implicit in the earlier
discussion.

It also occurs to me that what may be needed here is a BCP on how to best use
ASN.1. We have such a BCP on XML. ASN.1 is similarly complex and similarly
decorated with features, so it makes sense to me that if we're going to
continue to use it why not have a document discussing what features make sense
and what ones don't. (For example, some sage advice on when and how to use
EXTERNAL could have made several protocols a lot more tractable.)

> Put differently, we all know

Given how little uptake (AFAIK) there has been of the various encodings for
ASN.1 beyond BER and DER (let's see, there's CER and PER and at least two
others whose names I cannot recall), I'm not especially worried about XER
taking the world by storm. Indeed, I think it would actually help XER's case if
there was some explanation of where and why you'd ever want to use it.

The fact that pigs can be made to fly with enough dynamite doesn't get you
permission to use explosives for purposes of implementing porcine aviation.

> impresses me as a little strange.

Agreed.

				Ned

---

From: Tom Yu <[email-masked]>
Date: Tue, 13 Mar 2007 19:54:59 -0400

>>>>> "Ned" == Ned Freed <[email-masked]> writes:

>> deployment, existing tools, etc.

Ned> This suggestion was at the very least strongly implicit in the earlier
Ned> discussion.

I think I made some preliminary conclusions regarding the intent of
this effort, which I can write more about later.

Ned> It also occurs to me that what may be needed here is a BCP on how to best use
Ned> ASN.1. We have such a BCP on XML. ASN.1 is similarly complex and similarly
Ned> decorated with features, so it makes sense to me that if we're going to
Ned> continue to use it why not have a document discussing what features make sense
Ned> and what ones don't. (For example, some sage advice on when and how to use
Ned> EXTERNAL could have made several protocols a lot more tractable.)

I began such a document a few years ago.  Perhaps I should dust it
off.  Also, I think many people contemplating ASN.1 would do well to
read the actual specifications, as well as the reasonably good (and
freely downloadable) books by Dubuisson and Larmouth.

>> circumstances it is expected to useful is in order.

Ned> Given how little uptake (AFAIK) there has been of the various encodings for
Ned> ASN.1 beyond BER and DER (let's see, there's CER and PER and at least two
Ned> others whose names I cannot recall), I'm not especially worried about XER
Ned> taking the world by storm. Indeed, I think it would actually help XER's case if
Ned> there was some explanation of where and why you'd ever want to use it.

Use of alternative encoding rules might best be coupled with
presentation layer negotiation, which is a direction the IETF has
historically resisted moving towards, I think.  (It doesn't help that
PER is rather baroque for the sake of conserving bits.)

Ned> The fact that pigs can be made to fly with enough dynamite doesn't get you
Ned> permission to use explosives for purposes of implementing porcine aviation.

>> impresses me as a little strange.

Ned> Agreed.

I believe the omissions in the writeup have been acknowledged to be
mistakes.

---Tom

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 13 Mar 2007 17:30:49 -0700

Options are not necessarily complications.

The only point to having XER that I can see is if you intend to allow an orderly transition from use of ASN.1 to use of XML. Both standards do their job fine, both are somewhat more complex than they should be. One of these choices is surplus to requirements.

If I am writing in any modern development language that supports metadata such as .NET I can perform XML encoding and decoding automatically by simply calling up an encoder/decoder. To create the same capability in ASN.1 requires vastly more effort.

If we had hundreds of ASN.1 schemas that people cared about in the IETF I might see an argument for continuing to dual stack ASN.1 and XML indefinitely. Given where we are enabling a phase out of ASN.1 for certain protocols makes a lot of sense.

I don't think that this would make a lot of sense for PKIX but certainly for SNMP and LDAP. 

> From: John C Klensin [mailto:[email-masked]] 
> Sent: Tuesday, March 13, 2007 6:13 PM
> To: Simon Josefsson; Hallam-Baker, Phillip
> Cc: Brian E Carpenter; [email-masked]; [email-masked]; Pekka Savola
> proposal 
> >> is made I hear the complexity argument used against it. 
> Everything we 
> >> do is complex. Computers are complex.
> experimental 
> But that was precisely where the other thread, if I recall, 
> came out.  It wasn't an argument against complexity.  It was 
> an argument about introducing another optional way of doing 
> things because we _know_ that many options lead to worse 
> interoperability.  And it was a suggestion/ request that, 
> before this document was published in _any_ form, that it at 
> least acquire a clear discussion as to when one would select 
> this form over the well-established ASN.1 form for which 
> there is existing deployment, existing tools, etc.  Put 
> differently, we all know that this _can_ be done but, if 
> there is another solution already out there, widely deployed, 
> and in active use, a clear explanation about _why_ it should 
> be done and under what circumstances it is expected to useful 
> is in order.
>

---

From: John C Klensin <[email-masked]>
Date: Tue, 13 Mar 2007 23:29:35 -0400

> a later revision can move to the standards track.

Andy,  I just found Ted's note explaining that the writeup was
just an error.  These things happen and my reaction was a little
strong (pre-IETF tension, I think).  

Certainly, making it an experimental document helps with the
worst of the problem.  I'd be _seriously_ upset if we were
advancing it onto the standards track with as little context as
we have.  But, even for an experimental document, I still think
it would be highly desirable to get some serious discussion
about "why" and "when" into it to justify publication in any
form.   I think Ned's note summarizes the reasons for that
better than I could.  I also think that, if the author took
Ned's note, Phillip's recent one, contemplated both for a while,
and then turned the combination into a "rationale and context"
section (with appropriate acknowledgements, of course), that
none of us would have anything significant to complain about.  

best,
   john

---

From: David Kessens <[email-masked]>
Date: Tue, 13 Mar 2007 20:29:19 -0700

John,

> but I trust that has not occurred.

For the record, not everybody in the IESG was convinced that this
document should be approved considering the discussion that happened
on the IETF list.

David Kessens
---

---

From: John C Klensin <[email-masked]>
Date: Tue, 13 Mar 2007 23:18:06 -0400

--On Tuesday, 13 March, 2007 17:30 -0700 "Hallam-Baker, Phillip"
<[email-masked]> wrote:

> The only point to having XER that I can see is if you intend
> to allow an orderly transition from use of ASN.1 to use of
> XML. Both standards do their job fine, both are somewhat more
> complex than they should be. One of these choices is surplus
> to requirements.
> 
> If I am writing in any modern development language that
> supports metadata such as .NET I can perform XML encoding and
> decoding automatically by simply calling up an
> encoder/decoder. To create the same capability in ASN.1
> requires vastly more effort.
> 
> If we had hundreds of ASN.1 schemas that people cared about in
> the IETF I might see an argument for continuing to dual stack
> ASN.1 and XML indefinitely. Given where we are enabling a
> phase out of ASN.1 for certain protocols makes a lot of sense.
> 

Whether I agree with the above or not (and I think we could
debate your last couple of paragraphs at great length), if the
document said something like that, I'd be a lot happier.  

And, perhaps like some others, I'm much less concerned about the
document at this point than the claims that there were no
comments and/or no actionable comments.

I hope this is being discussed within the IESG because it would
be a pity to write up an appeal at this point --especially just
before the handoff-- if they were willing to just do the right
thing.  That, to me, would be to pull back the approval and
either rewrite the statement or tune the document a bit or both.

        john

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Mar 2007 10:33:14 +0100

> document should be approved considering the discussion that happened

I can testify that there would have been at least one DISCUSS if this
had stayed on the standards track, even without the Last Call comments.
But as Experimental, it seemed to me that we had no reason to
block it.

     Brian

---

From: Ned Freed <[email-masked]>
Date: Fri, 16 Mar 2007 11:17:07 -0700 (PDT)

> off.

I would certainly be supportive of that.

> Also, I think many people contemplating ASN.1 would do well to

To be honest I found the specifications totally inpenetrable as a means of
initially learning ASN.1, including the relatively straightforward initial
description that first appeared in X.400-1984. (I have no idea why they insist
on making macros in particular seem like so much more than they really are.) Of
course I no longer have this problem - but surely that's to be expected after
implementing X.400-1988 from scratch...

The free books are OK IMO but not great. Although it's now fairly dated, I
still think the best book on ASN.1 is the one by Douglas Steedman: ASN.1
Tutorial and Reference. Unfortunately it is out of print and nearly impossible
to find - and it was fairly expensive when it was in print. (And no, my copy is
not for sale ;-)

I went so far as to put this one on my list of books the ACM should revive and
republish, but I fear I was the only person who did so.

> PER is rather baroque for the sake of conserving bits.)

Or it might not. If memory serves, I actually implemented this stuff in our
X.400 code because some profile or other (German maybe?) required it. What I
found was that apparently everyone else that did it just coded it as a checkbox
item and didn't bother to check to see if it actually worked. The result was a
huge loss of interoperability, and X.400 interoperability was in general so
poor that I think we actually went so far as to rip it all out. (It's a huge
pain to implement for X.400 in any case because X.400 P1 uses RTSE, not ROSE,
and hence it is convenient to pre-encode messages and put them in files.)

This IMO is one of the big problems with lots of options in protocols - they
tend to result in batches of infrequently used code that contains lots of bugs.

				Ned