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

[John C Klensin]

--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

[David Kessens]

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

[John C Klensin]

--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

[Hallam-Baker, Phillip]

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

[Tom Yu]

> "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

[Ned Freed]

> --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

[Andy Bierman]

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

[John C Klensin]

--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: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)

[Robert Sayre]

Sam Hartman wrote:

I think both 2818 and 4346 contain important details and need to be
normative.
  


That makes sense to me. However, I initially thought the references had 
been mistakenly switched around.


From the draft:

 At a minimum, client and server implementations MUST be capable of
 being configured to use HTTP Basic Authentication [RFC2617] in
 conjunction with a TLS connection as specified by [RFC2818].  See
 [RFC4346] for more information on TLS. 


This text is actively misleading, because it suggests RFC 4346 is 
included for informational purposes. The text should read:


"At a minimum, client and server implementations MUST be capable of
being configured to use HTTP Basic Authentication [RFC2617] in
conjunction with a TLS connection as specified by [RFC2818] and
[RFC4346]."

- Rob

___
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

[Tom Yu]

> "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: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)

[Sam Hartman]

> "Robert" == Robert Sayre <[EMAIL PROTECTED]> writes:

Robert> Sam Hartman wrote:
>> My preference is to resolve this by making 2818 normative; I
>> believe we've already 3967'd 2818 so we don't need an
>> additional last call on this one.
>> 

Robert> Is RFC 2818 sufficient to ensure interoperability?  It
Robert> would be quite easy for two implementations to claim to
Robert> implement "TLS" and fail to interoperate. RFC 4346
Robert> contains mandatory cipher suites. Without those,
Robert> conformant implementations could fail during
Robert> authentication setup, right? The same danger would exist

I think both 2818 and 4346 contain important details and need to be
normative.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)

[Robert Sayre]

Sam Hartman wrote:

My preference is to resolve this by making 2818 normative; I believe
we've already 3967'd 2818 so we don't need an additional last call on
this one.
  


Is RFC 2818 sufficient to ensure interoperability?  It would be quite 
easy for two implementations to claim to implement "TLS" and fail to 
interoperate. RFC 4346 contains mandatory cipher suites. Without those, 
conformant implementations could fail during authentication setup, 
right? The same danger would exist if the draft claimed "HTTP 
Authentication" must be supported without specifying a scheme.


- Rob

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)

[Sam Hartman]

> "Robert" == Robert Sayre <[EMAIL PROTECTED]> writes:

Robert> From the draft:
>> At a minimum, client and server implementations MUST be capable
>> of being configured to use HTTP Basic Authentication [RFC2617]
>> in conjunction with a TLS connection as specified by [RFC2818].
>> See [RFC4346] for more information on TLS.

Robert> I've discovered a small but potentially critical mistake
Robert> in the references here. RFC2818 is an informative
Robert> reference, so the text must read "as specified by
Robert> [RFC4346]".

My preference is to resolve this by making 2818 normative; I believe
we've already 3967'd 2818 so we don't need an additional last call on
this one.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

TLS requirements (Last Call: draft-ietf-atompub-protocol to Proposed Standard)

[Robert Sayre]

From the draft:

 At a minimum, client and server implementations MUST be capable of
 being configured to use HTTP Basic Authentication [RFC2617] in
 conjunction with a TLS connection as specified by [RFC2818].  See
 [RFC4346] for more information on TLS.


I've discovered a small but potentially critical mistake in the 
references here. RFC2818 is an informative reference, so the text must 
read "as specified by [RFC4346]".


- Rob

___
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]

> 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

[Simon Josefsson]

"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: Last Call: draft-martin-ibcs (Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems) to Informational RFC

[Sam Hartman]

> "Russ" == Russ Housley <[EMAIL PROTECTED]> writes:

Russ> See
Russ> https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=751
Russ> At 08:43 AM 3/13/2007, Sam Hartman wrote:

*Sigh* I searched on the draft before sending the last call comment
and when the search tool is used no documents show up.


___
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]

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

[Ted Hardie]

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

[Stephane Bortzmeyer]

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

[Hallam-Baker, Phillip]

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

[Simon Josefsson]

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: Atompub WG activity (Last Call: draft-ietf-atompub-protocol to Proposed Standard)

[James M Snell]

While it is definitely true that there has been a lot of good feedback,
it would still be good to at least start broadening the net and get
feedback from the larger IETF community.

- James

Julian Reschke wrote:
> [snip]
> + 0,5.
> 
> The document got lots of constructive feedback in the previous weeks
> (mainly due to fresh eyes), and I think it would be worthwhile to
> resolve most of the issues that were raised before doing the Last Call.
> This will save lots of time spent by new reviewers raising new issues.
> 
> Best regards, Julian
> 
> ___
> 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: Last Call: draft-martin-ibcs (Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems) to Informational RFC

[Russ Housley]

See https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=751

At 08:43 AM 3/13/2007, Sam Hartman wrote:


I'd feel uncomfortable approving this draft until the authors indicate
that any IPR disclosures required by our process have been filed.



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-openpgp-rfc2440bis (OpenPGP Message Format) to Proposed Standard

[Simon Josefsson]

Hi!

I started a review by going through the reference section.  There
seems to be some editing left to do...

There are reference to old documents, including:

  RFC 2279 -> RFC 3629
  RFC 1750 -> RFC 4086

