Re: IETF Last Call for two IPR WG Dcouments

[Olaf Kolkman]

On Mar 27, 2008, at 10:28 PM, Brian E Carpenter wrote:

While not really disagreeing with Leslie and Olaf, I would
point out that the IPR WG was chartered to look at
IETF documents.


Those being ietf-stream exclusively or implicitly also covering the  
iab-stream?


Personally, I think it makes sense that the iab-stream is covered, but  
let me put that in front of the IAB too.



We can have a meta-discussion about
where the clarifications belong, but it seems to me
that the WG consensus definitely assumed that scope
and no wider scope. I'd be happy if that was made
clear in the drafts, rather than trying to cover
the other documents streams by some kind of awkward
retro-fit.



My suggestion is to rewrite  section 4 a bit to call out that this  
document does not cover the incoming rights for the independent and  
irtf stream and to use the terms "ietf-stream" and possibly "iab- 
stream" in the definitions.


Such a rewrite would preserve the status quo for the independent and  
irtf stream.



no-hats,

--Olaf




On Mar 27, 2008, at 10:28 PM, Brian E Carpenter wrote:

While not really disagreeing with Leslie and Olaf, I would
point out that the IPR WG was chartered to look at
IETF documents. We can have a meta-discussion about
where the clarifications belong, but it seems to me
that the WG consensus definitely assumed that scope
and no wider scope. I'd be happy if that was made
clear in the drafts, rather than trying to cover
the other documents streams by some kind of awkward
retro-fit.

  Brian

On 2008-03-28 08:15, Leslie Daigle wrote:


--On March 27, 2008 10:33:24 AM +0100 Olaf Kolkman  
<[EMAIL PROTECTED]>

wrote:
I would think that the document would gain in clarity if it  
explicitly
ties the incoming rights to the streams as defined in RFC4844 and  
also
explicitly calls out that if new streams would be defined those  
should
specifically define if and how rights are transferred to the IETF  
Trust.


I would have to agree with the above, and say further that the
the IAB should make sure that the entities responsible for
the non-IETF streams are okay with the result.

When writing the streams definitions, it was clear that there was a
lot of material that was spread across existing documents without
clear delineation between "IETF" or "non-IETF" documents, let
alone further refinement into what has become "streams".  THat's
understandable, historically, but we should be clearer going
forward.  Breaking it out, as you suggest, would be consistent
with that goal.

Leslie.



While reviewing the documents I tried to determine how the 4 streams
currently defined in RFC4844 fit into the framework.

Although the stream is not specifically mentioned it is clear that  
the

incoming rights document applies to the IETF Stream.

To me it is clear that a contribution to the IAB is explicitly  
bound by

the rules (including the No Duty to Publish rule, that allows for
confidential information to be supplied to the IAB), so are  
contributions
from the IAB, i.e. IAB stream document. I conclude this from the  
fact
that "IAB" is part of the IETF under the definition in 1.e.  
However, I
may be over-interpreting, and the status of the incoming rights  
for the

IAB stream is also not captured.

The independent stream document are clearly excluded by section 4  
of the

document.

It is not quite clear where the IRTF stream document live. This  
could be

fixed in a document which defines the IRTF stream.

I would think that the document would gain in clarity if it  
explicitly
ties the incoming rights to the streams as defined in RFC4844 and  
also
explicitly calls out that if new streams would be defined those  
should
specifically define if and how rights are transfered to the IETF  
Trust.




--Olaf (no hats)






___
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




PGP.sig
Description: This is a digitally signed message part
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-wu-sava-testbed-experience (SAVA Testbed and Experiences to Date) to Experimental RFC

[Jari Arkko]

Thanks for your review, Pekka. A few notes:

> it doesn't go into much detail on how they solved 
> difficult and more interesting issues, for example:
>   - how they solved MTU problems caused by adding hop-by-hop header
>   - given their deployment model, why didn't they try inserting a destination 
> options
> header instead of hop-by-hop and if they tried, why it didn't work;
>   - how did the rekeying of inter-AS solution work (not described)
>
> These would increase the value of the report.

This would be very useful addition to the document. Authors?

But note that the overall experience from the specific approach chosen
here was that yes, its possible get it to working, but there are
significant issues both for deployment and for the way the protocol bits
are arranged. Remember that this was an experiment, not a design ready
for standardization. MTU problems are in the list that is in Section 5.3.

> I object to 
> publishing the draft as written. At least issue 1) below needs to be 
> fixed before publication because the draft is confusing and 
> misrepresentative of the scope of existing solution solution space.
>
> 1) Access Network SAV and Intra-AS SAV terminology misrepresents the
> applicability of BCP38/84 and needs to be rephrased.
>
> We use the term "intra-AS source address validation" to mean the IP
> source address validation at the attachment point of an access
> network to its provider network, also called the ingress point.  IP
> source address validation at ingress points can enforce the source IP
> address correctness at the IP prefix level, assuming the access
> network owns one or more IP address blocks.  This practice has been
> adopted as the Internet Best-Current-Practice [RFC2827][RFC3704].
>
> This text (also to some degree the previous paragraph) and Figure 1 
> are confusing.  In Figure 1, Intra-AS SAV occurs between two routers 
> is construed as if it was only applicable between routers. BCP38 and 
> BCP84 are applicable also in scenarios which are in the figure listed 
> under "Access Network SAV", not just under intras-AS SAV. 
> Specifically, BCP38/84 can be applied on each LAN interface of a 
> router.  In case router connects just one host, that is also a 
> sufficient solution and nothing else is needed.
>   

Right. This needs to be corrected in the draft.

I am not commenting on the remaining issues, but I expect the authors to
address them in a new revision of their document.

Jari

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

Re: IETF Last Call for two IPR WG Dcouments

[Simon Josefsson]

Regarding -outbound section 4.3:

   IETF contributions often include components intended to be directly
   processed by a computer.  Examples of these include ABNF definitions,
   XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values,
   MIBs, ASN.1, or classical programming code.  These are included in
   IETF contributions for clarity and precision in specification.  It is
   clearly beneficial, when such items are included in IETF
   contributions, to permit the inclusion of such code components in
   products which implement the contribution.  It has been pointed out
   that in several important contexts use of such code requires the
   ability to modify the code.  One common example of this is simply the
   need to adapt code for use in specific contexts (languages,
   compilers, tool systems, etc.)  Such use frequently requires some
   changes to the text of the code from the IETF contribution.  Another
   example is that code included in open source products is frequently
   licensed to permit any and all of the code to be modified.  Since we
   want this code included in such products, it follows that we need to
   permit such modification.  While there has been discussion of
   restricting the rights to make such modifications in some way, the
   rough consensus of the IETF is that such restrictions are likely a
   bad idea, and are certainly very complex to define.

   As such, the rough consensus is that the IETF Trust is to grant
   rights such that code components of IETF contributions can be
   extracted, modified, and used by anyone in any way desired.  To
   enable the broadest possible extraction, modification and usage, the
   IETF Trust should avoid adding software license obligations beyond
   those already present in a contribution.  The granted rights to
   extract, modify and use code should allow creation of derived works
   outside the IETF that may carry additional license obligations.
...

I believe the intention here is good, but it leaves the IETF Trust with
no guidelines on how to write the license declaration that is likely to
work well in practice with actual products.  There are no reference to
what "open source" means in this context, and references to "free
software" is missing.

I believe it would be a complete failure if code-like portions of RFCs
cannot be included into open source and free software products such as
the Debian project.

To give the Trust something concrete to work with I propose to add the
following:

  To make sure the granted rights are usable in practice, they need to
  at least meet the requirements of the Open Source Definition [OSD],
  the Free Software Definition [FSD], and the Debian Free Software
  Guidelines [DFSG].

For those who fear that this will lead to complexity: releasing
something that is compatible with those requirements is simple.  The
modified BSD license meets those requirements, as does a number of other
methods, including releasing the work into the public domain.

The references being:

[OSD] "The Open Source Definition",
  http://opensource.org/docs/osd

[FSD] "The Free Software Definition",
  http://www.fsf.org/licensing/essays/free-sw.html

[DFSG] "The Debian Free Software Guidelines",
  http://www.debian.org/social_contract#guidelines

Thanks,
Simon

Russ Housley <[EMAIL PROTECTED]> writes:

> During the Wednesday Plenary at IETF 71, I gave the IETF community a 
> "heads up" on two documents from the IPR WG that were nearing IETF 
> Last Call.  Both of the documents have now reached IETF Last 
> call.  The Last Call announcements are attached.  Please review and comment.
>
> Russ
>
> == == == == == == == == == ==
>
> To: IETF-Announce <[EMAIL PROTECTED]>
> From: The IESG <[EMAIL PROTECTED]>
> Subject: Last Call: draft-ietf-ipr-outbound-rights (Advice to the
>  Trustees of the IETF Trust on Rights to be Granted in IETF
>  Documents) to Informational RFC
> Date: Wed, 19 Mar 2008 15:15:56 -0700 (PDT)
> Cc: [EMAIL PROTECTED]
>
> The IESG has received a request from the Intellectual Property Rights WG
> (ipr) to consider the following document:
>
> - 'Advice to the Trustees of the IETF Trust on Rights to be Granted in
> IETF Documents '
>  as an Informational RFC
>
> 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
> ietf@ietf.org mailing lists by 2008-04-02. Exceptionally,
> comments may be sent to [EMAIL PROTECTED] 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-ietf-ipr-outbound-rights-06.txt
>
> This document is closely related to draft-ietf-ipr-3978-incoming.
> The two documents should be considered as a set.  IETF Last Call for
> draft-ietf-ipr-3978-incoming will begin as soon as the next update is
> posted.
>
> IESG discussion can be tracked via
> ht

Re: Last Call: draft-wu-sava-testbed-experience (SAVA Testbed and Experiences to Date) to Experimental RFC

[Pekka Savola]

On Fri, 28 Mar 2008, Jari Arkko wrote:
> This would be very useful addition to the document. Authors?
>
> But note that the overall experience from the specific approach chosen
> here was that yes, its possible get it to working, but there are
> significant issues both for deployment and for the way the protocol bits
> are arranged. Remember that this was an experiment, not a design ready
> for standardization. MTU problems are in the list that is in Section 5.3.

A lot of issues are brought up in Section 5 (and elsewhere).  For 
issues noted, for each I'd like to ask quostions such as:
  - was this noticed in the testbed?  how?
  - was the issue relevant in that context; if not, why not?
  - if the issue was noticed, how was it worked around?  which
approaches worked (in that restricted context), which did not?
  - if the issue was not worked around, what kind of impact not
doing so had in the testbed and in testing?

I suspect some of the issues listed were addressed in some way (not 
necessarily in a globally applicable way).  For example, wrt MTU 
issues, a statement like "MTU increase was not an issue because the 
transit network provided 9000B MTU" or "Participating hosts were 
manually configured to use 1280B MTU" would have been useful.

So, when reading the report, I find it has basically the following 
kinds of content:
  1) some general overview of the problem space
  2) description of new mechanisms developed
  3) description of the testbed where mechanisms were tested
  4) description of issues to be considered in future work

However, 4) seems to be mainly about 1) and 2); it would have been 
possible to write fundamentally the same draft without any significant 
testbed deployment.  In other words, the experiences from the testbed 
and deployment itself are not extensively captured in the report, and 
as a result it is not obvious how useful the testbed was when 
considering follow-up activities in this space.

-- 
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-wu-sava-testbed-experience (SAVA Testbed and Experiences to Date) to Experimental RFC

[Jari Arkko]

> For issues noted, for each I'd like to ask quostions such as:
>  - was this noticed in the testbed?  how?
>  - was the issue relevant in that context; if not, why not?
>  - if the issue was noticed, how was it worked around?  which
>approaches worked (in that restricted context), which did not?
>  - if the issue was not worked around, what kind of impact not
>doing so had in the testbed and in testing?
Yes, this would be useful.

Jari

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

RE: Last Call: draft-klensin-rfc2821bis

[michael.dillon]

> >> OTOH, I think standardizing this convention makes all 
> sorts of sense, 
> >> but not, of course, in 2821bis.
> > 
> > Why not in 2821bis?  Is 2821bis really that time critical?
> 
> It is on its way to Draft Standard.  This would be a 
> sufficiently new feature to force recycle at Proposed, which, 
> to put it mildly, would not be welcomed by the editor or, 
> more important, those who convinced me to do the work.

Let me throw another idea into the mix. What if we were to
recommend a transition architecture in which an MTA host
ran two instances of the MTA software, one binding only to
IPv4 addresses, and the other binding to only IPv6 addresses.
Assume that there will be some means for the two MTA software
instances to exchange messages when their DNS queries return
the wrong kind of addresses (A or ). The IPv4 MTA can 
continue to use the rules regarding MX records with A record
fallback. The IPv6 MTA could require SRV records to identify
destinations and have no  fallback.

It immediately seems obvious that some issues surrounding 
an architecture of email systems during the IPv4-IPv6 transition,
are well out of scope of RFC28821bis. Therefore, I suggest that
2821bis move forward and that people interested in documenting
email transition strategies discuss this with the Application
area AD's. Such work should not be done without some form of
outreach to operational groups such as MAAWG since email operators
are quite likely to do whatever makes operational sense without
regard to IETF documents. Unless, of course, email operators
are highly involved in writing such documents.

--Michael Dillon
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-klensin-rfc2821bis

[Douglas Otis]

On Mar 27, 2008, at 8:31 PM, Keith Moore wrote:
> David Morris wrote:
>>
>> Perhaps you could help us out and share a reference to  
>> documentation of such problems. I for one have not personally  
>> observed any problems related to using the A record to locate a  
>> mail server when there is no MX.
>
> part of the problem is that most hosts don't wish to receive mail  
> but there is no way to indicate this to a mailer that is trying to  
> deliver mail to them.

Agreed.  Although MX records provide a discovery method for SMTP  
services, fall-back to A records prevents an assertion of no SMTP  
services when A records exist at the domain.

> if the host has an A record, under the current specifications, a  
> mailer that gets a message (presumably spam) with a recipient  
> address at that domain is expected to try to deliver that message.   
> and unless that host implements a dummy SMTP server that refuses all  
> incoming mail with a permanent error the sending mailer will keep  
> getting "connection refused" - which is treated as a temporary error  
> and the sending mailer will keep retrying.  this clogs up mail queues.

As John Levine pointed out, a message with an originating email- 
address referencing a domain only containing  records is likely to  
be refused.  In part to avoid potential issues handing NDNs as Frank  
suggested, and in part that each IPv6 hostname offers a vast number of  
domains and addresses that can be exploited as a spoofed source due to  
the RFC2821bis fallback specifically including IPv6  records.

> and the dummy SMTP server works, but it consumes resources on the  
> host and eats bandwidth on the network.  having a way to say "don't  
> send this host any mail" in DNS seems like a useful thing.  and we  
> simply don't need the fallback to  because we don't have the  
> backward compatibility issue that we had when MX records were  
> introduced.

Not sanctioning IPv6  records as an MX fall-back avoids the  
undesired traffic now caused by SMTP spoofing of A records.  MX  
records might then be seen as an opt-in mechanism from the perspective  
of IPv6, since opt-out mechanism are onerous for those not wishing to  
participate.  While Bill and others expressed concerns of being tied  
to DNS, whatever replaces DNS must also offer separate service and IP  
address resolution mechanisms.  The concerns related to DNS seems to  
assume there would not be separate service/address mechanisms, but  
this would not suit those running their services out of different  
domains.

Not sanctioning IPv6 MX to  fallback actually makes IPv6 easier to  
manage in that email policies will not be required at all IPv6  
hostnames, as they would be for IPv4.  Those wanting to employ small  
and simple services connected directly to the Internet might otherwise  
find these services inundated by undesired traffic whenever their  
hostname is used to spoof an email source.  Not sanctioning IPv6 MX to  
 fallback makes IPv6 safer from abuse, perhaps enough to  
compensate for the quadrillions of hostnames and IP addresses that  
might be involved.  Over time SMTP itself may not remain viable as an  
exchange between anonymous parties if RFC2821bis retains IPv6   
records as a fall-back for MX records.

-Doug
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: IETF Last Call for two IPR WG Dcouments

[Lawrence Rosen]

Simon Josefsson wrote:
> To give the Trust something concrete to work with I propose to add the
> following:
> 
>   To make sure the granted rights are usable in practice, they need to
>   at least meet the requirements of the Open Source Definition [OSD],
>   the Free Software Definition [FSD], and the Debian Free Software
>   Guidelines [DFSG].

+1

/Larry




> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Simon Josefsson
> Sent: Friday, March 28, 2008 3:02 AM
> To: Russ Housley
> Cc: ietf@ietf.org
> Subject: Re: IETF Last Call for two IPR WG Dcouments
> 
> Regarding -outbound section 4.3:
> 
>IETF contributions often include components intended to be directly
>processed by a computer.  Examples of these include ABNF definitions,
>XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values,
>MIBs, ASN.1, or classical programming code.  These are included in
>IETF contributions for clarity and precision in specification.  It is
>clearly beneficial, when such items are included in IETF
>contributions, to permit the inclusion of such code components in
>products which implement the contribution.  It has been pointed out
>that in several important contexts use of such code requires the
>ability to modify the code.  One common example of this is simply the
>need to adapt code for use in specific contexts (languages,
>compilers, tool systems, etc.)  Such use frequently requires some
>changes to the text of the code from the IETF contribution.  Another
>example is that code included in open source products is frequently
>licensed to permit any and all of the code to be modified.  Since we
>want this code included in such products, it follows that we need to
>permit such modification.  While there has been discussion of
>restricting the rights to make such modifications in some way, the
>rough consensus of the IETF is that such restrictions are likely a
>bad idea, and are certainly very complex to define.
> 
>As such, the rough consensus is that the IETF Trust is to grant
>rights such that code components of IETF contributions can be
>extracted, modified, and used by anyone in any way desired.  To
>enable the broadest possible extraction, modification and usage, the
>IETF Trust should avoid adding software license obligations beyond
>those already present in a contribution.  The granted rights to
>extract, modify and use code should allow creation of derived works
>outside the IETF that may carry additional license obligations.
> ...
> 
> I believe the intention here is good, but it leaves the IETF Trust with
> no guidelines on how to write the license declaration that is likely to
> work well in practice with actual products.  There are no reference to
> what "open source" means in this context, and references to "free
> software" is missing.
> 
> I believe it would be a complete failure if code-like portions of RFCs
> cannot be included into open source and free software products such as
> the Debian project.
> 
> To give the Trust something concrete to work with I propose to add the
> following:
> 
>   To make sure the granted rights are usable in practice, they need to
>   at least meet the requirements of the Open Source Definition [OSD],
>   the Free Software Definition [FSD], and the Debian Free Software
>   Guidelines [DFSG].
> 
> For those who fear that this will lead to complexity: releasing
> something that is compatible with those requirements is simple.  The
> modified BSD license meets those requirements, as does a number of other
> methods, including releasing the work into the public domain.
> 
> The references being:
> 
> [OSD] "The Open Source Definition",
>   http://opensource.org/docs/osd
> 
> [FSD] "The Free Software Definition",
>   http://www.fsf.org/licensing/essays/free-sw.html
> 
> [DFSG] "The Debian Free Software Guidelines",
>   http://www.debian.org/social_contract#guidelines
> 
> Thanks,
> Simon
> 
> Russ Housley <[EMAIL PROTECTED]> writes:
> 
> > During the Wednesday Plenary at IETF 71, I gave the IETF community a
> > "heads up" on two documents from the IPR WG that were nearing IETF
> > Last Call.  Both of the documents have now reached IETF Last
> > call.  The Last Call announcements are attached.  Please review and
> comment.
> >
> > Russ
> >
> > == == == == == == == == == ==
> >
> > To: IETF-Announce <[EMAIL PROTECTED]>
> > From: The IESG <[EMAIL PROTECTED]>
> > Subject: Last Call: draft-ietf-ipr-outbound-rights (Advice to the
> >  Trustees of the IETF Trust on Rights to be Granted in IETF
> >  Documents) to Informational RFC
> > Date: Wed, 19 Mar 2008 15:15:56 -0700 (PDT)
> > Cc: [EMAIL PROTECTED]
> >
> > The IESG has received a request from the Intellectual Property Rights WG
> > (ipr) to consider the following document:
> >
> > - 'Advice to the Trustees of the IETF Trust on Rights to 

Re: IETF Last Call for two IPR WG Dcouments

[Scott O. Bradner]

> My suggestion is to rewrite  section 4 a bit to call out that this  
> document does not cover the incoming rights for the independent and  
> irtf stream and to use the terms "ietf-stream" and possibly "iab- 
> stream" in the definitions.

thats all well & good for the independent stream since they have 
their own ruleset but gets tricky for irtf unless they do and
splitting off iert & iab from teh rest of the ietf seems a bit
funky

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

Re: IETF Last Call for two IPR WG Dcouments

[Joel M. Halpern]

I do not understand the problem you want addressed.  The way this is 
worded, it doesn't matter what "open source" or "free software" is or 
becomes.  The intention is to grant anyone to do anything with the code 
segments.  That's what we ask the trust to do. Further in line.

Simon Josefsson wrote:
> Regarding -outbound section 4.3:
> 
...
> 
>As such, the rough consensus is that the IETF Trust is to grant
>rights such that code components of IETF contributions can be
>extracted, modified, and used by anyone in any way desired.  To
>enable the broadest possible extraction, modification and usage, the
>IETF Trust should avoid adding software license obligations beyond
>those already present in a contribution.  The granted rights to
>extract, modify and use code should allow creation of derived works
>outside the IETF that may carry additional license obligations.
This says that the trust is to grant rights so that code can be 
extracted, modified, and used by ANYONE.  I.e. our grant will not place 
restrictions on people.

> ...
> 
> I believe the intention here is good, but it leaves the IETF Trust with
> no guidelines on how to write the license declaration that is likely to
> work well in practice with actual products.  There are no reference to
> what "open source" means in this context, and references to "free
> software" is missing.
> 
> I believe it would be a complete failure if code-like portions of RFCs
> cannot be included into open source and free software products such as
> the Debian project.
If we grant anyone the right to use the code any way they want, which 
means that we specifically can not require preservation of notices or 
anything else, how could it fail to meet the requirements of the 
specific cases you list?

> 
> To give the Trust something concrete to work with I propose to add the
> following:
> 
>   To make sure the granted rights are usable in practice, they need to
>   at least meet the requirements of the Open Source Definition [OSD],
>   the Free Software Definition [FSD], and the Debian Free Software
>   Guidelines [DFSG].
> 
> For those who fear that this will lead to complexity: releasing
> something that is compatible with those requirements is simple.  The
> modified BSD license meets those requirements, as does a number of other
> methods, including releasing the work into the public domain.
My concern is not complexity.  Referencing the specific documents is 
more restrictive than what the working group recommended.  I don't see 
why that would help anything.

Yours,
Joel M. Halpern
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-klensin-rfc2821bis

[John C Klensin]

--On Wednesday, 26 March, 2008 17:09 + Tony Finch
<[EMAIL PROTECTED]> wrote:

>> With that change to "address record", if no MX record is
>> found, the SMTP client is required to look for DNS names with
>> either A or  RRs, rather than A RRs only.
> 
> There's also RFC 3974 (Jan 2005, informational) which
> recommends treating  like A. The most popular MTAs
> implement this logic.

Yep.  But the people who are already convinced that treating
 like A is the Right Thing are, well, already convinced.
And those who aren't will probably just say "well, 3974 is
informational".

Please see comments (yours, mine, and others) on the ietf-smtp
list.

john



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

Re: IETF Last Call for two IPR WG Dcouments

[Simon Josefsson]

"Joel M. Halpern" <[EMAIL PROTECTED]> writes:

> I do not understand the problem you want addressed.  The way this is 
> worded, it doesn't matter what "open source" or "free software" is or 
> becomes.  The intention is to grant anyone to do anything with the code 
> segments.  That's what we ask the trust to do. Further in line.

The problem is that without proper guidelines on how to make a software
license compatible with free software licenses, it is possible to end up
with something that won't be compatible, and thus wouldn't meet the
intended goals.

Given that the IETF Trust doesn't publish drafts or have a history of
asking for community review on the legal license they chose, I believe
it is important that the IETF articulate its wishes in ways that reduce
chances of misunderstandings or are open for interpretation.

> Simon Josefsson wrote:
>> Regarding -outbound section 4.3:
>> 
> ...
>> 
>>As such, the rough consensus is that the IETF Trust is to grant
>>rights such that code components of IETF contributions can be
>>extracted, modified, and used by anyone in any way desired.  To
>>enable the broadest possible extraction, modification and usage, the
>>IETF Trust should avoid adding software license obligations beyond
>>those already present in a contribution.  The granted rights to
>>extract, modify and use code should allow creation of derived works
>>outside the IETF that may carry additional license obligations.
> This says that the trust is to grant rights so that code can be 
> extracted, modified, and used by ANYONE.  I.e. our grant will not place 
> restrictions on people.

Agreed.

>> I believe the intention here is good, but it leaves the IETF Trust with
>> no guidelines on how to write the license declaration that is likely to
>> work well in practice with actual products.  There are no reference to
>> what "open source" means in this context, and references to "free
>> software" is missing.
>> 
>> I believe it would be a complete failure if code-like portions of RFCs
>> cannot be included into open source and free software products such as
>> the Debian project.
> If we grant anyone the right to use the code any way they want, which 
> means that we specifically can not require preservation of notices or 
> anything else, how could it fail to meet the requirements of the 
> specific cases you list?

If you show me the software license that is going to be used, the
community will be able to tell you.

Writing software licenses that are compatible with free software
licenses is a complicated area, and there are many ways to fail.  If you
haven't evaluated licenses for compatibility before, I suggest to look
at what the debian-legal list has been doing.  There are subtle issues
that can prevent a license from giving the necessary rights.  As far as
I know the IETF Trust does not have extensive knowledge of free software
licensing and license compatibility considerations.  Helping them to get
this right by providing some sanity tests (the OSD, FSD and DFSG) to run
their drafts against will help them.

>> To give the Trust something concrete to work with I propose to add the
>> following:
>> 
>>   To make sure the granted rights are usable in practice, they need to
>>   at least meet the requirements of the Open Source Definition [OSD],
>>   the Free Software Definition [FSD], and the Debian Free Software
>>   Guidelines [DFSG].
>> 
>> For those who fear that this will lead to complexity: releasing
>> something that is compatible with those requirements is simple.  The
>> modified BSD license meets those requirements, as does a number of other
>> methods, including releasing the work into the public domain.
> My concern is not complexity.  Referencing the specific documents is 
> more restrictive than what the working group recommended.  I don't see 
> why that would help anything.

Please read again what I proposed, in particular "at least meet the
requirements".  If the Trust's software license do not meet those
requirements, then it clearly will not meet the intended IETF goals that
we agree on.

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

Re: Last Call: draft-klensin-rfc2821bis

[Keith Moore]

>> and the dummy SMTP server works, but it consumes resources on the  
>> host and eats bandwidth on the network.  having a way to say "don't  
>> send this host any mail" in DNS seems like a useful thing.  and we  
>> simply don't need the fallback to  because we don't have the  
>> backward compatibility issue that we had when MX records were  
>> introduced.
> 
> Not sanctioning IPv6  records as an MX fall-back avoids the  
> undesired traffic now caused by SMTP spoofing of A records.  MX  
> records might then be seen as an opt-in mechanism from the perspective  
> of IPv6, since opt-out mechanism are onerous for those not wishing to  
> participate.  While Bill and others expressed concerns of being tied  
> to DNS, whatever replaces DNS must also offer separate service and IP  
> address resolution mechanisms.

there are lots of cases where I'd share the concern that DNS gets out of 
sync with reality.  but having this information in DNS doesn't bother me 
in this case because the servers to which incoming mail messages to 
[EMAIL PROTECTED] are supposed to be sent, are a property of the 
example.com domain, far more than a property of any host.  it makes 
sense to put information about a domain in DNS (or whatever might 
someday replace DNS).

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

Re: IETF Last Call for two IPR WG Dcouments

[Ted Hardie]

At 8:16 AM -0700 3/28/08, Simon Josefsson wrote:
>"Joel M. Halpern" <[EMAIL PROTECTED]> writes:
>
>> I do not understand the problem you want addressed.  The way this is
>> worded, it doesn't matter what "open source" or "free software" is or
>> becomes.  The intention is to grant anyone to do anything with the code
>> segments.  That's what we ask the trust to do. Further in line.
>
>The problem is that without proper guidelines on how to make a software
>license compatible with free software licenses, it is possible to end up
>with something that won't be compatible, and thus wouldn't meet the
>intended goals.
>
>Given that the IETF Trust doesn't publish drafts or have a history of
>asking for community review on the legal license they chose, I believe
>it is important that the IETF articulate its wishes in ways that reduce
>chances of misunderstandings or are open for interpretation.

I disagree with Simon's addition.  The intent of the document is to
give the Trust instructions from the community that we want
the code in RFCs to be available to anyone to do anything.
As Joel put it:

"The intention is to grant anyone to do anything with the code
segments.  That's what we ask the trust to do. "

That was the consensus of the working group, and I believe it
should remain the consensus of the IETF as a whole--it gives
the widest possible reach to the standard.  Crafting the legal
language to make that work is a task best left to lawyers;
adding specific compatibility requirements that appear
to privilege one set of follow-on outputs is both confusing and ultimately
pointless.  The language in the draft is clear that we want
the code to be usable by *anyone*.  It wouldn't add anything
to that mandate to list specific individuals, and it doesn't
add anything to list specific licenses that will only apply
after an individual has already used the code.

regards,
Ted
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-klensin-rfc2821bis

[Ned Freed]

> > > > In an IETF that believes the potential recursion of URNs and
> > > > NAPTR records is reasonable, it is really hard for me to get
> > > > excited about that one possible extra lookup.   YMMD, of course.
> >
> > I can't get excited about this either.
> >
> > >   Doug's issue, which sparked off this latest debate, would
> > >   be addressed by codifying "MX 0 .".  This would allow hosts
> > >   to say that do not accept email and any email (MAIL FROM)
> > >   claiming to come from such a domain to be dropped in the
> > >   SMTP session.
> >
> > OTOH, I think standardizing this convention makes all sorts of sense, but
> > not, of course, in 2821bis.

>   Why not in 2821bis? 

Mainly because this entire exercise is focused on a move to draft with this
revision and a move to draft is not the time to introduce new features.

> Is 2821bis really that time critical?
 
It is somewhat time critical, but to be blunt I'm much more worried that if we
delay long enough to get consensus on this change and force a recycle at
proposed the necessary energy to move this document to draft won't be there
when it is possible to do so.

I'm also concerned that opening the door to new features and additions to
this document will result in a slew of additional well intentioned proposals
for changes and additions that will delay things even more.

This entire effort to revise the core email protocol documents has only been
been able to reach some sort of closure because we've managed to keep a pretty
narrow focus on just cleaning ujp what's there in the base specifications. And
even then it has taken a huge amount of work. I don't think you realize the
potential for harm opening the door the way you propose can do.

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

Re: Implicit MX and A RRs

[Ned Freed]

> On Thu, 27 Mar 2008, Matti Aarnio wrote:
> >
> > There will be lots of legacy codes using legacy APIs for long future.
> > I do use  getaddrinfo()  API myself, and permit it do all queries to
> > get addresses.  Thus it will also query for A in addition to .
> > It can even be ordered to ignore IPv4 or IPv6 as sysadmin wants.

> There's an amusing interop issue with getaddrinfo and DNS lookups in MTAs.
> In many implementations getaddrinfo will perform SRV lookups for you (as
> an extension to /etc/services or getservbyname), so it probably doesn't do
> the right thing (or it can be persuaded not to do the right thing by
> people with perverse DNS setups). On Mac OS X, the daemon that handles
> getaddrinfo has a special case for port 25 which performs MX lookups for
> you (like SRV lookups), so it certainly does't do the right thing! Serious
> email software needs to talk to the low-level resolver API in situations
> when it cares about the detailed semantics of domain resolution, and it
> needs a way of talking to the high-level resolver API when the sysadmin
> chooses so that /etc/hosts, /etc/nsswitch.conf, and similar platform-
> specific settings can do their thing.

If anything this understates the problems MTAs face. Sure, you can use your own
resolver routines and avoid these semantics issues with getaddrinfo, but now
you're doing purely DNS-based address lookup. It may not be standardized, but
it is surprisingly common to use other name services or host files for this
within an administative domain. And while it may be possible to duplicate the
logic to do these other  sorts of lookups, you're now talking about
substantially more code and complexity, not to mention platform and
environmental dependencies.

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

Re: IETF Last Call for two IPR WG Dcouments

[Peter Saint-Andre]

Joel M. Halpern wrote:
> I do not understand the problem you want addressed.  The way this is 
> worded, it doesn't matter what "open source" or "free software" is or 
> becomes.  The intention is to grant anyone to do anything with the code 
> segments.  That's what we ask the trust to do. Further in line.

I think Simon is suggesting that we provide some guidance to the Trust
in choosing a license. IANAL, however the phrase "grant anyone to do
anything" sounds nice in theory but needs to be translated into a
functioning license. As far as I can see there are three licenses that
would fit the bill:

1. The MIT license
2. A BSD-style license
3. A designation that the code is in the public domain

Some people allege that it is not possible to put a work directly into
the public domain (although I disagree), which is why they prefer to use
a license.

As a point of comparison, the XMPP Standards Foundation recently worked
to make sure that its specifications are safe for inclusion in free
sofware, and decided upon a slightly-modified MIT license (modified in
order to make clear that we were publishing specifications, not code).
The resulting license is here:

http://www.xmpp.org/extensions/ipr-policy.shtml

> Simon Josefsson wrote:
>> Regarding -outbound section 4.3:
>>
> ...
>>As such, the rough consensus is that the IETF Trust is to grant
>>rights such that code components of IETF contributions can be
>>extracted, modified, and used by anyone in any way desired.  To
>>enable the broadest possible extraction, modification and usage, the
>>IETF Trust should avoid adding software license obligations beyond
>>those already present in a contribution.  The granted rights to
>>extract, modify and use code should allow creation of derived works
>>outside the IETF that may carry additional license obligations.
> This says that the trust is to grant rights so that code can be 
> extracted, modified, and used by ANYONE.  I.e. our grant will not place 
> restrictions on people.

Correct. But we need to have a license over the code, not just say that
anyone can use it, which legally is void for vagueness (IMO IANAL etc.).

>> ...
>>
>> I believe the intention here is good, but it leaves the IETF Trust with
>> no guidelines on how to write the license declaration that is likely to
>> work well in practice with actual products.  There are no reference to
>> what "open source" means in this context, and references to "free
>> software" is missing.
>>
>> I believe it would be a complete failure if code-like portions of RFCs
>> cannot be included into open source and free software products such as
>> the Debian project.
> If we grant anyone the right to use the code any way they want, which 
> means that we specifically can not require preservation of notices or 
> anything else, how could it fail to meet the requirements of the 
> specific cases you list?

Because it is not covered by a license.

>> To give the Trust something concrete to work with I propose to add the
>> following:
>>
>>   To make sure the granted rights are usable in practice, they need to
>>   at least meet the requirements of the Open Source Definition [OSD],
>>   the Free Software Definition [FSD], and the Debian Free Software
>>   Guidelines [DFSG].
>>
>> For those who fear that this will lead to complexity: releasing
>> something that is compatible with those requirements is simple.  The
>> modified BSD license meets those requirements, as does a number of other
>> methods, including releasing the work into the public domain.
> My concern is not complexity.  Referencing the specific documents is 
> more restrictive than what the working group recommended.  I don't see 
> why that would help anything.

See above. Perhaps it would be more helpful to reference some specific
licenses that would realize the stated intent?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Ray Pelletier]

Peter Saint-Andre wrote:


Joel M. Halpern wrote:
 

I do not understand the problem you want addressed.  The way this is 
worded, it doesn't matter what "open source" or "free software" is or 
becomes.  The intention is to grant anyone to do anything with the code 
segments.  That's what we ask the trust to do. Further in line.
   



I think Simon is suggesting that we provide some guidance to the Trust
in choosing a license. IANAL, however the phrase "grant anyone to do
anything" sounds nice in theory but needs to be translated into a
functioning license. As far as I can see there are three licenses that
would fit the bill:

1. The MIT license
2. A BSD-style license
3. A designation that the code is in the public domain

Some people allege that it is not possible to put a work directly into
the public domain (although I disagree), which is why they prefer to use
a license.

As a point of comparison, the XMPP Standards Foundation recently worked
to make sure that its specifications are safe for inclusion in free
sofware, and decided upon a slightly-modified MIT license (modified in
order to make clear that we were publishing specifications, not code).
The resulting license is here:

http://www.xmpp.org/extensions/ipr-policy.shtml
 

The Trustees adopted the Non-Profit Open Software License 3.0 in 
September 2007 as the license it would use for open sourcing software 
done as work-for-hire and that contributed to it, at that time thinking 
of code contributed by IETF volunteers.  See:  
http://trustee.ietf.org/licenses.html 

Is it clear that the contributions contemplated by these documents would 
require a different treatment?


Ray
Trustee
IAD

 


Simon Josefsson wrote:
   


Regarding -outbound section 4.3:

 


...
   


  As such, the rough consensus is that the IETF Trust is to grant
  rights such that code components of IETF contributions can be
  extracted, modified, and used by anyone in any way desired.  To
  enable the broadest possible extraction, modification and usage, the
  IETF Trust should avoid adding software license obligations beyond
  those already present in a contribution.  The granted rights to
  extract, modify and use code should allow creation of derived works
  outside the IETF that may carry additional license obligations.
 

This says that the trust is to grant rights so that code can be 
extracted, modified, and used by ANYONE.  I.e. our grant will not place 
restrictions on people.
   



Correct. But we need to have a license over the code, not just say that
anyone can use it, which legally is void for vagueness (IMO IANAL etc.).

 


...

I believe the intention here is good, but it leaves the IETF Trust with
no guidelines on how to write the license declaration that is likely to
work well in practice with actual products.  There are no reference to
what "open source" means in this context, and references to "free
software" is missing.

I believe it would be a complete failure if code-like portions of RFCs
cannot be included into open source and free software products such as
the Debian project.
 

If we grant anyone the right to use the code any way they want, which 
means that we specifically can not require preservation of notices or 
anything else, how could it fail to meet the requirements of the 
specific cases you list?
   



Because it is not covered by a license.

 


To give the Trust something concrete to work with I propose to add the
following:

 To make sure the granted rights are usable in practice, they need to
 at least meet the requirements of the Open Source Definition [OSD],
 the Free Software Definition [FSD], and the Debian Free Software
 Guidelines [DFSG].

For those who fear that this will lead to complexity: releasing
something that is compatible with those requirements is simple.  The
modified BSD license meets those requirements, as does a number of other
methods, including releasing the work into the public domain.
 

My concern is not complexity.  Referencing the specific documents is 
more restrictive than what the working group recommended.  I don't see 
why that would help anything.
   



See above. Perhaps it would be more helpful to reference some specific
licenses that would realize the stated intent?

Peter

 




___
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

Re: Last Call: draft-klensin-rfc2821bis

[Frank Ellermann]

Ned Freed wrote:
 
> this entire exercise is focused on a move to draft with this revision

In this case I'm a part of the rough, my focus is on "get it right"
before the staus.  For 2822upd I'd be upset if it is no STD in 2010,
2821bis is different.  

> a move to draft is not the time to introduce new features.

It's a trick to keep wild and wonderful new features out.  For the
IPv6-fallback discussed in this thread "getting it right" is more
important than the status.  Ideal case, 2821bis is good as is, and
can replace the relevant parts of STD 10 in two years.  

Worst case, we find that 2821bis should have no IPv6-fallback in
two years, a 2821ter starting at PS would then take about five
years before its successor can be at STD.  

With a modified 2821bis requiring PS now assuming again five years
from PS to STD we'd be there 2013 instead of 2015 compared with the
worst case, or in 2013 instead of 2010 compared with the ideal case.

The question of the status PS / DS / STD alone IMO misses the point
of getting it right.

> to be blunt I'm much more worried that if we delay long enough to
> get consensus on this change and force a recycle at proposed the
> necessary energy to move this document to draft won't be there
> when it is possible to do so.

No energy to fix it if necessary would be bad independent of the
status.  And 2821bis as is fixes various things that needed to be
fixed, whatever the outcome of the IPv6-fallback question and the
status will be.

IMO adding null-MX to 2821bis makes no sense technically, it is an
IPv4 kludge, not something to be added to billions of IPv6 webcams
or similar devices as "SMTP opt out".  OTOH a "SMTP opt in" by a
mandatory MX for IPv6 could be okay.

