Subject: RE: New ID-Checklist to replace ID-nits (fwd)

From: [email-masked]
Date: Sun, 23 May 2004 21:38:45 -0700

Hi Harald,

I am trying to check a document for my WG, and have a couple of
questions/comments.

1) Internet Draft boilerplate 

Section 2.2, 1: It MUST contain boilerplate that permits publication as an
RFC, see [RFC3667]Bradner, S., IETF Rights in Contributions, February 2004.,
Section 5.2.

Section 5.2 of 3667 does not seem to have a standard boilerplate, only the
two boilerplates that restrict IETF derivative works.  So, are we supposed
to use the 2026 boilerplate and replace 2026 with 3667?  The statement " Do
not add a numbered reference in the I-D boilerplate to RFC 3667 or RFC 3668
(or to RFC 2026 for older documents)." Section 2.1, 7 implies that the
boilerplate has been updated and references 3667.

2) The script refers to sections in 2026, but the ID-checklist indicates
using text verbatim from 3667 and 3668.

Thanks,

Elizabeth Rodriguez
-----Original Message-----
From: Harald Tveit Alvestrand [mailto:[email-masked]] 
Sent: Friday, May 21, 2004 7:54 AM
To: [email-masked]
Subject: New ID-Checklist to replace ID-nits (fwd)

I assume most of you saw this message on ietf-announce.
But since it's especially important to the WG chairs, I'm forwarding it to 
you directly.

Take care!

---------- Forwarded Message ----------
Date: 20. mai 2004 09:34 -0400
From: The IESG <[email-masked]>
To: IETF-Announce
Subject: New ID-Checklist to replace ID-nits

    As you probably all know, we have used the ID-nits for a few
    years to help you all to prepare your Internet-Drafts such that
    they will process faster through the AD-review, IETF Last Call
    and IESG approval process.

    The name was somewhat wrong in that it is more a serious checklist
    than merely "nits" (however, there are some nits too).
    The IESG, RFC-Editor and IANA have evaluated the checklist, and
    a new (improved) ID-Checklist is now available at

            http://www.ietf.org/ID-Checklist.html

    Please help us all by actually CHECKING your Internet-Draft BEFORE
    you pass it on to your AD and the IESG via a "request to publish".
    It will help to make the process go faster and reduce the workload
    on all of us if your document has been checked and complies with
    the guidance/rules in the ID-Checklist.

    Thanks, the IESG

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

---------- End Forwarded Message ----------

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 24 May 2004 10:36:51 +0200

Hi Elizabeth,

> boilerplate has been updated and references 3667.

FWIW, I enclose the boilerplate I've had some of the MIP4 authors use;
this also matches what the latest version of the xml2rfc produces.  As
far as I can see this complies fully with 3667 and 3668.

> using text verbatim from 3667 and 3668.

Not sure which script you're referring to, but if it is the 'idnits'
script, it looks at the draft and tries to determine whether the draft
is based on 2026 or 3667 boilerplate, and judges it accordingly.  A
future version will be strict in permitting 3667 only, but currently
there are a lot of drafts in flight based on 2026, so I going by the
'conform to either 2026 or 3667' approach for now.  Mmm, maybe I'll add
a switch which makes it 3667-strict now; with the updated ID-checklist
that seems reasonable.

	Henrik

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 24 May 2004 11:37:11 +0200

Hi Henrik and Harald,

One question concerning your boilerplate. Shouldn't your status of this 
memo section include the following paragraph?

"By submitting this Internet-Draft, I (we) accept the provisions of 
Section 3 of RFC 3667 (BCP 78)."

I am a bit confused that section 3 of RFC 3667 is for all drafts, why 
the text actually saying that they may be included is listed as "Notices 
and Rights Required in RFC Editor Contributions".

Shouldn't the above statement be always included except if the 
alternative one is included. Could I not otherwise claim that I am in 
fact not granting the IETF and ISOC the rights that are listed in 
section 3 of RFC 3667?

Clarification on this is highly appreciated.

Second, I thing that bullet 1 of section 2.2 of the ID-Checklist:

"1. Internet Draft boilerplate

It MUST contain boilerplate that permits publication as an RFC, see 
[RFC3667], Section 5.2."

Is rather insufficient and even erroneous for the job. I think one 
should have proper walk through here of the different elements needed in 
the "Status of this memo" section. To my understanding this consists of 
several different pieces:

A. The RFC 3668 IPR statement.

B. Possibly the RFC 3667 statements in Section 6.

C. Possibly limitation to copyright and publishing rights, according to 
section 5.2 of RFC 3667.

D. The "Internet draft" name disclaimer statement:

"Internet-Drafts are working documents of the Internet Engineering Task 
Force (IETF), its areas, and its working groups.  Note that other groups 
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months 
  and may be updated, replaced, or obsoleted by other documents at any 
  time.  It is inappropriate to use Internet-Drafts as reference 
material or to cite them other than as "work in progress"."

E. Pointer to current IDs and shadow directories:

 >
 >    The list of current Internet-Drafts can be accessed at
 >    http://www.ietf.org/ietf/1id-abstracts.txt .
 >
 >    The list of Internet-Draft Shadow Directories can be accessed at
 >    http://www.ietf.org/shadow.html .

Further I have also included in some draft included either of the 
following statements, to clearly indicate the document status. However I 
have now idea where I have got these from. However I think they are 
beneficial.

1. "This document is an individual submission to the IETF. Comments 
should be directed to the authors."

