headers
Lucy Lynch | 16 Feb 22:39

Request for input (patchwork RFCs)

All -

At the behest of the IAOC, I recently published a draft:

"Tasks previously assigned to the IETF Executive Director"
http://www.ietf.org/internet-drafts/draft-lynch-execd-tasks-00.txt

Which was intended to tidy up some issues left over from our
pre-BCP 101 days:

    "BCP 101 [RFC4071] requires the IETF Administrative Oversight
    Committee to "designate, in consultation with the IAB and the IESG,
    the person or people who carry out the tasks that other IETF process
    documents say are carried out by the IETF Executive Director."  The
    purpose of this document is to document the agreed designations.

    The RFCs updated by this document are all those that have not already
    been obsoleted which assign tasks to the IETF Executive Director
    (sometimes abbreviated as ExecD).  Note that there is no relationship
    to the IAB Executive Director.

    In general the tasks concerned are well defined and closely linked to
    other duties of the IETF Secretariat.  Therefore, in what follows,
    almost all of them are re-assigned to the Secretariat.  It is
    expected that they will normally be performed by the person occupying
    the role of Head of Secretariat."

The document kicked off a short discussion about "patchwork RFCs"
in the IPR-WG:
(Continue reading)

Permalink | Reply | 0 comments |
headers
John C Klensin | 16 Feb 23:20

Re: Request for input (patchwork RFCs)

Lucy,

It seems to me that anything that the IAOC feels able to do 
without formally asking for community consensus is a candidate 
for an ION unless its significance is so broad that permanent/ 
archival RFC documentation is appropriate.  I believe that IAOC 
should be able to make that decision, ideally announcing it in a 
way that would permit an appeal if someone felt the decision was 
seriously out of whack.

For this particular draft, I think that translates into "you 
decide".   If I were deciding I would recommend ION, but that is 
just because I aspire to be a charter member of the "keep 
unnecessary administrative clutter out of the RFC Series" club.

     john

--On Friday, February 16, 2007 13:39 -0800 Lucy Lynch 
<llynch <at> civil-tongue.net> wrote:

> All -
>
> At the behest of the IAOC, I recently published a draft:
>
> "Tasks previously assigned to the IETF Executive Director"
> http://www.ietf.org/internet-drafts/draft-lynch-execd-tasks-00
> .txt
>
> Which was intended to tidy up some issues left over from our
> pre-BCP 101 days:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Hoffman | 16 Feb 23:24

Re: Request for input (patchwork RFCs)

At 1:39 PM -0800 2/16/07, Lucy Lynch wrote:
>So, my question to the community, as the author of this admittedly
>pitiful draft is:
>
>Should I withdraw the draft and publish it as an IAOC approved ION?

Yes. It is a great use of IONs.

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Permalink | Reply | 0 comments |
headers
Lucy Lynch | 16 Feb 23:40

Re: Request for input (patchwork RFCs)

On Fri, 16 Feb 2007, John C Klensin wrote:

> Lucy,
>
> It seems to me that anything that the IAOC feels able to do without formally 
> asking for community consensus is a candidate for an ION unless its 
> significance is so broad that permanent/ archival RFC documentation is 
> appropriate.  I believe that IAOC should be able to make that decision, 
> ideally announcing it in a way that would permit an appeal if someone felt 
> the decision was seriously out of whack.
>
> For this particular draft, I think that translates into "you decide".   If I 
> were deciding I would recommend ION, but that is just because I aspire to be 
> a charter member of the "keep unnecessary administrative clutter out of the 
> RFC Series" club.

Sign me up! Is there a secret handshake? Do I get to wear a fez?

>    john
>
>
>
>
> --On Friday, February 16, 2007 13:39 -0800 Lucy Lynch 
> <llynch <at> civil-tongue.net> wrote:
>
>> All -
>> 
>> At the behest of the IAOC, I recently published a draft:
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steven M. Bellovin | 17 Feb 02:12

Re: Request for input (patchwork RFCs)

On Fri, 16 Feb 2007 14:40:12 -0800 (PST)
Lucy Lynch <llynch <at> civil-tongue.net> wrote:

> 
> Sign me up! Is there a secret handshake? Do I get to wear a fez?
>
We use public key handshakes these days.  And it's f(e)^z.  All of this
is spelled out in the Security Considerations section of that club.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb
Permalink | Reply | 0 comments |
headers
Harald Alvestrand | 27 Feb 16:57
Picon

Call for issues, -outgoing document

Hello folks,

it is time (and past time) to prepare for the March IPR WG meeting.

We have:
- An -outgoing document where the editor has attempted to update it with 
the consensus items from our San Diego meeting

- An -incoming document hot off the presses (in fact, it isn't published 
yet), containing the principles and legal language that we need to put 
up on the "grants of rights to the IETF" side.

These 2 documents will obviously be the agenda items in Prague.

In preparation for that, I'd like all of you to mail your issues with 
the OUTGOING document to the mailing list.

To raise an issue, send mail to the mailing list saying "ISSUE: Outgoing 
<section>: <subject>".