> even then it has taken a huge amount of work.

Sure, but SMTP is also important enough to deserve that much work.

Actually it would have deserved more work from me, but when folks
start whining about the status and not introducing new features at
critical points this is pretty much demotivating, and I fear the
outcome is not as good as it could have been without this "status
first" group think.
 
 Frank

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

Re: IETF Last Call for two IPR WG Dcouments

[Margaret Wasserman]

Ray Pelletier wrote:
> The Trustees adopted the Non-Profit Open Software License 3.0 in  
> September 2007 as the license it would use for open sourcing  
> software done as work-for-hire and that contributed to it, at that  
> time thinking of code contributed by IETF volunteers.  See:  http:// 
> trustee.ietf.org/licenses.html
>
> Is it clear that the contributions contemplated by these documents  
> would require a different treatment?


Disclaimer:  IANAL, and I apologize if I am misunderstanding  
something about the license you referenced, but...

It seems to me that the "Non-Profit Open Software License 3.0", while  
fine for the source code to IETF tools, places more restrictions and  
more burden on someone who uses the code than we would want to place  
on someone who uses a MIB, XML schema or other "code" from our RFCs.

For example, the license places an obligation on someone using the  
source code to distribute copies of the original source code with any  
products they distribute.  Effectively, this means that anyone who  
distributes products based on MIBs, XML schemas or other "code" from  
RFCs would need to put up a partial RFC repository.  Why would we  
want that?

Margaret

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

Re: IETF Last Call for two IPR WG Dcouments

[SM]

At 03:01 28-03-2008, Simon Josefsson wrote:
>Regarding -outbound section 4.3:
>
>
>As such, the rough consensus is that the IETF Trust is to grant
>rights such that code components of IETF contributions can be
>extracted, modified, and used by anyone in any way desired.  To
>enable the broadest possible extraction, modification and usage, the
>IETF Trust should avoid adding software license obligations beyond
>those already present in a contribution.  The granted rights to
>extract, modify and use code should allow creation of derived works
>outside the IETF that may carry additional license obligations.
>...
>
>I believe the intention here is good, but it leaves the IETF Trust with
>no guidelines on how to write the license declaration that is likely to
>work well in practice with actual products.  There are no reference to
>what "open source" means in this context, and references to "free
>software" is missing.

The above are guidelines.  You'll get a different definition of what 
"open source" or "free software" is depending on whom you ask.  The 
words "enable the broadest possible extraction, modification and 
usage" provides more scope.

>To give the Trust something concrete to work with I propose to add the
>following:
>
>   To make sure the granted rights are usable in practice, they need to
>   at least meet the requirements of the Open Source Definition [OSD],
>   the Free Software Definition [FSD], and the Debian Free Software
>   Guidelines [DFSG].

These are not guidelines; they are requirements.

Regards,
-sm


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

Re: IETF Last Call for two IPR WG Dcouments

[Peter Saint-Andre]

Ray Pelletier wrote:
> 
> Peter Saint-Andre wrote:
> 
>> Joel M. Halpern wrote:
>>  
>>
>>> I do not understand the problem you want addressed.  The way this is
>>> worded, it doesn't matter what "open source" or "free software" is or
>>> becomes.  The intention is to grant anyone to do anything with the
>>> code segments.  That's what we ask the trust to do. Further in line.
>>>   
>>
>> I think Simon is suggesting that we provide some guidance to the Trust
>> in choosing a license. IANAL, however the phrase "grant anyone to do
>> anything" sounds nice in theory but needs to be translated into a
>> functioning license. As far as I can see there are three licenses that
>> would fit the bill:
>>
>> 1. The MIT license
>> 2. A BSD-style license
>> 3. A designation that the code is in the public domain
>>
>> Some people allege that it is not possible to put a work directly into
>> the public domain (although I disagree), which is why they prefer to use
>> a license.
>>
>> As a point of comparison, the XMPP Standards Foundation recently worked
>> to make sure that its specifications are safe for inclusion in free
>> sofware, and decided upon a slightly-modified MIT license (modified in
>> order to make clear that we were publishing specifications, not code).
>> The resulting license is here:
>>
>> http://www.xmpp.org/extensions/ipr-policy.shtml
>>  
>>
> The Trustees adopted the Non-Profit Open Software License 3.0 in
> September 2007 as the license it would use for open sourcing software
> done as work-for-hire and that contributed to it, at that time thinking
> of code contributed by IETF volunteers.  See: 
> http://trustee.ietf.org/licenses.html
> Is it clear that the contributions contemplated by these documents would
> require a different treatment?

Thanks for the link. I had not been aware of this license, so I'll take
some time to read it before commenting. I've also sent the text of the
license to the debian-legal list for discussion among that community.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Peter Saint-Andre]

SM wrote:
> At 03:01 28-03-2008, Simon Josefsson wrote:
>
>> To give the Trust something concrete to work with I propose to add the
>> following:
>>
>>   To make sure the granted rights are usable in practice, they need to
>>   at least meet the requirements of the Open Source Definition [OSD],
>>   the Free Software Definition [FSD], and the Debian Free Software
>>   Guidelines [DFSG].
> 
> These are not guidelines; they are requirements.

This is true.

Rather than wrangling over text that might be added to -outbound,
perhaps it would be more productive to describe how members of the
Internet community can provide input to the Trust regarding this issue
(or any other, for that matter). It seems to me that the information at
http://trustee.ietf.org/ does not describe the relevant processes, other
than mentioning .

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: IETF Last Call for two IPR WG Dcouments

[Wes Beebee (wbeebee)]

I would think that any license for RFC code should meet two
requirements:
1) It should be usable by anyone in the open source community
(compatible 
   with any open source/free software license).
2) It should be usable by anyone in any corporation who sells a closed 
   source product.

That way, we can ensure interoperability between open source and closed
source 
implementations.  Note that these requirements greatly constrain the
form that the
license should take.

- Wes

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Margaret Wasserman
Sent: Friday, March 28, 2008 2:30 PM
To: Ray Pelletier
Cc: Simon Josefsson; Joel M. Halpern; ietf@ietf.org
Subject: Re: IETF Last Call for two IPR WG Dcouments


Ray Pelletier wrote:
> The Trustees adopted the Non-Profit Open Software License 3.0 in 
> September 2007 as the license it would use for open sourcing software 
> done as work-for-hire and that contributed to it, at that time 
> thinking of code contributed by IETF volunteers.  See:  http:// 
> trustee.ietf.org/licenses.html
>
> Is it clear that the contributions contemplated by these documents 
> would require a different treatment?


Disclaimer:  IANAL, and I apologize if I am misunderstanding  
something about the license you referenced, but...

It seems to me that the "Non-Profit Open Software License 3.0", while  
fine for the source code to IETF tools, places more restrictions and  
more burden on someone who uses the code than we would want to place  
on someone who uses a MIB, XML schema or other "code" from our RFCs.

For example, the license places an obligation on someone using the  
source code to distribute copies of the original source code with any  
products they distribute.  Effectively, this means that anyone who  
distributes products based on MIBs, XML schemas or other "code" from  
RFCs would need to put up a partial RFC repository.  Why would we  
want that?

Margaret

___
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

Re: Last Call: draft-klensin-rfc2821bis

[John C Klensin]

--On Friday, 28 March, 2008 19:20 +0100 Frank Ellermann
<[EMAIL PROTECTED]> wrote:

>> a move to draft is not the time to introduce new features.
> 
> It's a trick to keep wild and wonderful new features out.  For
> the IPv6-fallback discussed in this thread "getting it right"
> is more important than the status.  Ideal case, 2821bis is
> good as is, and can replace the relevant parts of STD 10 in
> two years.  
> 
> Worst case, we find that 2821bis should have no IPv6-fallback
> in two years, a 2821ter starting at PS would then take about
> five years before its successor can be at STD.  
>...

Frank,

As you and others have been repeatedly told on the ietf-smtp
list, if you have wild and wonderful new features, write drafts,
introduce them as separate, Proposed Standard, updates to 2821
that stand on their own, with their own justifications.  If that
had been done when the 2821bis effort started, or in the
subsequent months, if any of the supposed wonderful new features
introduced then had achieved interoperable implementations and
some deployment, it would have been perfectly reasonable to slip
them into 2821bis before the first Last Call a few months ago.

That approach is important because 2821 (and 2821bis),
independent of their formal status, are updates to a collection
of long-established and very widely deployed full standards.
Few people, other than the advocates of a particular wild and/or
wonderful idea, are going to be happy putting anything into it
--even at Proposed-- for which we do not have considerable
operational experience.  Those were essentially the rules for
DRUMS and they are the rules that Tony, Lisa, and myself have
been trying to apply to 2821 changes: we clarify, we correct
errors, but 2821[bis] is not the right place for wild and
wonderful ideas until they are thoroughly tamed.

Looked at a different way, the only advantage I can see of
stuffing a new idea into 2821bis and then cycling at Proposed
over writing the new idea up and processing it as a separate
update to 2821bis is the former would tend to hide from the
reader that it is a new idea and one that is less tested and
understood than the balance of 2821.  I don't believe the former
is a good way to proceed, but that is just my opinion.

So, with the understanding that this is just my opinion (but
that, as editor, I'm getting impatient with new ideas and
discussions surfacing during and after Last Call), let me repeat
my suggestion.  If you (or others, and you are clearly not the
worst offender) have new and/or wonderful ideas, write them up
in one or more I-Ds.  If they are good enough to stand on their
own, you should have no difficulty persuading an AD to process
them and getting them approved.  If they are not, then let's not
get involved with trying to insert them into 2821[bis] at the
last minute or later.   And, of course, if you are convinced
that there are enough wild and wonderful ideas to justify it, or
that circumstances have changed enough to justify redefining
Internet Mail, see if you can get tracking for a WG.  I'll wish
you well.

john

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

Re: IETF Last Call for two IPR WG Dcouments

[Peter Saint-Andre]

Ray Pelletier wrote:

> The Trustees adopted the Non-Profit Open Software License 3.0 in
> September 2007 as the license it would use for open sourcing software
> done as work-for-hire and that contributed to it, at that time thinking
> of code contributed by IETF volunteers.  See: 
> http://trustee.ietf.org/licenses.html

Because the license is provided in a PDF file, I have pasted the text
below for ease of discussion.