There are normative reference to non-standards track RFCs, including:

  RFC 1641
  RFC 1951
  RFC 1991 (which documents is intended to obsolete?)
  RFC 2144

The following reference are never cited in the text as far as I can
tell.  Most of them should likely be removed, but citing
[BLEICHENBACHER] at some appropriate point may be useful.

[RFC1423]Balenson, D., "Privacy Enhancement for Internet
 Electronic Mail: Part III: Algorithms, Modes, and
 Identifiers", RFC 1423, October 1993.

[RFC1641]Goldsmith, D. and M. Davis, "Using Unicode with
 MIME", RFC 1641, July 1994.

[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal
 signatures without knowing the secret key,"
 Eurocrypt 96. Note that the version in the
 proceedings has an error. A revised version is
 available at the time of writing from
 

[DONNERHACKE]Donnerhacke, L., et. al, "PGP263in - an improved
 international version of PGP", ftp://ftp.iks-
 jena.de/mitarb/lutz/crypt/software/pgp/

[MAURER] Ueli Maurer, "Modelling a Public-Key
 Infrastructure", Proc. 1996 European Symposium on
 Research in Computer Security (ESORICS' 96),
 Lecture Notes in Computer Science, Springer-Verlag,
 vol. 1146, pp. 325-350, Sep 1996.

[RFC1983]Malkin, G., "Internet Users' Glossary", FYI 18, RFC
 1983, August 1996.

/Simon

The IESG <[EMAIL PROTECTED]> writes:

> The IESG has received a request from the An Open Specification for 
> Pretty Good Privacy WG (openpgp) to consider the following document:
>
> - 'OpenPGP Message Format '
> 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
> ietf@ietf.org mailing lists by 2007-03-27. Exceptionally, 
> comments may be sent to iesg@ietf.org 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-ietf-openpgp-rfc2440bis-19.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=4936&rfc_flag=0

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: draft-ietf-ltans-ers (Evidence Record Syntax (ERS)) to Proposed Standard - comment from Tim and answer

[Tobias Gondrom]

Comment to the draft received from Tim Polk during review:

> I thought I might follow up on the first unaddressed comment:
> 
> I notice that the phrase "the Initial Archive Timestamp" frequently 
> appears in the text with a capitalized 'I' in word "initial".  This
seems 
> to indicate that there *is* something special about this timestamp,
and I 
> would expect to find a definition in the terminology section.
> 
> Perhaps a lowercase 'i' would more clearly indicate that it is simply
a 
> subtype with the same structure?  That is, if the phrase was "the
initial 
> Archive Timestamp", I would only expect to find "Archive Timestamp" in
the  
> terminology section.  (Actually, the phrase appears with a lowercase
'i' 
> twice - once in section 1.2 and again in 5.2.  I assume there is no 
> difference?)
> 
> Thanks,
>
> Tim Polk

Answer from I-D author:
> Hi Tim,
> 
> I agree with you, and follow your comment and will make sure in the
final 
> revision of the draft that the word "initial" of the "initial Archive 
> Timestamp" only starts with a capital letter at the beginning of a 
> sentence.
> 
> Thanks, Tobias


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-ietf-16ng-ipv6-over-ipv6cs (IPv6 Over the IP Specific part of the Packet Convergence sublayer in 802.16 Networks) to Proposed Standard

[Basavaraj Patil]

Hello,

A slightly revised version of the I-D is now available at:
http://people.nokia.net/~patil/IDs/draft-ietf-16ng-ipv6-over-ipv6cs-09.txt

This revision incorporates changes based on some of the comments made by the
directorate. It will be submitted to the ID repository as soon as the gates
are opened.

-Basavaraj


On 3/12/07 9:57 AM, "ext The IESG" <[EMAIL PROTECTED]> wrote:

> The IESG has received a request from the IP over IEEE 802.16 Networks WG
> (16ng) to consider the following document:
> 
> - 'IPv6 Over the IP Specific part of the Packet Convergence sublayer in
>802.16 Networks '
> 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
> ietf@ietf.org mailing lists by 2007-03-31. Exceptionally,
> comments may be sent to iesg@ietf.org 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-ietf-16ng-ipv6-over-ipv6cs-08.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15298&;
> rfc_flag=0
> 
> 
> 
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> 


___
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

[Brian E Carpenter]

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

[John C Klensin]

--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: Last Call: draft-martin-ibcs (Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems) to Informational RFC

[Sam Hartman]

I'd feel uncomfortable approving this draft until the authors indicate
that any IPR disclosures required by our process have been filed.



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Atompub WG activity (Last Call: draft-ietf-atompub-protocol to Proposed Standard)

[Julian Reschke]

Robert Sayre schrieb:


The IESG has received a request from the Atom Publishing Format and 
Protocol WG (atompub) to consider the following document:


- 'The Atom Publishing Protocol '
as a Proposed Standard


By my count, draft-ietf-atompub-protocol-14.txt has generated over 250 
on-topic comments on the WG list since March 06, when the version was 
announced. It is clearly not ready for publication. I don't think it is 
appropriate for the IETF as a whole to review this document.


+ 0,5.

The document got lots of constructive feedback in the previous weeks 
(mainly due to fresh eyes), and I think it would be worthwhile to 
resolve most of the issues that were raised before doing the Last Call. 
This will save lots of time spent by new reviewers raising new issues.


Best regards, Julian

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf