Subject: Do we now require change control on specifications we use?

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 4 Dec 2007 17:42:43 +0100

draft-bjorklund-netconf-yang-00.txt says:

> o From a process perspective, the IETF lacks any IETF change control
> and real input into the update process for XSD.

And draft-lengyel-why-yang-00 says:

> and we can enjoy long term stability and full chance control in the
> IETF, which also exercises change control over NETCONF.

That's a completely new argument for me, and a strange one. AFAIK,
there is no general rule in the IETF that the IETF must have "change
control" over the specifications it uses. Otherwise, we would never
used standards from very closed SDOs like ISO or IEEE.

And Netconf does not follow this practice, anyway, since it uses XML,
hardly a standard that the IETF controls.

Asking for "change control" here really looks like a modern form of
"NIH".

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 4 Dec 2007 09:29:28 -0800

> used standards from very closed SDOs like ISO or IEEE.

There is no rule.

However, past experience with ASN.1 has created enough scars in this  
community.
Using a base standard that is a moving target, in control by people  
who don't care about our needs, is a problem.

XML is *not* a moving target.
ASN.1 was.  Worse, it was in the control of tool vendors who were  
living off changes to the "standard" and increasing complexity in  
order to sell upgrades and keep a high barrier to market entry.

Exercise to the reader: Where in this picture is XSD?
(Hint: Whose interests/which forces shape this specification and its  
evolution?
Hint2: The existence of an insurgent direct competitor with strong  
support by large parts of the community is an indicator that there  
might be something interesting to find in this space.)

All that said, I'm not sure that XSD actually is that much of a moving  
target (1.1 notwithstanding).

Gruesse, Carsten

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 4 Dec 2007 10:25:12 -0800

>order to sell upgrades and keep a high barrier to market entry.

Oh, please. The "added complexity" that was *needed* to be changed in 
all the PKIX and S/MIME specs to meet the changes over 20 years of 
ASN.1 changes are minor and cause no bits-on-the-wire changes. See 
draft-hoffman-cms-new-asn1-00.txt and 
draft-hoffman-pkix-new-asn1-00.txt. Those drafts also add a bunch of 
very simple things that give compilers and validators more tools to 
find errors in data. Again, no bits-on-the-wire changes.

Blaming this on ASN.1 "tool vendors" is silly. First, there is 
basically only one significant tool vendor. More important, however, 
is that most of the changes have been to add new data formats that 
the IETF has completely ignored. Those formats (PER, CER, XER, 
YAER...) were wanted by other SDOs; that's no skin off our noses.

The changes in ASN.1 have had little or no effect on the IETF. We are 
considering bringing our specs up to date now, and it is quite easy 
and completely voluntary.

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 4 Dec 2007 10:31:17 -0800

Hi -

> From: "Stephane Bortzmeyer" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, December 04, 2007 8:42 AM
> Subject: Do we now require change control on specifications we use?
...
> Asking for "change control" here really looks like a modern form of

Agreed, but...  I understand how the bad experience with ASN.1's
mutations over the years could lead to this perspective.  The ASN.1
used for SNMP in the 1980s little resembles what is called
ASN.1 today.  (Those same changes also caused great heartburn
in ISO/ITU-land as well.  The ripple effects from the dropping of the
MACRO notation, bad as it was, turned into a tidal wave of changes
to other standards that, for example, relied on ROSE or ANY.)

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 4 Dec 2007 10:47:02 -0800

Hi -

> From: "Paul Hoffman" <[email-masked]>
> To: "Carsten Bormann" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, December 04, 2007 10:25 AM
> Subject: Re: Do we now require change control on specifications we use?
..
> The changes in ASN.1 have had little or no effect on the IETF. 
...

I disagree.  The dropping of the MACRO notation was one of the factors
(though by no means the only one) behind the migration from SMIv1 to SMIV2
in SNMP, and one of the reasons why SMIv2 is *not* defined using ASN.1
notation, even though it makes reference to ASN.1 types, etc.  The term
"adapted subset" really just means that there are some familiar tokens
in the language.  The whole SNMPv1->v2 transition was an *extremely*
painful process, and the net management old-timers cannot help but
be wary.

I also know first-hand that the changes caused an enormous amount of
grief for the CMIP folk in JTC1/SC21/WG4.  We were just very glad
we hadn't based GDMO on ASN.1, despite significant pressure to do so.

Randy

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 4 Dec 2007 11:00:16 -0800

On Dec 04 2007, at 10:25, Paul Hoffman wrote:

> Oh, please. The "added complexity" that was *needed* to be changed  
> in all the PKIX and S/MIME specs to meet the changes over 20 years  
> of ASN.1 changes are minor and cause no bits-on-the-wire changes.

So you were lucky.
(One could also say the writers of those specs had the right "taste"  
in using only features that survived.)

> basically only one significant tool vendor.

See?  The strategy worked for them.
(And yes, "tool vendors" is a simplification -- "that part of the  
ecosystem that benefits from change more than from stability" is a bit  
long.)

The end result is that there is a dearth of useful ASN.1 tools.  That  
matters.

> More important, however, is that most of the changes have been to  
> add new data formats that the IETF has completely ignored. Those  
> formats (PER, CER, XER, YAER...) were wanted by other SDOs;

There is an interesting push-pull relationship to those desires (as in  
"wanted"), but this is off-topic.

> The changes in ASN.1 have had little or no effect on the IETF.

Because the IETF uncoupled from the "progress" in those cases where it  
mattered.

> We are considering bringing our specs up to date now, and it is  
> quite easy and completely voluntary.

I was not trying to criticize that.  I still think ASN.1 is a textbook  
example for an external dependency gone wrong, at least for some of  
its customers.  And my point stands that having a dependency on an SDO  
that does not care about you does not help.

Gruesse, Carsten