** BEGIN LICENSE **

Non-Profit Open Software License ("Non-Profit OSL") 3.0

This Non-Profit Open Software License ("Non-Profit OSL") version 3.0
(the "License") applies to any original work of authorship (the
"Original Work") whose owner (the "Licensor") has placed the following
licensing notice adjacent to the copyright notice for the Original Work:

Licensed under the Non-Profit Open Software License version 3.0

1) Grant of Copyright License. Licensor grants You a worldwide,
royalty-free, non-exclusive, sublicensable license, for the duration of
the copyright, to do the following:

a) to reproduce the Original Work in copies, either alone or as part of
a collective work;

b) to translate, adapt, alter, transform, modify, or arrange the
Original Work, thereby creating derivative works ("Derivative Works")
based upon the Original Work;

c) to distribute or communicate copies of the Original Work and
Derivative Works to the public, with the proviso that copies of Original
Work or Derivative Works that You distribute or communicate shall be
licensed under this Non-Profit Open Software License or as provided in
section 17(d);

d) to perform the Original Work publicly; and

e) to display the Original Work publicly.

2) Grant of Patent License. Licensor grants You a worldwide,
royalty-free, non-exclusive, sublicensable license, under patent claims
owned or controlled by the Licensor that are embodied in the Original
Work as furnished by the Licensor, for the duration of the patents, to
make, use, sell, offer for sale, have made, and import the Original Work
and Derivative Works.

3) Grant of Source Code License. The term "Source Code" means the
preferred form of the Original Work for making modifications to it and
all available documentation describing how to modify the Original Work.
Licensor agrees to provide a machine-readable copy of the Source Code of
the Original Work along with each copy of the Original Work that
Licensor distributes. Licensor reserves the right to satisfy this
obligation by placing a machine-readable copy of the Source Code in an
information repository reasonably calculated to permit inexpensive and
convenient access by You for as long as Licensor continues to distribute
the Original Work.

4) Exclusions From License Grant. Neither the names of Licensor, nor the
names of any contributors to the Original Work, nor any of their
trademarks or service marks, may be used to endorse or promote products
derived from this Original Work without express prior permission of the
Licensor. Except as expressly stated herein, nothing in this License
grants any license to Licensor’s trademarks, copyrights, patents,
trade secrets or any other intellectual property. No patent license is
granted to make, use, sell, offer for sale, have made, or import
embodiments of any patent claims other than the licensed claims defined
in Section 2. No license is granted to the trademarks of Licensor even
if such marks are included in the Original Work. Nothing in this License
shall be interpreted to prohibit Licensor from licensing under terms
different from this License any Original Work that Licensor otherwise
would have a right to license.

5) External Deployment. The term "External Deployment" means the use,
distribution, or communication of the Original Work or Derivative Works
in any way such that the Original Work or Derivative Works may be used
by anyone other than You, whether those works are distributed or
communicated to those persons or made available as an application
intended for use over a network. As an express condition for the grants
of license hereunder, You must treat any External Deployment by You of
the Original Work or a Derivative Work as a distribution under section
1(c).

6) Attribution Rights. You must retain, in the Source Code of any
Derivative Works that You create, all copyright, patent, or trademark
notices from the Source Code of the Original Work, as well as any
notices of licensing and any descriptive text identified therein as an
"Attribution Notice." You must cause the Source Code for any Derivative
Works that You create to carry a prominent Attribution Notice reasonably
calculated to inform recipients that You have modified the Original Work.

7) Warranty of Provenance and Disclaimer of Warranty. The Original Work
is provided under this License on an "AS IS" BASIS and WITHOUT WARRANTY,
either express or implied, including, without limitation, the warranties
of non-infringement, merchantability or fitness for a particular
purpose. THE ENTIRE RISK AS T

Re: Last Call: draft-klensin-rfc2821bis

[Keith Moore]

[EMAIL PROTECTED] wrote:

> Let me throw another idea into the mix. What if we were to
> recommend a transition architecture in which an MTA host
> ran two instances of the MTA software, one binding only to
> IPv4 addresses, and the other binding to only IPv6 addresses.
> Assume that there will be some means for the two MTA software
> instances to exchange messages when their DNS queries return
> the wrong kind of addresses (A or ). The IPv4 MTA can 
> continue to use the rules regarding MX records with A record
> fallback. The IPv6 MTA could require SRV records to identify
> destinations and have no  fallback.


it's not as if we want mail that is initially submitted via 
SMTP-over-IPv4 to be treated differently from the mail that is initially 
submitted via SMTP-over-IPv6.  if an MX for a domain has presence on 
both IPv4 and IPv6, there's no reason that an SMTP client shouldn't try 
to contact that MX using either IPv4 or IPv6.

as for using SRV for this case, it's pointless.  MX already works fine; 
SRV would require an extra DNS lookup with the attendant delay, 
overhead, and potential for failure.  using SRV is also more disruptive 
with no benefit that I can see.

> It immediately seems obvious that some issues surrounding 
> an architecture of email systems during the IPv4-IPv6 transition,
> are well out of scope of RFC28821bis. 

perhaps, but I disagree that this is one of those issues.

more broadly, I think what we're seeing is an example of why our model 
for revision of our standards is broken.   what you seem to be arguing 
is that since we can't get everything settled with 2821bis immediately, 
we should indefinitely defer any further changes to it - even when we 
have good reason to believe there are problems that we can fix in the 
near term and that it's better to fix them now than later.

really what we should be doing is periodically (or continuously) 
maintaining our specifications as new requirements issues are 
identified.  we need to develop a better sense of which kinds of 
changes/improvements/fixes can be made without a major rewrite/rethink 
and which ones require a process like that which produced rfc2821.

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

RE: IETF Last Call for two IPR WG Dcouments

[Lawrence Rosen]

Margaret Wasserman wrote:
> Disclaimer:  IANAL, and I apologize if I am misunderstanding
> something about the license you referenced, but...
> 
> It seems to me that the "Non-Profit Open Software License 3.0", while
> fine for the source code to IETF tools, places more restrictions and
> more burden on someone who uses the code than we would want to place
> on someone who uses a MIB, XML schema or other "code" from our RFCs.
> 
> For example, the license places an obligation on someone using the
> source code to distribute copies of the original source code with any
> products they distribute.  Effectively, this means that anyone who
> distributes products based on MIBs, XML schemas or other "code" from
> RFCs would need to put up a partial RFC repository.  Why would we
> want that?

As the author of the Non-Profit Open Software License 3.0 (NOSL 3.0),
perhaps I can clear up some misconceptions about it.

* NOSL 3.0 is for software tools; it is not a standards license. It is not
used as the outbound license for any code in RFCs, and thus there is no
obligation that I'm aware of to put up a "partial RFC repository" anywhere. 

* NOSL 3.0 does not obligate someone merely "using" the source code or the
software to distribute anything at all. 

* Source code must be made available by anyone who actually distributes the
software or derivative works thereof to third parties. (The definition in
NOSL 3.0 of "distribution" is important but not relevant to this thread.)

* Source code need not be distributed "with" products containing that
software. Typically, distribution of source code is handled through separate
links on websites, just as most open source software companies now
distribute software and source code.

* Products that incorporate unmodified copies of NOSL 3.0 software tools
rather than derivative works thereof can just inform customers to link to
the IETF website itself for source code. That also serves as a way for IETF
and its contributors to receive credit for writing that free and open source
software in the first place.

* The reciprocity obligation for derivative works and patents in NOSL 3.0 is
on purpose. Everyone is free to use those software tools for any purpose
whatsoever, but improvements to them *that are distributed to third parties*
must be returned to IETF for the potential benefit of other members of the
IETF community. 

* As you may have seen in recent discussions about the proposed IETF IPR
policies, one goal is to allow anyone to create and distribute products that
embody IETF standards under any license whatsoever. Whatever the outbound
license turns out to be for RFCs, it will presumably not dictate or limit
the license terms for products embodying those RFCs. For that reason alone,
NOSL 3.0 is not appropriate for RFC outbound licensing.

Further information about NOSL 3.0 and related licenses, is at
www.rosenlaw.com/OSL3.0-explained.pdf.  

For various reasons, AFL 3.0, also described in that paper, would perhaps be
a more appropriate outbound license for code in RFCs, but that too is a
topic for a potential separate thread.

Best regards,

/Larry

Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com) 
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243
Skype: LawrenceRosen
Author of "Open Source Licensing: Software Freedom and 
Intellectual Property Law" (Prentice Hall 2004)

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Margaret Wasserman
> Sent: Friday, March 28, 2008 11:30 AM
> To: Ray Pelletier
> Cc: Simon Josefsson; Joel M. Halpern; ietf@ietf.org
> Subject: Re: IETF Last Call for two IPR WG Dcouments
> 
> 
> Ray Pelletier wrote:
> > The Trustees adopted the Non-Profit Open Software License 3.0 in
> > September 2007 as the license it would use for open sourcing
> > software done as work-for-hire and that contributed to it, at that
> > time thinking of code contributed by IETF volunteers.  See:  http://
> > trustee.ietf.org/licenses.html
> >
> > Is it clear that the contributions contemplated by these documents
> > would require a different treatment?
> 
> 
> Disclaimer:  IANAL, and I apologize if I am misunderstanding
> something about the license you referenced, but...
> 
> It seems to me that the "Non-Profit Open Software License 3.0", while
> fine for the source code to IETF tools, places more restrictions and
> more burden on someone who uses the code than we would want to place
> on someone who uses a MIB, XML schema or other "code" from our RFCs.
> 
> For example, the license places an obligation on someone using the
> source code to distribute copies of the original source code with any
> products they distribute.  Effectively, this means that anyone who
> distributes products based on MIBs, XML schemas or other "code" from
> RFCs would need to put up a partial RFC repository.  Why would we
> want that?
> 
> Margaret
> 
> _

RE: IETF Last Call for two IPR WG Dcouments

[michael.dillon]

> c) to distribute or communicate copies of the Original Work 
> and Derivative Works to the public, with the proviso that 
> copies of Original Work or Derivative Works that You 
> distribute or communicate shall be licensed under this 
> Non-Profit Open Software License or as provided in section 17(d);

Is this a viral clause similar to that found in the GPL which
makes numerous commercial developers purposely avoid incorporating
such code into theirs? And in the IETF context, wouldn't this
clause encourage developers to create implementations that
ARE NOT COMPATIBLE WITH IETF STANDARDS?

