Subject: [Netconf] Netconf Notification: Issues 22: Import Statements

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 21 Apr 2008 12:41:49 -0400

Hi

This is the last of the DISCUSS issues that requires a bit of airing.
The rest are fairly straight forward and I'll send the proposed edits
for those shortly. I've been putting this one off since the choice seems
to be between delaying the document or making a change I'm not all that
happy with.  

One of our DISCUSS issues is that there is an objection to using
URL-based schema locations in import statements. The concern is that
this will cause a lot of traffic to IETF/IANA websites by dumb tools.
Although I think a lot of us prefer URL-based locations since it would
mean people won't have to spend as much time hunting down and extracting
Schema as they did with MIBs, there is a realization that fighting this
might result in a delay in publication of the Notification work.

The proposed resolution would be to continue this discussion for the
sake of future specifications, but to make the following change to this
one:

Replace

<xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
    schemaLocation=
     "http://www.iana.org/assignments/xml-registry/schema/netconf.xsd"/>
<xs:import namespace=
    "urn:ietf:params:xml:ns:netconf:notification:1.0"
      schemaLocation=
"http://www.iana.org/assignments/xml-registry/schema/notification.xsd"/>

With (I think)

<xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
    schemaLocation=
     "urn:ietf:params:xml:ns:netconf:base:1.0"/>
<xs:import namespace=
    "urn:ietf:params:xml:ns:netconf:notification:1.0"
      schemaLocation=
"urn:ietf:params:xml:ns:netcoFrom [email-masked]  Mon Apr 21 09:42:05 2008
Content-class: urn:content-classes:message
Date: Mon, 21 Apr 2008 12:41:49 -0400
From: "Sharon Chisholm" <[email-masked]>
To: <[email-masked]>
Subject: [Netconf] Netconf Notification: Issues 22: Import Statements
Sender: [email-masked]

Hi

This is the last of the DISCUSS issues that requires a bit of airing.
The rest are fairly straight forward and I'll send the proposed edits
for those shortly. I've been putting this one off since the choice seems
to be between delaying the document or making a change I'm not all that
happy with.  

One of our DISCUSS issues is that there is an objection to using
URL-based schema locations in import statements. The concern is that
this will cause a lot of traffic to IETF/IANA websites by dumb tools.
Although I think a lot of us prefer URL-based locations since it would
mean people won't have to spend as much time hunting down and extracting
Schema as they did with MIBs, there is a realization that fighting this
might result in a delay in publication of the Notification work.

The proposed resolution would be to continue this discussion for the
sake of future specifications, but to make the following change to this
one:

Replace

<xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
    schemaLocation=
     "http://www.iana.org/assignments/xml-registry/schema/netconf.xsd"/>
<xs:import namespace=
    "urn:ietf:params:xml:ns:netconf:notification:1.0"
      schemaLocation=
"http://www.iana.org/assignments/xml-registry/schema/notification.xsd"/>

With (I think)

<xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
    schemaLocation=
     "urn:ietf:params:xml:ns:netconf:base:1.0"/>
<xs:import namespace=
    "urn:ietf:params:xml:ns:netconf:notification:1.0"
      schemaLocation=
"urn:ietf:params:xml:ns:netconf:notification:1.0"/>

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

nf:notification:1.0"/>

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Apr 2008 10:30:14 -0700

> might result in a delay in publication of the Notification work.

I do not agree with the problem statement.
Is there a demonstrated impact on the ietf.org WEB site
due to 'over-use' of the IANA registries?  When the IETF
posts files in the xml-registry/schema directory,
is the expectation that only humans will retrieve
the files, and HTML caches will not be used, causing
repeated retrievals?  I do not understand this objection.

Isn't the point of the IANA registries to have a stable home
for standard-related data which may need to be retrieved
by applications or humans?

ApplicatioFrom [email-masked]  Mon Apr 21 10:30:19 2008
Date: Mon, 21 Apr 2008 10:30:14 -0700
From: Andy Bierman <[email-masked]>
To: Sharon Chisholm <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements
Sender: [email-masked]

> might result in a delay in publication of the Notification work.

I do not agree with the problem statement.
Is there a demonstrated impact on the ietf.org WEB site
due to 'over-use' of the IANA registries?  When the IETF
posts files in the xml-registry/schema directory,
is the expectation that only humans will retrieve
the files, and HTML caches will not be used, causing
repeated retrievals?  I do not understand this objection.

Isn't the point of the IANA registries to have a stable home
for standard-related data which may need to be retrieved
by applications or humans?

Applications which utilize the schemaLocation attribute for
finding XSDs they do not know about are not dumb.  The purpose
of the schemaLocation attribute is to provide a URL associated
with a schema that defines the namespace contents.  This field
is not supposed to contain a generic URN.

Andy

ns which utilize the schemaLocation attribute for
finding XSDs they do not know about are not dumb.  The purpose
of the schemaLocation attribute is to provide a URL associated
with a schema that defines the namespace contents.  This field
is not supposed to contain a generic URN.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Apr 2008 19:49:35 +0200

> sake of future specifications, but to make the following change to this

[...]

