From: Toerless Eckert <tte@xxxxxxxxx>
Sent: 12 August 2024 08:41
Subject: [Last-Call] Re: Last Call: <draft-wkumari-rfc8110-to-ieee-02.txt> (Transferring Opportunistic Wireless Encryption to the IEEE 802.11 Working Group) to Informational RFC
Thanks, S.
I am also not a legal expert, which is why i am asking here so that
someone who would know the correct legal answer could provide it:
AFAIK, if RFC8110 and draft where IETF WG product, the authors would be irrelevant
for the purpose of granting whatever the draft is granting to IEEE - because its
a WG/IETF (track) product. Given how the RFC and draft seem to be AD sponsored,
i am totally unclear how the status is now different. And given how the draft
talks about IETF handin over work to IEEE, its even less clear to me, what that
authors have to do with the handover. Aka: Only the IETF can handover something
pertaining to the IETF, right ?
<tp>
Mmmmmm where to start? When I have has a contract of employment or the like, then it has laid down who has the rights to anything original I produce. That is not the case here. The rights are mine and remain mine. There is no contract with the IETF (I use the term loosely) that stops me posting what I say in other places.
The IETF process of producing RFC wants me to grant rights to them so that they can publish the RFC. I have done so in the past. That grant is not exclusive. Look at what the IETF asks for and it should be clear that that does not take away my rights in my original material. I can grant rights to any one else I choose, for example to another SDO, to a publisher of a magazine and so on. That recipient may want exclusive rights restricting use by others in which case I may have a problem but it is my problem, nothing to do with the IETF to whom I have granted rights which are not exclusive..
Perhaps the issue here is the word 'rights' which covers a wide spectrum of issues which at times need to be teased out and handled separately.
HTH
Tom Petch
p.s. I do not have legal qualifications in this area. I did track the WG a few decades ago that came up with the relevant RFC.
Not meant to dismay the authors or the work in any way. Purely from a legal perspective.
Aka: i find the comments from JohnL that you refer to confusing...
Btw: The liason statement from IEEE would be quite useless for the case of this
work given how it is not a WG result. The liaison statement only grants rights
to WG chairs. So not even AD sponsort would be covered, e.g.: if an AD would need
to pass on IEEE WG work to some authors whose work the AD is sponsoring.
Cheers
Toerless
On Sun, Aug 11, 2024 at 09:32:13AM -0700, S Moonesamy wrote:
> Hi Toreless,
> At 12:51 AM 11-08-2024, Toerless Eckert wrote:
> > 1. S: How are the original RFC8110 authors relevant when the RFC and the new
> > draft are IETF AD sponsored instead of ISE track ?
>
> I'll disclose that I am not a legal expert.
>
> From what I understood, it has something to do the rights which an author
> provides to the IETF. There is a discussion of that topic in BCP 78.
>
> John Levine wrote that the authors of the draft and RFC 8110 are the same
> persons:
> https://mailarchive.ietf.org/arch/msg/last-call/hq_inaOfkqbzVaNiOWHdAIOxlxs/
> That matches my reading of the two documents. Now, if the authors were
> different, there could be other questions which come into play. However,
> that's not the case here.
>
> The draft is AD-sponsored:
> https://mailarchive.ietf.org/arch/msg/last-call/VyVxlbdkZsn-qqcm6pYlA7twnHc/
> As it is an IETF thing, I don't have to say anything about the ISE track.
> :-)
>
> > 2. Of course, if further progress on this technology is something the IETF
> > does not care about, it does make sense to make it as easy as possible for
> > IEEE do this work. I am not sure whether the draft achieves this because
> > of 1. I don't understand from the draft what exactly the IETF promises to
> > change in its behavior, or what legally changes - if anything. E.g.: is this
> > a promise to never ever touch anything related to rfc8110 ?? Has the IETF
> > ever made such a promise, e.g.: prior examples ?
>
> The following file is a patch which was sent to an open source project:
> https://www.freebsd.org/security/patches/SA-19%3A03/wpa-12.patch My reading
> of the patch is that someone implemented RFC 8110. If I am not mistaken, it
> has something to do with "Enhanced Open" security.
>
> Tom Petch pointed to RFC 4663:
> https://mailarchive.ietf.org/arch/msg/last-call/NZ2ijGqeOoJWXMjxoAPd0qMMTrY/
> It's an example of what was done before. There may be some differences
> between the that example and the matter on hand. I would have to give more
> thought, and maybe seek external expertise, to figure all that out.
>
> Someone might wish to ask for some thing about RFC 8110. It would help if
> there was a pointer so that the person can find out which "standards"
> organization maintains the specification. "Maintains" means "Hold for
> document update" in IETF parlance.
>
> The IETF would be unable to make promises unless the "I" is a person. As a
> side comment, I cannot make promises on behalf of the IETF. It seems like
> there is a volunteer willing to take responsibility for the "I":
> https://mailarchive.ietf.org/arch/msg/last-call/VyVxlbdkZsn-qqcm6pYlA7twnHc/
>
> > 3. I very much hope that the IEEE provides an equal or better opportunity
> > for those interestd to work on updates as IETF would. I am not sure this is
> > the case. Seems as if there is at least a potentially significant
> > membership fee associated with working in IEEE SA.
>
> Please see https://www.ietf.org/lib/dt/documents/LIAISON/file41.pdf
>
> > 4. What happens if this draft does not become RFC ?
>
> The contact persons listed at https://datatracker.ietf.org/liaison/1929/
> would have to come up an explanation.
>
> Regards,
> S. Moonesamy
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
