Subject: RE: Proposed Resolution to PROT I-D Issues List

From: "McDonald, Ira" <[email-masked]>
Date: Wed, 23 Mar 2005 06:40:35 -0800

Hi,

About hosting the NetConf XSD elsewhere (than just the RFC):

(1) As David Harrington just observed, this will be done
    anyway, just as now happens with MIBs

(2) Even an 'official' hosting elsewhere (per the eventual 
    NetConf RFC) isn't any help - because really almost no 
    one _does_ read the RFC - they read the machine-readable
    portions out of context.

(3) Repairing bugs in XSD hosted elsewhere is tricky, because
    XML in general and XSD in particular have serious unsolved
    problems of version control and identification - just
    overwriting an undated generic link for the XSD 'works', 
    but not in any predictable way - each implementation may
    have picked up the XSD via that link at a different point
    in time.

(4) If the 'bug' is determined to be in the sainted plaintext,
    then fixing the outboard XSD won't help at all.

(5) As Wes Hardaker alludes to below, the RFC update, approval,
    and publication process is an order of magnitude too slow
    to be helpful.

Cheers,
- Ira

PS - Separately from "version" in XML documents, the problem
of "namespace" is awful.  W3C and other standards organizations
have no concensus solution.  The current most widespread kludge
is to _never_ change the "namespace" - but just keep putting more 
stuff in the latest "version" of the XSD in the same namespace.

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

-----Original Message-----
From: Wes Hardaker [mailto:[email-masked]]
Sent: Wednesday, March 23, 2005 1:29 AM
To: Andy Bierman
Cc: [email-masked]; 'McDonald, Ira'; 'Randy Presuhn';
[email-masked]
Subject: Re: Proposed Resolution to PROT I-D Issues List

Andy> Echoing one last word on XSD vs. plaintext -- if the XSD doesn't
Andy> match the text then we fix whichever one is broken.

Nice in theory, but not nice in the IETF.

1) the IETF standards track provides strict controls on updating documents.

2) updates never happen quickly.  The editor queue alone would be too
   long to change something.

One solution would be to host the XSD elsewhere and reference it, but
that's likely not acceptable from a standards process either.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 23 Mar 2005 12:19:44 -0500

Hi,

Let me expand on my earlier comment.

The XSD will likely be distributed separated from the RFC, just as
happens with MIB modules, if certain conditions arise, which have
arisen with MIB modules.

Separate distribution is likely to occur if:
1) compilers and tools do not adequately distinguish the XSD from the
rest of the document programmatically, and require that the XSD be
separated from the surrounding text before processing,
2) multiple XSD specifications can exist within a document and
available tools are not able to deal with this,
3) XSDs are fairly easy to produce that are good enough for most use
cases, but RFCs are burdensome to produce because of boilerplates,
id-nits, MIB Doctor reviews, and other IETF-publication-process CLRs,
4) XSDs are fairly easy to produce that are good enough for most use
cases, and vendor-specific XSDs are produced without all the
unnecessary boilerplates, id-nits, MIB Doctor reviews, and other junk
that do not necessarily help vendors implement products, sell products
and get them to market before their competitors, and the extra junk
does not actually help their customers manage their networks, and
5) XSDs are unambiguous enough for operators to use, and operators'
tools to use programmatically, even if correct implementation might
have required referencing the surrounding text.

I think this last point is very important - I do not believe most
implementors work with only the MIB module; they also read the RFC.
Vendors distribute the stripped MIB modules to operators, because the
MIB modules alone are often good enough to meet the requirements of
operators and operators' tools, and the extra stuff is often available
in RFCs or product release notes or customer support.

But these points are all meta-discussion mostly unrelated to this WG's
deliverables.

I suggest that this WG develop specs that **support** the separate
distribution of the XSD from the RFC, and design the XSD to address
the potential issues caused by separate distribution. 

Let's make sure 
1) the XSD contains a clearly marked version, preferably
machine-parseable.
2) the XSD can be programmtically separated from the surrounding RFC
text reliably.
3) the XSD contains enough information to be meaningful to operators
and their tools.

David Harrington
[email-masked]