Let's be careful with those XML submissions to IANA

2009-09-01 Thread Tom.Petch
Looking at RFC5102 (IPFIXinfo), it, like many RFC, has normative definitions
in the body of the document and a non-normative appendix, which, since it
brings the definitions together, is easier and so more likely to be used.

Indeed, the IANA considerations, s.7, tell IANA to register the non-normative
appendix which is fine as long as the two are in step but what happens when they
are not?

In fact, they do differ slightly.

The IANA considerations register
   URI: urn:ietf:params:xml:ns:ipfix-info-15
   XML: See Appendix B for this document.

whereas Appendix B says that the name is
   schema targetNamespace=urn:ietf:params:xml:ns:ipfix-info
which is what is in the IANA registry.

IANA have used Appendix B and so have got the right answer
by doing the 'wrong' thing.

(Interestingly the last I-D of this document had, in Appendix B,
 schema targetNamespace=urn:ietf:params:xml:ns:ipfix-info-10
 xmlns:ipfix=urn:ietf:params:xml:ns:ipfix-info-10)

What if an error is discovered in the body of the document (I have not looked
at it in any detail) and an erratum is raised against it?  Does this implicitly
request IANA to update the registry? Does it matter whether the erratum is
against the appendix or the body of the document?

(I think this is called the distributed database problem:-)

 Tom Petch

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


Re: Let's be careful with those XML submissions to IANA

2009-09-01 Thread Doug Barton
Assuming that there actually is a contradiction here (and I don't know
anything about IPFIX so I won't hazard a guess) the end result is a
quality-control problem that should be brought to the attention of the
RFC Editor.

If I understand your comments below correctly, you're encouraging
document authors and reviewers to have better attention to detail,
which I agree is also a good takeaway.

Finally, please remember this example the next time you're tempted to
complain about how long it takes the RFC Editor and/or IANA to take
action on a document. Reasonable concerns about processing timeliness
aside, y'all are not so easy to work with as you would sometimes like
to believe.  :)


Doug


Tom.Petch wrote:
 Looking at RFC5102 (IPFIXinfo), it, like many RFC, has normative definitions
 in the body of the document and a non-normative appendix, which, since it
 brings the definitions together, is easier and so more likely to be used.
 
 Indeed, the IANA considerations, s.7, tell IANA to register the non-normative
 appendix which is fine as long as the two are in step but what happens when 
 they
 are not?
 
 In fact, they do differ slightly.
 
 The IANA considerations register
URI: urn:ietf:params:xml:ns:ipfix-info-15
XML: See Appendix B for this document.
 
 whereas Appendix B says that the name is
schema targetNamespace=urn:ietf:params:xml:ns:ipfix-info
 which is what is in the IANA registry.
 
 IANA have used Appendix B and so have got the right answer
 by doing the 'wrong' thing.
 
 (Interestingly the last I-D of this document had, in Appendix B,
  schema targetNamespace=urn:ietf:params:xml:ns:ipfix-info-10
  xmlns:ipfix=urn:ietf:params:xml:ns:ipfix-info-10)
 
 What if an error is discovered in the body of the document (I have not looked
 at it in any detail) and an erratum is raised against it?  Does this 
 implicitly
 request IANA to update the registry? Does it matter whether the erratum is
 against the appendix or the body of the document?
 
 (I think this is called the distributed database problem:-)
 
  Tom Petch
 
 ___
 Ietf mailing list
 Ietf@ietf.org
 https://www.ietf.org/mailman/listinfo/ietf

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