Does it make sense to store a URN in schemaLocation? Perhaps simply
dropping the whole attribute is a simpler solution.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Apr 2008 19:49:35 +0200

[...]

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Apr 2008 11:09:56 -0700

Juergen Schoenwaelder wrote:
>> The proposed resolution would be to continue this discussion for the sake of future
>> specifications, but to make the following change to this one:
> 
> [...]
> 
> Does it make sense to store a URN in schemaLocation? Perhaps simply dropping the whole attribute
> is a simpler solution.
> 

I agree that no schemaLocation attribute has as much value as
having one which does not contain a URL.  I think automated retrieval
of XSDs via schemaLocation is a feature, not something that
will cause harm to the Internet.

 From the spec:
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-import

The <import> element information item identifies namespaces used in external references, i.e. those
whose ·QName· identifies them as coming from a different namespace (or none) than the enclosing
schema document's targetNamespace. The ·actual value· of its namespace [attribute] indicates that
the containing schema document may contain qualified references to schema components in that
namespace (via one or more prefixes declared with namespace declarations in the normal way). If
that attribute is absent, then the import allows unqualified reference to components with From [email-masked]  Mon Apr 21 11:09:57 2008
Date: Mon, 21 Apr 2008 11:09:56 -0700
From: Andy Bierman <[email-masked]>
To: Sharon Chisholm <[email-masked]>, [email-masked]
Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements
Sender: [email-masked]

Juergen Schoenwaelder wrote:
>> The proposed resolution would be to continue this discussion for the sake of future
>> specifications, but to make the following change to this one:
> 
> [...]
> 
> Does it make sense to store a URN in schemaLocation? Perhaps simply dropping the whole attribute
> is a simpler solution.
> 

I agree that no schemaLocation attribute has as much value as
having one which does not contain a URL.  I think automated retrieval
of XSDs via schemaLocation is a feature, not something that
will cause harm to the Internet.

 From the spec:
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-import

The <import> element information item identifies namespaces used in external references, i.e. those
whose ·QName· identifies them as coming from a different namespace (or none) than the enclosing
schema document's targetNamespace. The ·actual value· of its namespace [attribute] indicates that
the containing schema document may contain qualified references to schema components in that
namespace (via one or more prefixes declared with namespace declarations in the normal way). If
that attribute is absent, then the import allows unqualified reference to components with no tarno target
namespace. Note that components to be imported need not be in the form of a ·schema document·; the
processor is free to access or construct components using means of its own choosing.

The ·actual value· of the schemaLocation, if present, gives a hint as to where a serialization of a
·schema document· with declarations and definitions for that namespace (or none) may be found. When
no schemaLocation [attribute] is present, the schema author is leaving the identification of that
schema to the instance, application or user, via the mechanisms described below in Layer 3: Schema
Document Access and Web-interoperability (§4.3). When a schemaLocation is present, it must contain
a single URI reference which the schema author warrants will resolve to a serialization of a
·schema document· containing the component(s) in the <import>ed namespace referred to elsewhere in
the containing schema document.

Andy

get
namespace. Note that components to be imported need not be in the form of a ·schema document·; the
processor is free to access or construct components using means of its own choosing.

The ·actual value· of the schemaLocation, if present, gives a hint as to where a serialization of a
·schema document· with declarations and definitions for that namespace (or none) may be found. When
no schemaLocation [attribute] is present, the schema author is leaving the identification of that
schema to the instance, application or user, via the mechanisms described below in Layer 3: Schema
Document Access and Web-interoperability (§4.3). When a schemaLocation is present, it must contain
a single URI reference which the schema author warrants will resolve to a serialization of a
·schema document· containing the component(s) in the <import>ed namespace referred to elsewhere in
the containing schema document.

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 21 Apr 2008 14:16:35 -0400

Hi

To be fair, I should probably provide some more content from those opposed to URL-based schema locations. Personally, I think we need them.

- This is apparently a long standing IETF policy

- W3C gets a lot of hits
	http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic

- "At the time of this writing, IANA or IETF does not provide a registration service for HTTP URLs (something they'd commit to being stable and pointing to the same file over long term).

Creating such a service has indeed been proposed -- but do we want to block this document until that proposal has been accepted?"

Sharon

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Monday, April 21, 2008 2:10 PM
To: Chisholm, Sharon (CAR:ZZ00); [email-masked]
Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements

Juergen Schoenwaelder wrote:
>> sake of future specifications, but to make the following change to this one:
> 
> [...]
> 

I agree that no schemaLocation attribute has as much value as having one which does not contain a URL.  I think automated retrieval of XSDs via schemaLocation is a feature, not something that will cause harm to the Internet.

 From the spec:

The <import> element information item identifies namespaces used in external references, i.e. those whose ·QName· identifies them as coming from a different namespace (or none) than the enclosing schema document's targetNamespace. The ·actual value· of its namespace [attribute] indicates that the containing schema document may contain qualified references to schema components in that namespace (via one or more prefixes declared with namespace declarations in the normal way). If that attribute is absent, then the import allows unqualified reference to components with no target namespace. Note that components to be imported need not be in the form of a ·schema document·; the processor is free to access or construct components using means of its own choosing.