Of course, IANAL but I really don't see why the IETF couldn't use
a licence which is basically the MIT or BSD licence possibly along
with some language about granting a patent license.

Is there a reason why the IETF does not submit its prospective license
to the OSI for approval? They know more about Open Source licences 
than anyone. There is more information here


--Michael Dillon
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

-outbound copying rights grant

[Joel M. Halpern]

The agreement was to let the trust work out the legal details.  This 
document is intended to tell the trust what we want, clearly and 
unambiguously.  The current text is unambiguous.  If we start trying to 
say that this or that specific license is a good starting point, then 
they have to figure out what aspects of that license we mean.
I certainly would not want to try to tell the lawyers what possible 
models there are to do their job.

Collapsing several other related notes:
No, I don't think that the agreement used for the code being written for 
the IETF will work (NOSL 3.0), since it is not as broad as described in 
this document.  (I do sometimes agree with Mr. Rosen.)
But I don't have any trouble allowing the trustees to do their job, 
which will include determining what license is appropriate.

Also, I don't see any need to point to specific examples to get at 
issues like "royalty free."  It is true that to meet the constraints, 
and the reality of RFC publication, the IETF license grant will be 
royalty free.  It's pretty hard to see how a license to permit anyone to 
do anything they want with the source code can be restricted by payments 
etc.

Remember, the state approach is for this document to state our goal, and 
for the trust to achieve what we ask.  The goal is not for us to 
shoehorn legal text into the outbound document.

Yours,
Joel

Peter Saint-Andre wrote:
> Joel M. Halpern wrote:
>> I do not understand the problem you want addressed.  The way this is 
>> worded, it doesn't matter what "open source" or "free software" is or 
>> becomes.  The intention is to grant anyone to do anything with the code 
>> segments.  That's what we ask the trust to do. Further in line.
> 
> I think Simon is suggesting that we provide some guidance to the Trust
> in choosing a license. IANAL, however the phrase "grant anyone to do
> anything" sounds nice in theory but needs to be translated into a
> functioning license. As far as I can see there are three licenses that
> would fit the bill:
> 
> 1. The MIT license
> 2. A BSD-style license
> 3. A designation that the code is in the public domain
> 
> Some people allege that it is not possible to put a work directly into
> the public domain (although I disagree), which is why they prefer to use
> a license.
> 
> As a point of comparison, the XMPP Standards Foundation recently worked
> to make sure that its specifications are safe for inclusion in free
> sofware, and decided upon a slightly-modified MIT license (modified in
> order to make clear that we were publishing specifications, not code).
> The resulting license is here:
> 
> http://www.xmpp.org/extensions/ipr-policy.shtml
> 
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call for two IPR WG Dcouments

[Peter Saint-Andre]

Lawrence Rosen wrote:
> Margaret Wasserman wrote:
>> Disclaimer:  IANAL, and I apologize if I am misunderstanding
>> something about the license you referenced, but...
>>
>> It seems to me that the "Non-Profit Open Software License 3.0", while
>> fine for the source code to IETF tools, places more restrictions and
>> more burden on someone who uses the code than we would want to place
>> on someone who uses a MIB, XML schema or other "code" from our RFCs.
>>
>> For example, the license places an obligation on someone using the
>> source code to distribute copies of the original source code with any
>> products they distribute.  Effectively, this means that anyone who
>> distributes products based on MIBs, XML schemas or other "code" from
>> RFCs would need to put up a partial RFC repository.  Why would we
>> want that?
> 
> As the author of the Non-Profit Open Software License 3.0 (NOSL 3.0),
> perhaps I can clear up some misconceptions about it.
> 
> * NOSL 3.0 is for software tools; it is not a standards license. It is not
> used as the outbound license for any code in RFCs, 

I understood Ray Pelletier to be suggesting that as a possibility, since
he said: "Is it clear that the contributions contemplated by these
documents would require a different treatment?" Which I took to mean
that NOSL 3.0 might be applied to the code snippets contained in RFCs.

> and thus there is no
> obligation that I'm aware of to put up a "partial RFC repository" anywhere. 

Not yet. :)

> * NOSL 3.0 does not obligate someone merely "using" the source code or the
> software to distribute anything at all. 

However, the same does not apply to Derivative Works.

> * Source code must be made available by anyone who actually distributes the
> software or derivative works thereof to third parties. (The definition in
> NOSL 3.0 of "distribution" is important but not relevant to this thread.)
> 
> * Source code need not be distributed "with" products containing that
> software. Typically, distribution of source code is handled through separate
> links on websites, just as most open source software companies now
> distribute software and source code.
> 
> * Products that incorporate unmodified copies of NOSL 3.0 software tools
> rather than derivative works thereof can just inform customers to link to
> the IETF website itself for source code. That also serves as a way for IETF
> and its contributors to receive credit for writing that free and open source
> software in the first place.
> 
> * The reciprocity obligation for derivative works and patents in NOSL 3.0 is
> on purpose. Everyone is free to use those software tools for any purpose
> whatsoever, but improvements to them *that are distributed to third parties*
> must be returned to IETF for the potential benefit of other members of the
> IETF community. 

That all makes perfect sense for the code produced by the Tools Team.

> * As you may have seen in recent discussions about the proposed IETF IPR
> policies, one goal is to allow anyone to create and distribute products that
> embody IETF standards under any license whatsoever. Whatever the outbound
> license turns out to be for RFCs, it will presumably not dictate or limit
> the license terms for products embodying those RFCs. For that reason alone,
> NOSL 3.0 is not appropriate for RFC outbound licensing.

Agreed.

> Further information about NOSL 3.0 and related licenses, is at
> www.rosenlaw.com/OSL3.0-explained.pdf.  

Reading.

> For various reasons, AFL 3.0, also described in that paper, would perhaps be
> a more appropriate outbound license for code in RFCs, but that too is a
> topic for a potential separate thread.

Thanks for the clarifications.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-klensin-rfc2821bis

[Ned Freed]

> Ned Freed wrote:
 
> > this entire exercise is focused on a move to draft with this revision

> In this case I'm a part of the rough, my focus is on "get it right"
> before the staus.  For 2822upd I'd be upset if it is no STD in 2010,
> 2821bis is different.

I completely and categorically disagree.

> > a move to draft is not the time to introduce new features.

> It's a trick to keep wild and wonderful new features out.  For the
> IPv6-fallback discussed in this thread "getting it right" is more
> important than the status.  Ideal case, 2821bis is good as is, and
> can replace the relevant parts of STD 10 in two years.

To the extent it's a trick, it's one intended to reach closure in something
less than geologic time.

> Worst case, we find that 2821bis should have no IPv6-fallback in
> two years, a 2821ter starting at PS would then take about five
> years before its successor can be at STD.

This is hopelessly optimistic. The odds are if this effort to move to draft
fails it will never happen period and we'll be stuck with even more
infrastructure reliance on proposed standard documents.

> With a modified 2821bis requiring PS now assuming again five years
> from PS to STD we'd be there 2013 instead of 2015 compared with the
> worst case, or in 2013 instead of 2010 compared with the ideal case.

> The question of the status PS / DS / STD alone IMO misses the point
> of getting it right.

And IMO this obsession on dotting every last I and crossing every last T is a
classic case of letting the best be the enemy of the good.

> > to be blunt I'm much more worried that if we delay long enough to
> > get consensus on this change and force a recycle at proposed the
> > necessary energy to move this document to draft won't be there
> > when it is possible to do so.

> No energy to fix it if necessary would be bad independent of the
> status.  And 2821bis as is fixes various things that needed to be
> fixed, whatever the outcome of the IPv6-fallback question and the
> status will be.

> IMO adding null-MX to 2821bis makes no sense technically, it is an
> IPv4 kludge, not something to be added to billions of IPv6 webcams
> or similar devices as "SMTP opt out".  OTOH a "SMTP opt in" by a
> mandatory MX for IPv6 could be okay.

I disagree with this as well, but I can live with either choice as long
as the current ambiguity gets resolved.

> > even then it has taken a huge amount of work.

> Sure, but SMTP is also important enough to deserve that much work.

You are SERIOUSLY underestimating how tired and out of sorts people are over
all of this.

> Actually it would have deserved more work from me, but when folks
> start whining about the status and not introducing new features at
> critical points this is pretty much demotivating, and I fear the
> outcome is not as good as it could have been without this "status
> first" group think.
 
Good. The "whining" as you call it pejoratively was intended to be demotivating
in regards to crammming new features into this document. Nice to hear it worked
to some extent. Too bad it didn't work even better.

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

Re: IETF Last Call for two IPR WG Dcouments

[Brian E Carpenter]

+1. I couldn't express it better.

   Brian

On 2008-03-29 04:54, Ted Hardie wrote:
> At 8:16 AM -0700 3/28/08, Simon Josefsson wrote:
>> "Joel M. Halpern" <[EMAIL PROTECTED]> writes:
>>
>>> I do not understand the problem you want addressed.  The way this is
>>> worded, it doesn't matter what "open source" or "free software" is or
>>> becomes.  The intention is to grant anyone to do anything with the code
>>> segments.  That's what we ask the trust to do. Further in line.
>> The problem is that without proper guidelines on how to make a software
>> license compatible with free software licenses, it is possible to end up
>> with something that won't be compatible, and thus wouldn't meet the
>> intended goals.
>>
>> Given that the IETF Trust doesn't publish drafts or have a history of
>> asking for community review on the legal license they chose, I believe
>> it is important that the IETF articulate its wishes in ways that reduce
>> chances of misunderstandings or are open for interpretation.
> 
> I disagree with Simon's addition.  The intent of the document is to
> give the Trust instructions from the community that we want
> the code in RFCs to be available to anyone to do anything.
> As Joel put it:
> 
> "The intention is to grant anyone to do anything with the code
> segments.  That's what we ask the trust to do. "
> 
> That was the consensus of the working group, and I believe it
> should remain the consensus of the IETF as a whole--it gives
> the widest possible reach to the standard.  Crafting the legal
> language to make that work is a task best left to lawyers;
> adding specific compatibility requirements that appear
> to privilege one set of follow-on outputs is both confusing and ultimately
> pointless.  The language in the draft is clear that we want
> the code to be usable by *anyone*.  It wouldn't add anything
> to that mandate to list specific individuals, and it doesn't
> add anything to list specific licenses that will only apply
> after an individual has already used the code.
> 
>   regards,
>   Ted
> ___
> 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