2. "This document is a submission of the IETF [#WG name] WG. Comments 
should be directed to the [#WG name] WG mailing list, [email-masked]."

How to build the previous "Status of this memo" section was previous 
indicated in the ID guideline:
http://www.ietf.org/ietf/1id-guidelines.txt

I think a similar page is needed also for the new text, and the old one 
should be removed, because currently there are contradicting guidelines.

Cheers

Magnus

Henrik Levkowetz wrote:

> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> 
> 	Draft Boilerplate conformant with RFC 3667 and 3668
> 	===================================================
> 
> 
> DRAFT INTRO:
> 
> ------------------------------------------------------------------------
> Status of this Memo
> 
>    By submitting this Internet-Draft, I certify that any applicable
>    patent or other IPR claims of which I am aware have been disclosed,
>    and any of which I become aware will be disclosed, in accordance with
>    RFC 3668.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as
>    Internet-Drafts.
> 
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress".
> 
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt .
> 
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html .
> 
>    This Internet-Draft will expire on ....................
> 
> Copyright Notice
> 
>    Copyright (C) The Internet Society (2004). All Rights Reserved.
> 
> ------------------------------------------------------------------------
> 
> 
> 
> DRAFT ENDING:
> ------------------------------------------------------------------------
> Intellectual Property Statement
> 
>    The IETF takes no position regarding the validity or scope of any
>    Intellectual Property Rights or other rights that might be claimed to
>    pertain to the implementation or use of the technology described in
>    this document or the extent to which any license under such rights
>    might or might not be available; nor does it represent that it has
>    made any independent effort to identify any such rights.  Information
>    on the procedures with respect to rights in RFC documents can be
>    found in BCP 78 and BCP 79.
> 
>    Copies of IPR disclosures made to the IETF Secretariat and any
>    assurances of licenses to be made available, or the result of an
>    attempt made to obtain a general license or permission for the use of
>    such proprietary rights by implementers or users of this
>    specification can be obtained from the IETF on-line IPR repository at
>    http://www.ietf.org/ipr.
> 
>    The IETF invites any interested party to bring to its attention any
>    copyrights, patents or patent applications, or other proprietary
>    rights that may cover technology that may be required to implement
>    this standard.  Please address the information to the IETF at
>    [email-masked].
> 
> 
> Disclaimer of Validity
> 
>    This document and the information contained herein are provided on an
>    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
>    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
>    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
>    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
>    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
>    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> Copyright Statement
> 
>    Copyright (C) The Internet Society (2004). This document is subject
>    to the rights, licenses and restrictions contained in BCP 78, and
>    except as set forth therein, the authors retain all their rights.
> 
> 
> Acknowledgment
> 
>    Funding for the RFC Editor function is currently provided by the
>    Internet Society.
> 
> ------------------------------------------------------------------------
> 

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 24 May 2004 15:10:16 +0200

Magnus, Harald, Scott, Bert

(I'm adding Scott and Bert - don't know if you are following this list)

I think the point you're making below is a good one Magnus, and if we
could agree on how this should be done and get it written out it'd
be excellent:

> Section 3 of RFC 3667 (BCP 78)."

As 3667 is written, you are deemed to agree to section 3.3 just by
submitting a draft - 3667 doesn't require you to acknowledge this.

BUT - since the boilerplate used by drafts in general is the most
immediately obvious pointer that readers and other authors have to
what applies, I think it would be good to include a paragraph with
this kind of acknowledgement.  On my part, I'd have expressed it as
a second paragraph, appearing after the initial 3667 Section 5.1
acknowledgement, or possibly as the first paragraph before the 3667(5.1)
ack.:

   "Submission of this draft is done with the understanding that the
   terms and conditions in Section 3.3 of RFC 3667 apply, and each
   contributor affirm that the items in Section 3.4 of RFC 3667 apply 
   to his or her contribution, to the best of his or her knowledge and 
   ability."

However this is maybe too longwinded - maybe a simple rephrasing of
the opening paragraph used up till now would be better:

   "This document is an Internet-Draft and is in full conformance with
   all provisions of RFC3667."

Scott? Bert?

> Clarification on this is highly appreciated.

Agree.  As for the following, I think it might also be a good
idea, although I don't know if it belongs in the ID-checklist
or in a separate document...

	Henrik

	Henrik

-- 
  Experience is something you don't get until just after you need it.

---

From: [email-masked] (Scott Bradner)
Date: Mon, 24 May 2004 09:26:50 -0400 (EDT)

> submitting a draft - 3667 doesn't require you to acknowledge this.

that is correct, RFC 3667 does not require you to acknowledge agreement
with RFC 3667 sec 3.3 - 

I do not think that there needs to be such an acknowledgement (legally)
but it would not hurt to do so - if someone wants to include such an
acknowledgement I'd suggest

  "This document is an Internet-Draft and is subject to all provisions
  of section 3 of RFC 3667."

(use of "accept" can be a problem in some cases where the document
has been placed in the public domain)

Scott

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 25 May 2004 12:43:58 -0700

Hi -

It would be *really* nice if RFC 2223bis explicitly said where to put
all these new incantations.  The ID-Checklist *should* just be summary
of the items from RFC 223bis that are legally motivated or frequently
gotten wrong.

Randy

> From: "Scott Bradner" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Monday, May 24, 2004 6:26 AM
> Subject: Re: New ID-Checklist to replace ID-nits (fwd)
>