The ·actual value· of the schemaLocation, if present, gives a hint as to where a serialization of a ·schema document· with declarations and definitions for that namespace (or none) may be found. When no schemaLocation [attribute] is present, the schema author is leaving the identification of that schema to the instance, application or user, via the mechanisms described below in Layer 3: Schema Document Access and Web-interoperability (§4.3). When a schemaLocation is present, it must contain a single URI reference which the schema author warrants will resolve to a serialization of a ·schema document· containing the component(s) in the <import>ed namespace referred to elsewhere in the containing schema document.

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 21 Apr 2008 14:16:35 -0400

Hi

- W3C gets a lot of hits

Sharon

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Monday, April 21, 2008 2:10 PM
To: Chisholm, Sharon (CAR:ZZ00); [email-masked]
Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements

 From the spec:

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Apr 2008 11:36:10 -0700

> Creating such a service has indeed been proposed -- but do we want to block this document until that proposal has been accepted?"

I think Juergen's suggestion of removing the schemaLocation attribute
is the least worst option.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Apr 2008 11:36:10 -0700

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 21 Apr 2008 20:40:41 +0200 (CEST)

> is the least worst option.

I agree.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 21 Apr 2008 20:40:41 +0200 (CEST)

I agree.

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 21 Apr 2008 12:19:46 -0600

Hi -

> From: "Martin Bjorklund" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, April 21, 2008 12:40 PM

As long as the solution is no worse than SNMP,
and gets the work unstuck,
in IETF terms we should consider it progress.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 21 Apr 2008 12:19:46 -0600

Hi -

Randy

---

From: "Natale, Bob" <[email-masked]>
Date: Mon, 21 Apr 2008 15:27:52 -0400

I agree also.

Just two associated points from the broader thread

- A registry is logically distinct from a repository.  The IETF
probably needs IANA to provide a registry for such artifacts
(well-known source for authoritative information about somethings), but
IANA might not want to provide the corresponding (and possibly
distributed) repository service (the location where the somethings can
be gotten).  Indeed, as W3C found, no organization should sign-up to
deliver a service (esp. implicitly) w/o considering supply, demand,
administration, cost-recovery, priorities, trade-offs, etc.

- For IETF *standard* MIBs, I guess, roughly speaking, that the RFC
database was the repository (assuming the necessary extraction
function) and the latest RFC index (RFC n000) was the registry
(assuming inclusion of new RFCs in between indexes n and n+1).

Cheers,
BobN

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Martin Bjorklund
Sent: Monday, April 21, 2008 2:41 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] Netconf Notification: Issues 22: Import
Statements

I agree.

/martin

---

From: "Natale, Bob" <[email-masked]>
Date: Mon, 21 Apr 2008 15:27:52 -0400

I agree also.

Cheers,
BobN

-----Original Message-----

I agree.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Mon, 21 Apr 2008 15:31:58 -0400

>in IETF terms we should consider it progress.

That's too close to haiku to leave it alone:

    No worse than SNMP
    The IETF
    Should consider it progress

But seriously, is the IESG refusing to host XSD files in the basis
that another standards organizations that hosts a file referenced
by a zillion web pages gets significant hits from crappy software?
If the number of crappy netconf implementations ever reaches a
number where it can be called significant, we can declare netconf
successful.

The problem is that this is a bad precedent, meaning the IETF
will likely refuse to host YANG files and other netconf collateral
that applications will need access to.  Yes, this can be solved
by yang-central.org, but it sure seems like putting this material
on ietf/iana/iesg/imumble.org would be better.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 21 Apr 2008 15:31:58 -0400

No worse than SNMP
    The IETF

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 21 Apr 2008 15:33:24 -0400

>(assuming inclusion of new RFCs in between indexes n and n+1).

RFCs make a fairly horrible source file for mib compilers.  I'm
hoping we can do something more modern for NETCONF and YANG.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 21 Apr 2008 15:33:24 -0400

Thanks,
 Phil

---

From: "Natale, Bob" <[email-masked]>
Date: Mon, 21 Apr 2008 15:42:02 -0400

Hi Phil,

Yes, having written tools to work with MIBs embedded in RFCs, I
definitely agree -- we just need to work out explicit repository
arrangements for our more modern artifacts.

Cheers,
BobN

-----Original Message-----
From: Phil Shafer [mailto:[email-masked]] 
Sent: Monday, April 21, 2008 3:33 PM
To: Natale, Bob
Cc: [email-masked]
Subject: Re: [Netconf] Netconf Notification: Issues 22: Import
Statements 

Thanks,
 Phil

---

From: "Natale, Bob" <[email-masked]>
Date: Mon, 21 Apr 2008 15:42:02 -0400

Hi Phil,

Cheers,
BobN

-----Original Message-----
From: Phil Shafer [mailto:[email-masked]] 
Sent: Monday, April 21, 2008 3:33 PM
To: Natale, Bob
Cc: [email-masked]
Subject: Re: [Netconf] Netconf Notification: Issues 22: Import
Statements 

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Apr 2008 14:06:41 -0700

> (assuming inclusion of new RFCs in between indexes n and n+1).