Gen-ART Last Call review of draft-ietf-sieve-notify-mailto-07

[Ben Campbell]

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.


Document: draft-ietf-sieve-notify-mailto-07
Reviewer: Ben Campbell  
Review Date:  2008-03-28
IETF LC End Date:  2008-03-31
IESG Telechat date: (if known)

NOTE: This is a review of version 07 of this draft. The gen-ART  
assignment was for version 06, but the draft was revised prior to my  
actual review.

Summary: This draft is almost (really close) ready for publication as  
a draft standard. I have a small number of comments that should be  
considered prior to publication.

Comments:

Section 2.7, third to last bullet on Page 6:

"URI headers with hname
   "received" are considered unsafe, and will be ignored."

Was that intended to be MUST be ignored? I noticed that similar  
statements are made about other header fields that do say MUST. It is  
not clear to me if this particular sentence was meant as normative  
language for the notifier, or descriptive language of what the  
recipient of the notification would do.

References:

IDNITS reports that draft-ietf-sieve-variables has been published as  
RFC 5229. Also, the [Notify] reference describes a very outdated  
version of that draft--I suggest checking all of the references to  
make sure they are current.

Editorial nits (opinions only--none of these need to block publication)

Section 1.1:

I found the first sentence a little hard to digest. I think it would  
read better if expanded into 2 or 3 sentences.

I also found the style of references disruptive to the flow of  
reading. The paragraph uses a rather clever overloading of references  
to serve as nouns in sentences. Although one can get away with this  
when the noun in question is the document being referenced, as in  
"...notations are as in [Sieve] section 1.1 ...", I find it visually  
disruptive to read "The [Notify] extension to the [Sieve] mail  
filtering language...". My brain keeps stopping to wonder what is with  
all the square brackets--it is not immediately clear from context that  
the brackets are there to denote references.

Thanks!

Ben.





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

Re: IETF Last Call for two IPR WG Dcouments

[Brian E Carpenter]

On 2008-03-28 20:14, Olaf Kolkman wrote:
> 
> On Mar 27, 2008, at 10:28 PM, Brian E Carpenter wrote:
>> While not really disagreeing with Leslie and Olaf, I would
>> point out that the IPR WG was chartered to look at
>> IETF documents.
> 
> Those being ietf-stream exclusively or implicitly also covering the
> iab-stream?

I think the clear separation defined in RFC 4844 was not so clear
at the time the WG took its major decisions. However, my personal
assumption was that we were only talking about the IETF stream.

> 
> Personally, I think it makes sense that the iab-stream is covered, but
> let me put that in front of the IAB too.

It makes sense to me that the IPR conditions for IAB documents
should be identical to those for IETF documents.

> 
>> We can have a meta-discussion about
>> where the clarifications belong, but it seems to me
>> that the WG consensus definitely assumed that scope
>> and no wider scope. I'd be happy if that was made
>> clear in the drafts, rather than trying to cover
>> the other documents streams by some kind of awkward
>> retro-fit.
> 
> 
> My suggestion is to rewrite  section 4 a bit to call out that this
> document does not cover the incoming rights for the independent and irtf
> stream and to use the terms "ietf-stream" and possibly "iab-stream" in
> the definitions.

As the responsibilities are defined in sections 5.1.1 and 5.1.2
of RFC 4844, it seems to me that an IETF-stream BCP can only
define the rules for IETF-stream RFCs. So I think the IAB would
need to issue its own IPR addendum to RFC 4845.

> 
> Such a rewrite would preserve the status quo for the independent and
> irtf stream.

If you're sure what the status quo actually is...

Brian
> 
> no-hats,
> 
> --Olaf
> 
> 
> 
> 
> On Mar 27, 2008, at 10:28 PM, Brian E Carpenter wrote:
>> While not really disagreeing with Leslie and Olaf, I would
>> point out that the IPR WG was chartered to look at
>> IETF documents. We can have a meta-discussion about
>> where the clarifications belong, but it seems to me
>> that the WG consensus definitely assumed that scope
>> and no wider scope. I'd be happy if that was made
>> clear in the drafts, rather than trying to cover
>> the other documents streams by some kind of awkward
>> retro-fit.
>>
>>   Brian
>>
>> On 2008-03-28 08:15, Leslie Daigle wrote:
>>>
>>> --On March 27, 2008 10:33:24 AM +0100 Olaf Kolkman <[EMAIL PROTECTED]>
>>> wrote:
 I would think that the document would gain in clarity if it explicitly
 ties the incoming rights to the streams as defined in RFC4844 and also
 explicitly calls out that if new streams would be defined those should
 specifically define if and how rights are transferred to the IETF
 Trust.
>>>
>>> I would have to agree with the above, and say further that the
>>> the IAB should make sure that the entities responsible for
>>> the non-IETF streams are okay with the result.
>>>
>>> When writing the streams definitions, it was clear that there was a
>>> lot of material that was spread across existing documents without
>>> clear delineation between "IETF" or "non-IETF" documents, let
>>> alone further refinement into what has become "streams".  THat's
>>> understandable, historically, but we should be clearer going
>>> forward.  Breaking it out, as you suggest, would be consistent
>>> with that goal.
>>>
>>> Leslie.
>>>

 While reviewing the documents I tried to determine how the 4 streams
 currently defined in RFC4844 fit into the framework.

 Although the stream is not specifically mentioned it is clear that the
 incoming rights document applies to the IETF Stream.

 To me it is clear that a contribution to the IAB is explicitly bound by
 the rules (including the No Duty to Publish rule, that allows for
 confidential information to be supplied to the IAB), so are
 contributions
 from the IAB, i.e. IAB stream document. I conclude this from the fact
 that "IAB" is part of the IETF under the definition in 1.e. However, I
 may be over-interpreting, and the status of the incoming rights for the
 IAB stream is also not captured.

 The independent stream document are clearly excluded by section 4 of
 the
 document.

 It is not quite clear where the IRTF stream document live. This
 could be
 fixed in a document which defines the IRTF stream.

 I would think that the document would gain in clarity if it explicitly
 ties the incoming rights to the streams as defined in RFC4844 and also
 explicitly calls out that if new streams would be defined those should
 specifically define if and how rights are transfered to the IETF Trust.



 --Olaf (no hats)

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

Re: IETF Last Call for two IPR WG Dcouments

[Henrik Levkowetz]

On 2008-03-28 18:49 Ray Pelletier said the following:

> The Trustees adopted the Non-Profit Open Software License 3.0 in 
> September 2007 as the license it would use for open sourcing software 
> done as work-for-hire and that contributed to it, at that time thinking 
> of code contributed by IETF volunteers.  See:  
> http://trustee.ietf.org/licenses.html 
> 
> Is it clear that the contributions contemplated by these documents would 
> require a different treatment?

My view on this:  Yes, definitely.  The two cases are very different,
and the kind of license which is needed and wanted is also very different.

In the case of work-for-hire for the IASA, we're talking about IETF-specific
code used to run the services needed by the IETF, such as for instance the
datatracker; and the purpose of using the OSL 3.0 license is that it is more
acceptable to commercial entities providing the services than GPL, while still
being clear on requiring derivative code used to provide services to be
contributed back as open source.

In the case of code embedded in standards documents, we want it to be as widely
used as possible, which as far as I'm concerned means limiting the requirements
on the users of the code as much as legally possible.  I'd love to have that
code put in the public domain, but as IANAL I have no idea whether that's
possible.


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

Re: Last Call: draft-klensin-rfc2821bis

[Frank Ellermann]

John C Klensin wrote:

> if you have wild and wonderful new features, write drafts,
> introduce them as separate, Proposed Standard, updates to
> 2821 that stand on their own, with their own justifications.

For one of the two discussed proposals, nullmx, that would be
easy enough, an old I-D exists.  Maybe you missed the point
that I'm not convinced that this is a good idea, and I do NOT
want to see nullmx as last minute addition to 2821bis.  For
technical reasons, not as a status question.

> the former would tend to hide from the reader that it is a
> new idea and one that is less tested and understood than
> the balance of 2821.  I don't believe the former is a good
> way to proceed, but that is just my opinion.

If "hiding" it deep in 2821bis is the point, trying to avoid
reviews, it would be wrong.  But I don't think that is what 
the nullmx proponents wanted, maybe they do not know that an
I-D exists, or they think it is a so perfectly obvious and
harmless idea that adding it to 2821bis is good.

Just in case again, I do NOT support nullmx in 2821bis, and
do NOT consider it as important enough to talk about it now
after the 2nd Last Call, and because it's in no way strictly
incompatible with 2821bis the proponents can try to revive
the existing I-D later.

> If you (or others, and you are clearly not the worst
> offender) have new and/or wonderful ideas, write them up
> in one or more I-Ds.

The IPv6-Fallback issue is something that clearly would be
incompatible with 2821bis-09, it is a now or never question.

So what I've done is to propose to talk about  and IPv6
at all in 2821bis, you've done that.  Shortly after that on
the DKIM list Doug said that the address fallback is really
bad.  That reminded me that Doug is not the first who said 
this, Meng Weng Wong among others also condidered this as
bad and back in 2004 even proposed to obsolete the fallback
in SPF.  For obvious reasons not the right place, so this
didn't fly.  Back in 2007 I forwarded the issue to the SMTP
list, in a way it was my fault that you added the missing
 in 2821bis everywhere, even for the "implicit MX" rule.

IIRC after a short discussion, maybe involving the notorious
"not for DS" way to suppress all good, bad, and ugly ideas,
the topic was dropped.

Doug mentioned it months later on the DKIM list again, and I
said that after the second Last Call is definitely too late,
and that folks supporting to remove "implicit MX" for IPv6
were a minority before (actually what I had in mind was the
minority consisting of Doug and me).  He nevertheless tried
it, and this time here on the general list "implicit MX" was
seriously discussed, maybe because the "climate" here is not
so suppressive as on the SMTP list.

It was not my idea to reopen this issue here, it was not my 
idea to close it, and whether you think that is a lunacy on
my side or not, various folks said that an "implicit MX" for
IPv6 is wrong, IIRC Doug, Keith, JohnL, and JohnL.  And Ned
for some hours.  

 Frank

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