Subject: Re: Last Call: draft-legg-xed-asd (Abstract Syntax Notation X (ASN.X)) to Proposed Standard

From: Simon Josefsson <[email-masked]>
Date: Sat, 13 Jan 2007 11:21:50 +0100

Hi!  These documents contains normative ASN.1 modules which, if I
understand the documents correctly, is typically included in
implementations of this standard.  Is that correct?

The modules contain this notice:

   -- Copyright (C) The IETF Trust (2006). This version of
   -- this ASN.1 module is part of RFC XXXX; see the RFC itself
   -- for full legal notices.

The legal notices used by the IETF doesn't grant third parties
(including implementers of your standard) the right to include
portions of documents in their implementations.  The rights granted by
RFC 3978/4748 in section 3.3, including the right to extract code
portions from documents, are only granted to "IETF Trust and the
IETF", and there is no other license to indicate that any similar
rights are granted to third parties.

This raises problems for some implementers, because they can't
implement your standard if they use the ASN.1 module.  The alternative
for them, to re-specify the ASN.1 module from the text (if that is at
all possible), is bad for interoperability.  If you want to enable
smooth implementation of your standard by everyone (which I hope!),
here is how to solve it:

There are several solutions to this problem.  A simple solution that
has been used successfully in several documents (RFC 3492, RFC 4398
and a few others) is to add, after the above notice, the following
notice:

   -- Regarding this entire document or any portion of it (including
   -- the pseudocode and C code), the author makes no guarantees and
   -- is not responsible for any damage resulting from its use.  The
   -- author grants irrevocable permission to anyone to use, modify,
   -- and distribute it in any way that does not diminish the rights
   -- of anyone else to use, modify, and distribute it, provided that
   -- redistributed derivative works do not contain misleading author
   -- or version information.  Derivative works need not be licensed
   -- under similar terms.

Note that should be added to all places where the notice about IETF
Trust and legal notices are added.

This notice would give third parties the necessary rights they need to
be able to use the normative ASN.1 module from your documents.

Btw, you'd might want to modify the text slightly, so that "pseudocode
and C code" becomes "ASN.1 module".  If you don't want to grant the
rights to the entire document, grant them only for the ASN.1 module.

Best regards, and thanks in advance,
Simon

The IESG <[email-masked]> writes:

> The IESG has received a request from an individual submitter to consider
> the following documents:
>
> - 'Abstract Syntax Notation X (ASN.X) Representation of Encoding 
>    Instructions for the XML Encoding Rules (XER) '
>    <draft-legg-xed-asd-xerei-03.txt> as a Proposed Standard
> - 'Encoding Instructions for the Robust XML Encoding Rules (RXER) '
>    <draft-legg-xed-rxer-ei-04.txt> as a Proposed Standard
> - 'Abstract Syntax Notation X (ASN.X) Representation of Encoding 
>    Instructions for the Generic String Encoding Rules (GSER) '
>    <draft-legg-xed-asd-gserei-03.txt> as a Proposed Standard
> - 'Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One 
>    (ASN.1) '
>    <draft-legg-xed-rxer-07.txt> as a Proposed Standard
> - 'Abstract Syntax Notation X (ASN.X) '
>    <draft-legg-xed-asd-07.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2007-02-14. Exceptionally, 
> comments may be sent to [email-masked] instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-legg-xed-asd-xerei-03.txt
> http://www.ietf.org/internet-drafts/draft-legg-xed-rxer-ei-04.txt
> http://www.ietf.org/internet-drafts/draft-legg-xed-asd-gserei-03.txt
> http://www.ietf.org/internet-drafts/draft-legg-xed-rxer-07.txt
> http://www.ietf.org/internet-drafts/draft-legg-xed-asd-07.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=10739&rfc_flag=0

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 13 Jan 2007 12:50:05 -0500

Simon, you are mixing several issues in your note, including strictly 
legal issues and personal preferences.