I suppose there is a slippery slope between being a standards archive and
becoming part of the application infrastructure.

Perhaps a never-ending list of arbitrarily named text files (RFCnnnn)
was sufficient in previous decades, but it isn't enough anymore.
In order to build a meaningful standards-based CM system, the
IETF standards track YANG modules, XSD and DSDL files should be
accessible online.  If the IETF does not want to take on any
more responsibility than a document archive (understandable),
then other sites will host the data modules, in an ad-hoc,
non-standard manner.  Perhaps applications will guess the
schemaLocation by trying free databases, ala CDDB.

(I bet the extra bandwidth used up by NETCONF/YANG file retrieval
is less than the email bandwidth the IETF uses up worrying about
NETCONF/YANG file retrieval. ;-)

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Apr 2008 14:06:41 -0700

Andy

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Tue, 22 Apr 2008 00:02:03 +0200

I personally would like to keep the URL.

But (as document shepherd) I am worried that if we stock to what we
currently have in our revision 12 of the document, that we may end up
having along fight.

As Sharon says, it seems to be a generic issue. I would love it to be
solved so that our approach in rev 12 is acceptable. But I dont think
we will want to be the guineypig (spelling) on this one and risk a
looooong delay in publicationa s RFC.

SO I would favor to make the change for now and then continue our fight
and if we win, we can do anoteh rev.

Bert Wijnen

> -----Oorspronkelijk bericht-----
> Van: [email-masked] [mailto:[email-masked]]Namens
> Sharon Chisholm
> Verzonden: maandag 21 april 2008 20:17
> Aan: Andy Bierman; [email-masked]
> Onderwerp: Re: [Netconf] Netconf Notification: Issues 22: Import
> Statements
>
>
> Hi
>
> To be fair, I should probably provide some more content from
> those opposed to URL-based schema locations. Personally, I think
> we need them.
>
> - "At the time of this writing, IANA or IETF does not provide a
> registration service for HTTP URLs (something they'd commit to
> being stable and pointing to the same file over long term).
>
> Creating such a service has indeed been proposed -- but do we
> want to block this document until that proposal has been accepted?"
>
> Sharon
>
>
>
> having one which does not contain a URL.  I think automated
> retrieval of XSDs via schemaLocation is a feature, not something
> that will cause harm to the Internet.
>
>
>  From the spec:

The <import> element information item identifies namespaces used in external
references, i.e. those whose ·QName· identifies them as coming from a
different namespace (or none) than the enclosing schema document's
targetNamespace. The ·actual value· of its namespace [attribute] indicates
that the containing schema document may contain qualified references to
schema components in that namespace (via one or more prefixes declared with
namespace declarations in the normal way). If that attribute is absent, then
the import allows unqualified reference to components with no target
namespace. Note that components to be imported need not be in the form of a
·schema document·; the processor is free to access or construct components
using means of its own choosing.

The ·actual value· of the schemaLocation, if present, gives a hint as to
where a serialization of a ·schema document· with declarations and
definitions for that namespace (or none) may be found. When no
schemaLocation [attribute] is present, the schema author is leaving the
identification of that schema to the instance, application or user, via the
mechanisms described below in Layer 3: Schema Document Access and
Web-interoperability (§4.3). When a schemaLocation is present, it must
contain a single URI reference which the schema author warrants will resolve
to a serialization of a ·schema document· containing the component(s) in the
<import>ed namespace referred to elsewhere in the containing schema
document.

Andy

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Tue, 22 Apr 2008 00:02:03 +0200

Bert Wijnen

Andy

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Tue, 22 Apr 2008 00:06:24 +0200

As I said in my other message,
We can keep (and should) fighting... 
but we should accept (for now) what they (IESG) want 
and get our document published. 

If we (hell knows wehn) winn our fight; we can do a quick update 
to the RFC and include the URLs.

Bert Wijnen (speaking as document shepherd)

> Phil Shafer
> Verzonden: maandag 21 april 2008 21:32
> Aan: Randy Presuhn
> CC: [email-masked]
> on ietf/iana/ieFrom [email-masked]  Mon Apr 21 15:06:34 2008
From: "Bert Wijnen - IETF" <[email-masked]>
To: "Phil Shafer" <[email-masked]>,
	"Randy Presuhn" <[email-masked]>
Date: Tue, 22 Apr 2008 00:06:24 +0200
Importance: Normal
Cc: [email-masked]
Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements
Sender: [email-masked]

As I said in my other message,
We can keep (and should) fighting... 
but we should accept (for now) what they (IESG) want 
and get our document published. 

If we (hell knows wehn) winn our fight; we can do a quick update 
to the RFC and include the URLs.

Bert Wijnen (speaking as document shepherd)

> Phil Shafer
> Verzonden: maandag 21 april 2008 21:32
> Aan: Randy Presuhn
> CC: [email-masked]

sg/imumble.org would be better.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Apr 2008 00:31:29 +0200

> arrangements for our more modern artifacts.

I fail to see why people like to make a distinction between
traditional artifacts (MIB modules) or more modern artifacts such as
YANG or XSD modules; the language does not matter. All these artifacts
would benefit from a repository.

