Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC (fwd)
Posted for Dean.
-- Forwarded message --
Date: Sat, 17 Mar 2007 23:50:33 -0400 (EDT)
From: Dean Anderson <[EMAIL PROTECTED]>
To: Pekka Savola <[EMAIL PROTECTED]>, John C Klensin <[EMAIL PROTECTED]>,
Simon Josefsson <[EMAIL PROTECTED]>,
Brian E Carpenter <[EMAIL PROTECTED]>,
Stephane Bortzmeyer <[EMAIL PROTECTED]>,
"Hallam-Baker, Phillip" <[EMAIL PROTECTED]>,
Ted Hardie <[EMAIL PROTECTED]>, Tom Yu <[EMAIL PROTECTED]>,
Andy Bierman <[EMAIL PROTECTED]>, Ned Freed <[EMAIL PROTECTED]>,
David Kessens <[EMAIL PROTECTED]>
Cc: iesg@ietf.org, ietf@ietf.org
Subject: Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to
Experimental RFC
I would appreciate it is someone would repost this to the IETF list.
First, I want to say that I support an ASN.1 compiler in C++ and am
considering a rewrite of that compiler's translated runtime to ADA to
leverage some of ADA's advantages. While some people think ASN.1 is
obsolete, it is still a very efficient way to describe protocols and
generate their codecs. ASN.1 has attractive security properties, once
the security flaws are removed from the ASN.1 translator, of course.
However, that effort, once performed in the translator, subsequently
benefits and protects all users with no code changes. ASN.1 is
complicated, but robust and usually worth the effort.
XML, by contrast, is quick and dirty and inefficient; the protocol/codec
equivalent of a scripting language. The world needs both scripting
languages and compiled languages, and likewise I see a need for both XML
and ASN.1.
So, I have some mixed feelings about this document. The motivation for
this work is entirely unclear to me. Why is the X.693 XML Encoding Rules
(XER) Specification insufficient for encoding ASN.1 in XML? If XER is
truly deficient, perhaps it should be amended, and so this issue belongs
with the ITU, not the IETF. But I am unable to divine the deficiency in
XER from reading this document.
But also, if X.693 is insufficient, the next question is why is X.692
Encoding Control Notation insufficient? (well, I suppose its too new)
I suggest that one investigate XER and also X.692 Encoding Control
Notation, rather than specify a new and incompatible alternative.
In reading the document, I think a little too much is made of the issue
of ambiguity in ASN.1 specifications; they are only ambiguous if you
want to translate in a single pass with a LALR(1) parser generator.
But, I looked at Section 6 of the draft for some insight, and found this
claim:
Note that the notation of ASN.1 is ambiguous where a Type is both
prefixed [X.680-1] (e.g., tagged) and constrained. For example, the
notation "[0] INTEGER (0..10)" could be interpreted as either a
tagged ConstrainedType or a constrained TaggedType. For the purposes
of the translation into ASN.X, the constraint is assumed to have
higher precedence than the prefix, so the above notation would be
taken to be a tagged ConstrainedType.
Looking at my copies of X.680 and X.680 Amendment 1, I find no reason to
see that there is any ambiguity in the quoted example. Also, X.680
Amendment 1 seems to have no relevance to the paragraph, so I'm
wondering if the reference is a mistake.
In fact, X.680 Amendment 2, Section F.6 gives numerous examples of
tagged constrained types of similar form as the example above.
A closer look reveals no ambiguity:
The productions in question are defined in X.680 Section 16.2 and 30.1,
I have abbreviated them:
Type ::= BuiltinType | ReferencedType | ContrainedType
BuiltinType ::= ... |
TaggedType
TaggedType ::= Tag Type
Tag ::= "[" Class ClassNumber "]"
where Class can be empty, as it is in the quoted example.
Definition 3.8.64 gives a definition for the meaning of tagged types:
"A type defined by referencing a single existing type and a tag; the new
type is isomorphic to the existing type but distinct from it."
However, there is no ambiguity since tag and constraint are attributes
of a type, and it doesn't matter which comes first. ASN.1 compilers
which I am familiar with perform this as follows (Bison/c++)
TaggedType
: Tag Type
{
$2->SetTag($1.tagClass, $1.tagNumber,
Module->GetDefaultTagMode());
$$ = $2;
}
ConstrainedType
: Type Constraint
{
$1->AddConstraint($2);
}
| TypeWithConstraint
;
Bison translates this without conflicts. A longest string of terminals
always results in a ConstrainedType being reduced before a TaggedType is
reduced to Type. Bison and yacc resolve shift/reduce conflicts as
"shift" unless otherwise directed by operator precedence rules.
Suppose the parser stack contains:
Tag ([0])
Type (INTEGER)
The next symbol is "("
A shift (the default) implies that ConstrainedType w
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
> > "Ned" == Ned Freed <[EMAIL PROTECTED]> writes: > >> --On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson > >> <[EMAIL PROTECTED]> wrote: > >> 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. > 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. I would certainly be supportive of that. > 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. 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. > >> 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. > 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.) 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
On 2007-03-14 04:29, David Kessens wrote: John, On Tue, Mar 13, 2007 at 09:04:52AM -0400, John C Klensin wrote: 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. 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
--On Tuesday, 13 March, 2007 17:30 -0700 "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> wrote: > 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
John, On Tue, Mar 13, 2007 at 09:04:52AM -0400, John C Klensin wrote: > > 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. 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 --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
--On Tuesday, 13 March, 2007 16:01 -0700 Andy Bierman <[EMAIL PROTECTED]> wrote: > > 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
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. > -Original Message- > From: John C Klensin [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 13, 2007 6:13 PM > To: Simon Josefsson; Hallam-Baker, Phillip > Cc: Brian E Carpenter; iesg@ietf.org; ietf@ietf.org; Pekka Savola > Subject: Re: Document Action: 'Abstract Syntax Notation X > (ASN.X)' to Experimental RFC > > > > --On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson > <[EMAIL PROTECTED]> wrote: > > > "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> 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. > >> > >> If an argument can always be used what is the discrimination power? > > > > 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. > > 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 > > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
> "Ned" == Ned Freed <[EMAIL PROTECTED]> writes: >> --On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson >> <[EMAIL PROTECTED]> wrote: >> 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. 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. >> 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. 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. >> 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. Ned> Agreed. I believe the omissions in the writeup have been acknowledged to be mistakes. ---Tom ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
> --On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson > <[EMAIL PROTECTED]> wrote: > > "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> 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. > >> > >> If an argument can always be used what is the discrimination > >> power? > > > > 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. > 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. 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 > 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. 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 > 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. 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. > 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. Agreed. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
John C Klensin wrote: --On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson <[EMAIL PROTECTED]> wrote: "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> 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. If an argument can always be used what is the discrimination power? 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. 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
--On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson <[EMAIL PROTECTED]> wrote: > "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> 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. >> >> If an argument can always be used what is the discrimination >> power? > > 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
> "pbaker" == Hallam-Baker, Phillip <[EMAIL PROTECTED]> 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
> From: Simon Josefsson [mailto:[EMAIL PROTECTED] > "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> 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. > > > > If an argument can always be used what is the discrimination power? > > 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. 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
"Hallam-Baker, Phillip" <[EMAIL PROTECTED]> 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. > > If an argument can always be used what is the discrimination power? 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
Absolutely there are degrees in complexity. But there are no objective measures. PKIX is certainly not a simple specification. It got that way for one simple reason - people used it enough to care about it. So over fifteen years it has grown. My point here is that if you look at an architecture with five layers it will appear to be more complex than one with two layers. But that does not say anything useful about the complexity of the overall system. Is the complexity in the design or in the requirements? If PKIX had originally been designed to anticipate a wider range of functions it could have been made much simpler. We could for example have used the same structure for CRLs and OCSP if both needs had been anticipated up front. Encoding ASN.1 in XML allows implementations to reduce the number of parser/encoder modules that they need to deal with. That represents a reduction in complexity as far as an embedded single purpose device is concerned. If you are writing an all purpose development tool your work has increased. Every change we make has complexity implications, very rarely does the complexity go down. A valid complexity argument in my view would be 'I can meet that set of needs in this way which is empirically less complex by virtue of these considerations (number of states required, number of different syntaxes, administrative burden)'. Simply stating 'that is more complex' does not tell me anything useful. Is the complexity unreasonable considering the objective. In this case the idea of being able to eventually eliminate the need for dual stack implementations of ASN.1 based protocols in the XML/SOAP world is very attractive to me. Having a single standard mapping from the ASN.1 world to the XML one is equally so. > -Original Message- > From: Stephane Bortzmeyer [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 13, 2007 11:23 AM > To: Hallam-Baker, Phillip > Cc: ietf@ietf.org > Subject: Re: Document Action: 'Abstract Syntax Notation X > (ASN.X)' to Experimental RFC > > On Tue, Mar 13, 2007 at 08:09:35AM -0700, Hallam-Baker, > Phillip <[EMAIL PROTECTED]> 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. > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
At 7:47 AM +0200 3/13/07, Pekka Savola wrote: >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 PROTECTED], 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
On Tue, Mar 13, 2007 at 08:09:35AM -0700, Hallam-Baker, Phillip <[EMAIL PROTECTED]> 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
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 PROTECTED] > Sent: Tuesday, March 13, 2007 10:11 AM > To: John C Klensin > Cc: ietf@ietf.org; Pekka Savola; iesg@ietf.org > Subject: Re: Document Action: 'Abstract Syntax Notation X > (ASN.X)' to Experimental RFC > > 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 > > On 2007-03-13 14:04, John C Klensin wrote: > > > > --On Tuesday, 13 March, 2007 07:47 +0200 Pekka Savola > > <[EMAIL PROTECTED]> wrote: > > > >> 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 PROTECTED], 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 > > > > > > ___ > > Ietf mailing list > > Ietf@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf > > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
Pekka Savola <[EMAIL PROTECTED]> writes: > 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 PROTECTED], as well as 12 comments under the 'Protest: Complexity > running rampant' thread. 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 ; 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
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 On 2007-03-13 14:04, John C Klensin wrote: --On Tuesday, 13 March, 2007 07:47 +0200 Pekka Savola <[EMAIL PROTECTED]> wrote: 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 PROTECTED], 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
--On Tuesday, 13 March, 2007 07:47 +0200 Pekka Savola <[EMAIL PROTECTED]> wrote: > 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 PROTECTED], 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Document Action: 'Abstract Syntax Notation X (ASN.X)' to Experimental RFC
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 PROTECTED], as well as 12 comments under the 'Protest: Complexity running rampant' thread. -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
