Subject: RE: RFC queue documents stuck on a normative reference

From: [email-masked]
Date: Fri, 29 Jul 2005 09:07:22 +0300

Thomas,

What is the process to change something from Normative to Informative?
Can the authors do it themselves, do WG chairs need to be involved,
does the IESG need to be informed?  I agree with you that many of
the Normative refs could be considered Informative.

thanks,
John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of ext Thomas Narten
> Sent: 27 July, 2005 20:47
> To: [email-masked]
> Subject: RFC queue documents stuck on a normative reference 
> 
> 
> I happened to be looking at the RFC queue recently, and noticed that
> there are a number of documents currently blocked, pending the
> availability of a normative reference.
> 
> I'd encourage you to look for documents that you are responsible for
> (i.e., those in your WG!)  and determine what can be done to get the
> normative references satisfied. Your options are:
> 
>   - remove the normative reference, i.e., by tweaking the text to
>     ensure that the way the reference is used, it is informational
>     rather than normative. (note: this usually means more than just
>     moving the reference to the "informative references" section; the
>     wording surrounding the use of the reference needs to be of an
>     informational nature.) Also, folk really should look at this
>     option carefully. In my experience reviewing documents, I've seen
>     plenty of "normative" references that IMO didn't need to be
>     normative. See section 1.1 of RFC 3967 for some additional wording
>     on the topic of normative vs. informative.
> 
>   - followup with the stuck document and help to get it completed and
>     published.
> 
> There's some 65 documents here. And some of been waiting many many
> _months_.
> 
> To figure out what is going on for document X, go to
> www.rfc-editor.org/queue.html, and see what document X is waiting
> on. Then go see its status, etc. (You may need to do this
> recursively.)
> 
> You might also find http://rtg.ietf.org/~fenner/iesg/rfc-deps.pdf
> useful, as it shows the normative reference relationships graphically.
> 
> Thomas
> 
> Days	ID name
> ====    =======
> 2	draft-ietf-enum-msg
> 16	draft-zeilenga-ldap-assert
> 16	draft-zeilenga-ldap-readentry
> 17	draft-zeilenga-ldap-t-f
> 26	draft-rescorla-dtls
> 27	draft-ietf-sipping-cc-conferencing
> 32	draft-ietf-mip6-mipv6-mib
> 32	draft-ietf-simple-xcap
> 34	draft-ietf-ipcdn-docsisevent-mib
> 34	draft-ietf-mmusic-sdp-media-label
> 47	draft-ietf-ops-mib-review-guidelines
> 66	draft-ietf-msec-gsakmp-sec
> 69	draft-ietf-l3vpn-mpls-vpn-mib
> 74	draft-ietf-aaa-diameter-cc
> 102	draft-ietf-ipsec-rfc2401bis
> 110	draft-ietf-ipsec-esp-v3
> 110	draft-ietf-msec-mikey-dhhmac
> 110	draft-ietf-sipping-kpml
> 115	draft-ietf-simple-event-filter-funct
> 115	draft-ietf-simple-filter-format
> 117	draft-burmeister-avt-rtcp-feedback-sim
> 117	draft-ietf-avt-rtcp-feedback
> 117	draft-ietf-nsis-rsvp-sec-properties
> 126	draft-ietf-sasl-anon
> 131	draft-ietf-sip-guidelines
> 136	draft-ietf-l2vpn-l2-framework
> 136	draft-ietf-simple-xcap-pidf-manipulation-usage
> 145	draft-ietf-ldapbis-dn
> 145	draft-ietf-ldapbis-filter
> 145	draft-ietf-ldapbis-models
> 151	draft-ietf-simple-xcap-list-usage
> 152	draft-zeilenga-ldup-sync
> 165	draft-ietf-ldapbis-url
> 185	draft-melnikov-imap-disc
> 191	draft-ietf-ipoib-ip-over-infiniband
> 194	draft-ietf-ipsec-esn-addendum
> 194	draft-ietf-ipsec-rfc2402bis
> 202	draft-ietf-ipsec-esp-ah-algorithms
> 202	draft-zeilenga-ldap-authzid
> 236	draft-ietf-grow-collection-communities
> 237	draft-ietf-v6ops-3gpp-analysis
> 243	draft-behringer-mpls-security
> 243	draft-ietf-mboned-mroutesec
> 272	draft-ietf-l3vpn-as2547
> 272	draft-ietf-l3vpn-rfc2547bis
> 286	draft-holbrook-idmr-igmpv3-ssm
> 293	draft-ietf-ipsec-ikev2
> 297	draft-ietf-isis-igp-p2p-over-lan
> 303	draft-ietf-ipsec-ikev2-algorithms
> 303	draft-ietf-ipsec-ui-suites
> 332	draft-ietf-ipv6-node-requirements
> 332	draft-ietf-mboned-msdp-deploy
> 332	draft-ietf-mboned-ssm232
> 411	draft-ietf-ospf-graceful-impl-report
> 419	draft-ietf-magma-igmp-proxy
> 433	draft-ietf-ipoib-architecture
> 474	draft-ietf-imapext-condstore
> 495	draft-ietf-ospf-2547-dnbit
> 503	draft-ietf-magma-igmpv3-and-routing
> 516	draft-ietf-ipsec-ciph-aes-ccm
> 559	draft-ietf-magma-snoop
> 684	draft-ietf-mmusic-sdpng-trans
> 838	draft-ietf-idwg-beep-idxp
> 838	draft-ietf-idwg-requirements
> 853	draft-ietf-smime-symkeydist
> 
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Jul 2005 11:04:48 +0200

Opinion: for something that has already been approved by the IESG,
this would count as a substantive change - so I would recommend a mini
WG last call followed by a formal note to the AD, who should run it
past the IESG before a formal note is sent to the RFC Editor.

The reason I think it's substantive is that we tend to consider
normative reference problems worthy of a DISCUSS during IESG
evaluation. (Hmm. Not mentioned in draft-iesg-discuss-criteria-00.txt)

    Brian