In the past, attempts to create such a repository for "traditional
artifacts" never went anywhere. If you go down the official IETF path,
you will find yourself quickly confronted with questions such as this
one:

  Will someone (who?, how is she selected) be allowed to fix bugs
  (what is the definition of a bug?) in an online repository (is it
  limited to IETF modules or may it contain IANA modules or even
  vendor modules?) or does the repository keep the version excatly as
  extracted from an RFC (will a new RFC revision automatically replace
  things in the repository?)  without changes (is white space removal
  a change?), even if serious bugs (what is the procedure to decide
  what a serious bug is?) have been detected after publication?

The best bet is probably to talk to the tools people; they might be
able to create something inofficial that does the job somehow. ;-)

To get the document published, drop the schemaLocation attribute and
declare success. Bert knows what he is talking about. ;-)

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Apr 2008 00:31:29 +0200

/js

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 21 Apr 2008 18:57:10 -0400

Hi, 

> by applications or humans?

IANA is responsible for providing standardized numbers fo the
Internet.
The RFC series is responsible for providing retrievable documents
containing IETF-standardized specifications (and other things).

I think having IANA provide a registry for schemas, just like it
provides a registry for MIB modules makes sense. I don't know that
having IANA.org provide storage for the schema themselves is the right
answer

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 21 Apr 2008 18:57:10 -0400

Hi,

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 21 Apr 2008 19:34:49 -0400

> becoming part of the application infrastructure.

There is a slippery slope between being a numnbering authority (IANA)
and being a standards archive (ala the RFC series) that becomes part
of the application infrastructure.

> schemaLocation by trying free databases, ala CDDB.

I think it would benefit the IETF community to have rfc-editor.org or
ietf.org (not iana.org) host an archive for standard data models,
including MIB modules. But there has to be a concern that the
normative document (the RFC) and the extracted schema could differ.
There are a number of issues that would need to be addressed, as
Juergen points out.

I suggest this be raised to the IAB, who, if I understand correctly,
have the job over overseeing the contracts with the RFC Editor
function to meet IETF needs (and I think might also control contracts
with the provider of ietf.org servers).

> NETCONF/YANG file retrieval. ;-)

I am pretty sure the bandwidth and storage requirements for
IETF-standard netconf schema would be dwarfed by the requirements for
bandwidth and storage of emails discussing the size of cookies
provided during IETF meetings. 

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 21 Apr 2008 19:34:49 -0400

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Apr 2008 20:54:47 -0700

David B Harrington wrote:
> including MIB modules. But there haFrom [email-masked]  Mon Apr 21 20:54:49 2008
Date: Mon, 21 Apr 2008 20:54:47 -0700
From: Andy Bierman <[email-masked]>
To: David B Harrington <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements
Sender: [email-masked]

David B Harrington wrote:
> including MIB modules. But ths to be a concern that the

Well, IANA extracts XSDs from RFCs are stores them in the
http://www.iana.org/assignments/xml-registry/schema/ directory.

I suppose there is some valid reason why IANA needs to maintain
these online files, yet not want them to be found via an <import>
clause.

Whether they differ from the RFC or not, these XSDs are being extracted
and stored.  Perhaps IANA should stop this practice.  You can carry
this logic right on through -- it seems pointless for IANA to extract
and store any information at all -- people should just hunt through RFCs
if they want to find any Internet 'data'.  Maybe IANA should never extract
any data from any published document, since this is redundant and
wastes precious iana.org bandwidth.

Andy

ere has to be a concern that the
> There are a number of issues that would need to be addressed, as

Well, IANA extracts XSDs from RFCs are stores them in the
http://www.iana.org/assignments/xml-registry/schema/ directory.

I suppose there is some valid reason why IANA needs to maintain
these online files, yet not want them to be found via an <import>
clause.

Whether they differ from the RFC or not, these XSDs are being extracted
and stored.  Perhaps IANA should stop this practice.  You can carry
this logic right on through -- it seems pointless for IANA to extract
and store any information at all -- people should just hunt through RFCs
if they want to find any Internet 'data'.  Maybe IANA should never extract
any data from any published document, since this is redundant and
wastes precious iana.org bandwidth.

Andy

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Tue, 22 Apr 2008 11:28:07 +0200

See... this seems to be the first step in a path of loooooong delay.
We have (in about 1 day) shifted our dicussion about our own
WG document into a discussion about the generic issue of storing
(and giving access) to extracted data from RFCs.

PLEASE... if you want to have this generic discussion, then
relabel the subject line (so I can ignore it). As document shepherd,
I am NOT interested in that type of discussion.

If you want the document to be hold up for this, then PLEASE do not
discuss this in detail, but just post one short message to the WG
list with subject "Holding Notifications Document".

If I see consensus forming to do that, then I can hand back my task
as "document shepherd" and give the document back to the WG for
further year-long discussions about this topic.

Bert Wijnen
Speaking as document shepherd

> Andy Bierman
> Verzonden: dinsdag 22 april 2008 5:55
> Aan: David B Harrington
> CC: [email-masked]
> > of the application infrastruFrom [email-masked]  Tue Apr 22 02:29:51 2008
From: "Bert Wijnen - IETF" <[email-masked]>
To: "Andy Bierman" <[email-masked]>,
	"David B Harrington" <[email-masked]>