The chairs will enter an issue in the tracker if one or more of the 
following things is true:
- the chairs agree it is an issue that needs discussion
- one or more persons apart from the person raising the issue agrees 
that it is an issue, and says so on the mailing list ("+1" can be used, 
but be clear on what you're responding to - +1 on a refutation is not 
the same as +1 on the original issue!)

The chairs will not enter an issue in the tracker if:
- they don't think it is an issue
(Continue reading)

Permalink | Reply | 1 comment |
headers
Internet-Drafts | 1 Mar 21:50
Picon
Favicon

I-D ACTION:draft-ietf-ipr-3978-incoming-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Intellectual Property Rights Working Group of the IETF.

	Title		: Rights Contributions provide to the IETF Trust
	Author(s)	: S. Bradner, J. Contreras
	Filename	: draft-ietf-ipr-3978-incoming-00.txt
	Pages		: 18
	Date		: 2007-3-1
	

   The IETF policies about rights in Contributions to the IETF are
   designed to ensure that such Contributions can be made available to
   the IETF and Internet communities while permitting the authors to
   retain as many rights as possible. This memo details the IETF
   policies on rights in Contributions to the IETF. It also describes
   the objectives that the policies are designed to meet.  This memo
   obsoletes RFC 3978 and, with RFC 3979 and RFC xxx (-outgoing),
   replaces Section 10 of RFC 2026.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipr-3978-incoming-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
(Continue reading)

Permalink | Reply | 5 comments |
headers
Brian E Carpenter | 2 Mar 11:26
Picon
Favicon

Re: I-D ACTION:draft-ietf-ipr-3978-incoming-00.txt

I don't much care whether the rationale comes before
or after the normative content, but they need to be
very clearly separated and labelled as such. For example
the trademark section is hidden after the rationale.

> 2. Introduction
...
>    In order for works to be used within the IETF Standards Process or to
>    be published as Internet-Drafts, certain limited rights in all
>    Contributions must be granted to the IETF Trust and the IETF. In
>    addition, Contributors must make representations to IETF Trust and
>    the IETF regarding their ability to grant these rights. These
>    necessary rights and representations have until now been laid out in
>    Section 10 of [RFC2026]. In the years since [RFC2026] was published
>    there have been a number of times when the exact intent of Section 10
>    has been the subject of vigorous debate within the IETF community.
>    The aim of this document is to clarify various ambiguities in Section
>    10 of [RFC2026] that led to these debates and to amplify the policy
>    in order to clarify what the IETF is currently doing.

This text needs to be updated to refer to RFC 4748, 3978 and 3667.

> 2.1 No Retroactive Effect
>    This memo does not retroactively obtain additional rights from
>    Contributions that predate the publication of this memo as a RFC.

I would prefer this to read
   "that predate the approval for publication..."
so that we don't have an ambiguous interregnum while this document
is in the RFC queue.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian E Carpenter | 2 Mar 12:07
Picon
Favicon

Re: IANA-maintained MIB copyright question

On 2007-01-29 19:33, Harald Tveit Alvestrand wrote:
> 
> 
> --On 29. januar 2007 09:48 +0100 Brian E Carpenter <brc <at> zurich.ibm.com> 
> wrote:
> 
>> I believe Jorge has recommended (2003-2007), which would
>> require an annual update.
>>
>> I fear it can't be an ION for the simple reason that the
>> existing URL is embedded in the MIBs concerned.
> 
> Not logical. The MIBs don't say anything about what's at the other end 
> of that URL.
> It could be a pointer to an ION as easily as it could be any other web 
> page. (And if the ION experiment is deemed a failure, we just point the 
> pointer somewhere else).
> 
>> And I
>> think in the end it's an operational detail that the
>> Trust and IASA should take care of.
> 
> Agreed.
> 

For now, following the approval of draft-heard-rfc4181-update-00.txt,
I have asked the secretariat to make the necessary update of
http://www.ietf.org/copyrights/ianamib.html

     Brian
(Continue reading)

Permalink | Reply | 1 comment |
headers
Simon Josefsson | 2 Mar 12:16
Favicon
Gravatar

Section 7 of draft-ietf-ipr-3978-incoming-00.txt normative or not?

Please clarify whether section 7 is normative or not.

I recall that Scott Bradner referenced to section 7 as an argument
that the IETF policy grants third parties various rights, but I
believe such an argument is flawed.  The title of section 7 is:

7. Exposition of Why These Procedures Are the Way They Are

Thus I believe the entire chapter was intended to be non-normative.

It is unfortunate that text in section 7 may not appear to say the
same as the normative part of the document, but making it clear that
section 7 is non-normative would be a good starting point.  We can fix
the factual problems in section 7 later.

Therefor, I suggest inserting as the first sentence in section 7 the
following:

   This entire section is not normative.  Thus, in case of conflict
   with normative text on a subject, the normative text has priority.

What do you think?

/Simon
Permalink | Reply | 0 comments |

Gmane