Firstly, it is clear that you (and every other implementor using this 
document) needs the ability to extract and use the ASN.1 include in 
the document.  That is already provided for in BCP 78.  The text he 
included is exactly the text that BCP 78 tells him to include to do 
that.  So there is no problem there.

Secondly, there is the agreement that implementors, in practice need 
the right to modify the code.
BCP 78 in section 3.3 E grants the IETF Trust the rights to make such 
code changes, even for use outside the IETF Standards Process.   This 
appears to mean that the IETF Trust can grant the rights that are 
needed.  Steven does not need to make any changes to achieve that.

Then, you go further and ask him to grant modification rights to all 
of the text, not just the code / ASN.1 components.  While you have a 
clearly stated preference for that grant, it is unfair and 
inappropriate of you to assert that the need for that is inherent in 
the problem you raise of implementor modification.

So, in summary, while I agree that you need the right to modify the 
ASN.1, I don't think there is anything that can or should be done in 
the document to address that.  The document already has the 
boilerplate components intended to permit that.
If some extra text is needed to ensure modifiablity of the code, it 
should be the code, and not "this entire document or any portion of it."

Yours,
Joel M. Halpern

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 13 Jan 2007 21:38:16 +0100

> legal issues and personal preferences.

I bring up only one issue here: Can implementers extract and use the
ASN.1 module for their implementations legally?

> that.  So there is no problem there.

I explained in my note that BCP 78 does _not_ provide for that.  If
you disagree with that, I think you need to show where BCP 78 gives
third parties the right to extract and use the ASN.1 module.

> needed.  Steven does not need to make any changes to achieve that.

Sure.  My point is that the implementers are not granted these rights.
What rights the IETF Trust are granted seems irrelevant.

> the problem you raise of implementor modification.

If you read my note again, and especially the last paragraph, you will
see that I quoted the text from RFC 3492 and then said that he might
want to restrict the additional rights that are granted to only the
ASN.1 module.  I think it is unfair to accuse me of asserting that
adding exactly that text is required.  There are many ways to solve
this problem, and I clearly said so.

> boilerplate components intended to permit that.

No.  The boilerplate present does not give me as third party the right
to extract and use the ASN.1 module.

> should be the code, and not "this entire document or any portion of

That is up to the each author to decide, of course.

Thanks,
Simon

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 13 Jan 2007 16:10:40 -0800

Hi -

> From: "Simon Josefsson" <[email-masked]>
> To: "Joel M. Halpern" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Saturday, January 13, 2007 12:38 PM
> Subject: Re: Last Call: draft-legg-xed-asd (Abstract Syntax Notation X(ASN.X)) to Proposed Standard
...
> third parties the right to extract and use the ASN.1 module.
...

Section 5.2 of RFC 3978 addresses the issue, giving the necessary
incantation and using MIBs and PIBs as an example.  There's nothing
about an ASN.1 module in this regard that's any different from PIBs
and MIBs.

Randy

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sat, 13 Jan 2007 22:05:35 -0500

On Sat, 13 Jan 2007 21:38:16 +0100
Simon Josefsson <[email-masked]> wrote:

> > Simon, you are mixing several issues in your note, including
> > strictly legal issues and personal preferences.
> 
> > Firstly, it is clear that you (and every other implementor using
> > this document) needs the ability to extract and use the ASN.1
> > include in the document.  That is already provided for in BCP 78.
> > The text he included is exactly the text that BCP 78 tells him to
> > include to do that.  So there is no problem there.
> 

And as you very well know, the IPR working group is fixing the
problem.  I think a pointer to the archives there would have sufficed
(or at least a mention of the discussion and status).

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 14 Jan 2007 12:10:52 +0100

> about an ASN.1 module in this regard that's any different from PIBs

Hi!  The notices required by section 5.2 are not present in these
documents, so that section doesn't apply.