Date: Tue, 22 Apr 2008 11:28:07 +0200
Importance: Normal
Cc: [email-masked]
Subject: [Netconf] Holding Notifications Document (was: RE: Netconf
	Notification: Issues 22: Import Statements)
Sender: [email-masked]

See... this seems to be the first step in a path of loooooong delay.
We have (in about 1 day) shifted our dicussion about our own
WG document into a discussion about the generic issue of storing
(and giving access) to extracted data from RFCs.

PLEASE... if you want to have this generic discussion, then
relabel the subject line (so I can ignore it). As document shepherd,
I am NOT interested in that type of discussion.

If you want the document to be hold up for this, then PLEASE do not
discuss this in detail, but just post one short message to the WG
list with subject "Holding Notifications Document".

If I see consensus forming to do that, then I can hand back my task
as "document shepherd" and give the document back to the WG for
further year-long discussions about this topic.

Bert Wijnen
Speaking as document shepherd

> Andy Bierman
> Verzonden: dinsdag 22 april 2008 5:55
> Aan: David B Harrington
> CC: [email-masked]

cture.

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 22 Apr 2008 09:45:41 -0400

Hi,

Is this a WGLC on this document?
The subject line doesn't say so.

The subject line is about the issue of a stable reference to support
imports, so I think the discussion of whether we can get a stable
archive to reference is part of the issue mentioned in the subject
line. I suggest that rather than grouse about it, we should (very
quickly) determine whose responsibility it would be to host such an
archive, and determine from those responsible whether an archive will
be set up.

I spoke up because I think expecting IANA to host such a repository is
asking the wrong organization to do this. If we want the problem
solved, we should talk to the right people.

If the goal of the WG is to deliver solutions of good technical
quality to help the Internet run better, we might want to try to solve
this (mainly) engineering problem to produce a solution that willFrom [email-masked]  Tue Apr 22 06:47:51 2008
From: "David B Harrington" <[email-masked]>
To: "'Bert Wijnen - IETF'" <[email-masked]>,
	"'Andy Bierman'" <[email-masked]>
Date: Tue, 22 Apr 2008 09:45:41 -0400
Cc: [email-masked]
Subject: Re: [Netconf] Holding Notifications Document (was: RE: Netconf
	Notification: Issues 22: Import Statements)
Sender: [email-masked]

Hi,

Is this a WGLC on this document?
The subject line doesn't say so.

The subject line is about the issue of a stable reference to support
imports, so I think the discussion of whether we can get a stable
archive to reference is part of the issue mentioned in the subject
line. I suggest that rather than grouse about it, we should (very
quickly) determine whose responsibility it would be to host such an
archive, and determine from those responsible whether an archive will
be set up.

I spoke up because I think expecting IANA to host such a repository is
asking the wrong organization to do this. If we want the problem
solved, we should talk to the right people.

If the goal of the WG is to deliver solutions of good technical
quality to help the Internet run better, we might want to try to solve
this (mainly) engineering problem to produce a solution that will
impro
improve the situation compared to the difficulty of finding MIB
modules. Our community probably has the most long-running problem
caused by the lack of such a repository, and we should make it clear
to those responsible that this is a real problem we need solved. 

If the goal is to make the document shepherd happy that we make
immediate progress, then we probably want to eliminate the
schemaLocation and let people hunt around to find the schema wherever
google sends them.

I have no desire to see a loooong discussion either, but neither do I
want to see us produce a poor quality solution to satisfy a petulant
document shepherd.

I think the solution is somewhere in between. I think we should, to
resolve this issue, contact the right people about the real need for
such a stable archive in the future, AND, to make document progress,
either use a URN or remove the schemaLocation. To deal only with the
document is to **not resolve** the issue but to ignore it.

dbh

> From: Bert Wijnen - IETF [mailto:[email-masked]] 
> Sent: Tuesday, April 22, 2008 5:28 AM
> To: Andy Bierman; David B Harrington
> Cc: [email-masked]
> Subject: Holding Notifications Document (was: RE: [Netconf] 
> Netconf Notification: Issues 22: Import Statements)
> 
> > I suppose there is some valid reason why IANA needs tve the situation compared to the difficulty of finding MIB
modules. Our community probably has the most long-running problem
caused by the lack of such a repository, and we should make it clear
to those responsible that this is a real problem we need solved. 

If the goal is to make the document shepherd happy that we make
immediate progress, then we probably want to eliminate the
schemaLocation and let people hunt around to find the schema wherever
google sends them.

I have no desire to see a loooong discussion either, but neither do I
want to see us produce a poor quality solution to satisfy a petulant
document shepherd.

I think the solution is somewhere in between. I think we should, to
resolve this issue, contact the right people about the real need for
such a stable archive in the future, AND, to make document progress,
either use a URN or remove the schemaLocation. To deal only with the
document is to **not resolve** the issue but to ignore it.

dbh