Btw, I don't think you meant to refer to section 5.2, since that is
normally not used for standards track documents:

   These notices may not be used with any standards-track document or
   with most working group documents, except as discussed in Section 7.3
   ...

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 14 Jan 2007 12:31:19 +0100

> (or at least a mention of the discussion and status).

The mailing list archives doesn't contain a clear description of the
problem.  In any case, the effort in the IPR WG seem to be a
multi-year effort, and it is not certain to me that the changes
ultimately made will fix the problem I brought up here or apply
retro-actively to these documents.  A reference to the mailing list
[1] for the problem statement might have been useful, but it does not
provide a solution for these documents.

If these documents should be possible to implement by third parties
before the IPR WG is finished with its goals, additional text is
necessary in these documents.  Adding such text is what I propose.

As Joel suggested, another choice of wordings that only gives
additional rights to the parts that needs to be extracted would be
(paraphrasing RFC 3492):

   Regarding this section, the author makes no guarantees and is not
   responsible for any damage resulting from its use.  The author
   grants irrevocable permission to anyone to use, modify, and
   distribute it in any way that does not diminish the rights of
   anyone else to use, modify, and distribute it, provided that
   redistributed derivative works do not contain misleading author or
   version information.  Derivative works need not be licensed under
   similar terms.

To avoid confusion, I want to stress that other alternatives are
conceivable.  (However, placing the code under a MIT/BSD license,
which would appear to be a simple solution, is not an option (at least
not without approval by the IAB), since additional copyright notices
are not permitted by BCP 78).

/Simon

[1] http://www1.ietf.org/mail-archive/web/ipr-wg/current/index.html

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 15 Jan 2007 09:47:06 +0100

On Sat, Jan 13, 2007 at 10:05:35PM -0500,
 Steven M. Bellovin <[email-masked]> wrote 
 a message of 34 lines which said:

> problem.

Is working on the problem. It is not the same thing. Nothing indicate
that it will be fixed, specially since some people even deny there is
a problem.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 15 Jan 2007 09:57:56 +0100

On Sat, Jan 13, 2007 at 04:10:40PM -0800,
 Randy Presuhn <[email-masked]> wrote 
 a message of 31 lines which said:

> incantation and using MIBs and PIBs as an example.

You really need to be more specific because I'm hopelessly confused
here. Section 5.2 talks about the *opposite*, how to give *less*
rights.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 15 Jan 2007 07:14:36 -0500

On Mon, 15 Jan 2007 09:47:06 +0100

> that it will be fixed, specially since some people even deny there is
Actually, I think we're quite close to a consensus document that does
solve the embedded code problem.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Jan 2007 16:03:21 +0100

I would refer you to the IETF Trust FAQ on RFC copyright,
http://trustee.ietf.org/24.html, point 6 and point 9.

     Brian

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 15 Jan 2007 16:49:00 +0100

> http://trustee.ietf.org/24.html, point 6 and point 9.

Interesting.  Point 6 seem incorrect to me, as there is nothing in BCP
78 that permits computer code extracts from RFC for third parties.  I
believe the IPR WG has established that point.  Point 9 seem
irrelevant since the IETF Trust doesn't (by point 1) own the copyright
on code in RFCs.

I think the FAQ should be updated to reflect the perception of the
problem being solved by the IPR WG.  You may also want to update point
3 to mention RFC 4748.  Adding contact information to the page, and in
particular, whether it was written with advice from a lawyer familiar
with BCP 78 would be useful.

/Simon

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 15 Jan 2007 08:07:09 -0800

Hi -

> From: "Stephane Bortzmeyer" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, January 15, 2007 12:57 AM
...
> here. Section 5.2 talks about the *opposite*, how to give *less*

|   In the cases of MIB or PIB modules and in other cases where the
|   Contribution includes material that is meant to be extracted in order
|   to be used, the following should be appended to statement 5.2 (a) or
|   5.2 (b):
|
|      "other than to extract section XX as-is for separate use."

Sorry, the incantation was so clear to me that I missed the over-qualification.

Randy