> From: Bert Wijnen - IETF [mailto:[email-masked]] 
> Sent: Tuesday, April 22, 2008 5:28 AM
> To: Andy Bierman; David B Harrington
> Cc: [email-masked]
> Subject: Holding Notifications Document (was: RE: [Netconf] 
> Netconf Notification: Issues 22: Import Statements)
> 
> > I suppose there is some valid reason why IANA needs to maino maintain

tain

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Apr 2008 07:10:20 -0700

> The subject line doesn't say so.

The WGLC thread ended already -- remove the schemaLocation attribute
and publish seems to be the consensus.

All IANA is supposed to do here is maintain a list
of URIs assigned to namespaces.  A simple text document
like for port numbers would be sufficient for this purpose.
(Does anyone know if this file exists?)

Instead, IANA is extracting XSDs and storing them online, but
it does not want applications to know about it.  This is neither
a registry or a repository.  (Let's just keep doing
this a few more years and it will become a 'long-standing' tradition
that cannot be changed ;-)

Andy

> solved, we should talk to the rightFrom [email-masked]  Tue Apr 22 07:10:23 2008
Date: Tue, 22 Apr 2008 07:10:20 -0700
From: Andy Bierman <[email-masked]>
To: David B Harrington <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Holding Notifications Document
Sender: [email-masked]

> The subject line doesn't say so.

The WGLC thread ended already -- remove the schemaLocation attribute
and publish seems to be the consensus.

All IANA is supposed to do here is maintain a list
of URIs assigned to namespaces.  A simple text document
like for port numbers would be sufficient for this purpose.
(Does anyone know if this file exists?)

Instead, IANA is extracting XSDs and storing them online, but
it does not want applications to know about it.  This is neither
a registry or a repository.  (Let's just keep doing
this a few more years and it will become a 'long-standing' tradition
that cannot be changed ;-)

Andy

> solved, we should talk to the people.
> 
>>>> There are a number of issues that wo right people.
> 
>>>> There are a number of issues tuld need to be addressed, as
>>>> Juergen points out.
>>>

hat would need to be addressed, as

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Apr 2008 09:12:01 -0700

Hi,

There is an IANA XML Registry:
http://www.iana.org/assignments/xml-registry-index.html

I looked at all 47 of the XSDs in the IANA XML registry:
http://www.iana.org/assignments/xml-registry/schema.html

There is a clear practice of using schemaLocation attributes
for other XSDs in the registry, which is exactly what
the Notifications XSD is doing, except with the wrong
kind of URL.

First the data:

Many XSDs do not have any <import> elements.

Most XSDs that have an <import> element, like these, do not
have a targetNamespace attribute in the <import> element:

    http://www.iana.org/assignments/xml-registry/schema/contact-1.0.xsd
    http://www.iana.org/assignments/xml-registry/schema/dchk1.xsd
    http://www.iana.org/assignments/xml-registry/schema/domain-1.0.xsd
    http://www.iana.org/assignments/xml-registry/schema/epp-1.0.xsd
    http://www.iana.org/assignments/xml-registry/schema/ereg1.xsd
    http://www.iana.org/assignments/xml-registry/schema/host-1.0.xsd

Some (including netconf) have the following import, which is one
of the corner-case XSDs that causes lots of WEB traffic:

    <xs:import namespace="http://www.w3.org/XML/1998/namespace"
      schemaLocation="http://www.w3.org/2001/03/xml.xsd" />

I think best current practice is not to have this import in XSDs
anymore, but I'm not sure.

Some XSDs, like these, have a targetNamespace attribute
in an <import> element:

    http://www.iana.org/assignments/xml-registry/schema/enum-token-1.0.xsd
    http://www.iana.org/assignments/xml-registry/schema/e164val-1.0.xsd
    http://www.iana.org/assignments/xml-registry/schema/e164valex-1.1.xsd
    http://www.iana.org/assignments/xml-registry/schema/pidf/timed-status.xsd

These schemaLocation attributes are all relative URLs for other XSDs in the
same directory (a few <include> elements do the same thing).
It seems clear that the Notifications XSD should use
a relative URL instead of no schemaLocation at all.

Here are the edits:

--------------------------------------

notification-12, page 18:

OLD:

NEW:

<xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
     schemaLocation="netconf.xsd"/>
<xs:import namespace=
     "urn:ietf:params:xml:ns:netconf:notification:1.0"
       schemaLocation="notification.xsd"/>

--------------------------------------

notification-12, page 24:

OLD:

NEW:

      <xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
        schemaLocation="netconf.xsd"/>

--------------------------------------

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Apr 2008 09:12:01 -0700

Hi,

First the data:

Here are the edits:

OLD:

NEW:

OLD:

NEW:

Andy

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Tue, 22 Apr 2008 19:14:09 +0200

Be my guest and go find the "right people" to setup and maintain
such a web site. If you want me to hold the document hostage till
that is done, then fine.... I will give in to that.

My experience in this space tells me we will be at least one year
further (if we ever get it done). 
At that time, there will be new IESG members, new IAB members, and 
the doc (since it has been out of sight for a year or more) will 
get re-scrutinized, and some IESG or IAB member (or one of their
directorate members (of whom we have plenty these days) will find
another issue that needs to be resolved... and on and on and on...

I don't think it is my task as document shepherd to try and entertain
all sorts of (in my view minor) issues that will delay the document 
forever. I agree that being able to IMPORT is goodness. But if we
loose that (like all current schema definitions in IETF do not 
have it), is that making the document fatally flawed? I don't think
so. So let us go ahead and accept the comment from IESG/IANA and 
get the docuemnt approved.

Those who have the enery to go fight for a repository that can be
referenced/used in an IMPORT Statement can then go and fight that 
battle. I might even participate... but I prefer not to hold up the
document.

At the other hand... we'll do whatever seems to be consensus of the
WG. Untill I see more than a few people speak up, I do not see a
reason to start this long process, beginning with a WGLC type
action.

Bert Wijnen 

> Van: David B Harrington [mailto:[email-masked]]
> Verzonden: dinsdag 22 april 2008 15:46
> Aan: 'Bert Wijnen - IETF'; 'Andy Bierman'
> CC: [email-masked]
> Onderwerp: RE: Holding Notifications Document (was: RE: [Netconf]

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Tue, 22 Apr 2008 19:14:09 +0200

Bert Wijnen

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Tue, 22 Apr 2008 19:15:57 +0200

Yep... and I believe this is what the IESG wants us to do based
on the DISCUSS we have seen.

Bert Wijnen

> Van: Andy Bierman [mailto:[email-masked]]
> Verzonden: dinsdag 22 april 2008 18:12
> Aan: David B Harrington
> CC: 'Bert Wijnen - IETF'; [email-masked]
> Onderwerp: Notification-12 schemaLocation edits
>
>
> Hi,
>

Here are the edits:

OLD:

NEW:

OLD:

NEW:

Andy

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Tue, 22 Apr 2008 19:15:57 +0200

Bert Wijnen

Here are the edits:

OLD:

NEW:

OLD:

NEW:

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Apr 2008 14:39:45 -0700

> that is done, then fine.... I will give in to that.

I don't think the IETF needs to spend any cycles on this.
The IESG-accepted approach of just listing the filename in
the schemaLocation is good enough.

Andy

> Those who have the enery to go fight for From [email-masked]  Tue Apr 22 14:39:45 2008
Date: Tue, 22 Apr 2008 14:39:45 -0700
From: Andy Bierman <[email-masked]>
To: Bert Wijnen - IETF <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Holding Notifications Document (was: RE: Netconf
 Notification: Issues 22: Import Statements)
Sender: [email-masked]

> that is done, then fine.... I will give in to that.

I don't think the IETF needs to spend any cycles on this.
The IESG-accepted approach of just listing the filename in
the schemaLocation is good enough.

Andy

> Those who have the enery to go figha repository that can be
>>>> Vert for a repository that can be
>>zonden: dinsdag 22 april 2008 5:55
>>>> Aan: David B Harrington
>>>> CC: [email-masked]

---

From: "tom.petch" <[email-masked]>
Date: Mon, 28 Apr 2008 12:13:23 +0200

---- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "David B Harrington" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, April 22, 2008 4:10 PM
Subject: Re: [Netconf] Holding Notifications Document

<snip>
> that cannot be changed ;-)
To quote from RFC3688, The IETF XML Registry,

" The IANA will also maintain a file server available via at least HTTP
 and FTP that contains all of the registered elements in some publicly
 accessible file space in the same way that all of the IANA's
 registered elements arFrom [email-masked]  Mon Apr 28 04:18:54 2008
From: "tom.petch" <[email-masked]>
To: "Andy Bierman" <[email-masked]>
Date: Mon, 28 Apr 2008 12:13:23 +0200
Cc: [email-masked]
Subject: Re: [Netconf] Holding Notifications Document
Reply-To: "tom.petch" <[email-masked]>
Sender: [email-masked]

---- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "David B Harrington" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, April 22, 2008 4:10 PM
Subject: Re: [Netconf] Holding Notifications Document

<snip>
> that cannot be changed ;-)
To quote from RFC3688, The IETF XML Registry,

" The IANA will also maintain a file server available via at least HTTP
 and FTP that contains all of the registered elements in some publicly
 accessible file space in the same way that all of the IANA's
 registered elements are avaie available via
  http://www.iana.org/assignments/.  While the directory structure of
  this server is up to the IANA, it is suggested that the files be
  organized by the <class> and the individual files have the <id> as
  their filename."

so while I appreciate the semantic distinction between repository and registry,
it seems clear to me that IANA are maintaining a readily accessible filestore of
the XSD source.

I note too the recent announcement that IANA are converting all their registries
to XML and inviting us to check that the contents have not been inadvertently
changed in doing so:-)

Tom Petch

> Andy
<snip>

lable via
  http://www.iana.org/assignments/.  While the directory structure of
  this server is up to the IANA, it is suggested that the files be
  organized by the <class> and the individual files have the <id> as
  their filename."

so while I appreciate the semantic distinction between repository and registry,
it seems clear to me that IANA are maintaining a readily accessible filestore of
the XSD source.

I note too the recent announcement that IANA are converting all their registries
to XML and inviting us to check that the contents have not been inadvertently
changed in doing so:-)

Tom Petch

> Andy
<snip>