Re: Obnoxious license
Rick el...@spinics.net writes: In article 6.2.5.6.2.20090813134034.0331e...@elandnews.com, SM s...@resistor.net wrote: I was discussing RFC 5617 with someone and the person mentioned that the copyright in the middle of the document is obnoxious. The copyright statement for the code is 32 lines while the code (ABNF) is only five lines. Can a copyright even be valid for just five lines of code? I'm told that in some jurisdictions even one line of code is sufficient. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Obnoxious license
SM wrote: Hello, I was discussing RFC 5617 with someone and the person mentioned that the copyright in the middle of the document is obnoxious. The copyright statement for the code is 32 lines while the code (ABNF) is only five lines. If an author wants to include the statement in a RFC for the sake of completeness, is it possible to have the statement in a paragraph near the end of the document and put in a note before the ABNF to refer to it? Regards, -sm Oh my. Could somebody clarify what the current situation with respect to ABNF is? Our WG documents (HTTPbis) contain ABNF fragments all over the place, and we're definitively NOT going to insert a copyright statement everywhere. BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Obnoxious license
1) There is no need to put licenses in the RFC at all. In fact, the trust document says clearly that putting license text in RFCs is a bad idea. 2) The trust policy states that when code is extracted from an RFC, it must be marked for attribution, and that the extractor can modify and use the code as they see fit. The license marking is on the extracted code, and is specifically to meet those goals. THE TRUST IS DOING WHAT WE ASKED THEM TO DO. 3) In order to determine what is code within an RFC, the trust has published a list: http://trustee.ietf.org/docs/Code-Components-List-4-23-09.txt That list includes ABNF. And XML Schema, and... 4) If you want something in your RFC treated as code, and it is not in that list, then you need to mark it with CODE BEGINS CODE ENDS 5) The trust as said publicly that they are looking into whether there is a practical way for the person who extracts code from an RFC to use a shorter license in their extraction. Yours, Joel Julian Reschke wrote: SM wrote: Hello, I was discussing RFC 5617 with someone and the person mentioned that the copyright in the middle of the document is obnoxious. The copyright statement for the code is 32 lines while the code (ABNF) is only five lines. If an author wants to include the statement in a RFC for the sake of completeness, is it possible to have the statement in a paragraph near the end of the document and put in a note before the ABNF to refer to it? Regards, -sm Oh my. Could somebody clarify what the current situation with respect to ABNF is? Our WG documents (HTTPbis) contain ABNF fragments all over the place, and we're definitively NOT going to insert a copyright statement everywhere. BR, Julian ___ 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: Obnoxious license
Julian Reschke wrote: SM wrote: Hello, I was discussing RFC 5617 with someone and the person mentioned that the copyright in the middle of the document is obnoxious. The copyright statement for the code is 32 lines while the code (ABNF) is only five lines. If an author wants to include the statement in a RFC for the sake of completeness, is it possible to have the statement in a paragraph near the end of the document and put in a note before the ABNF to refer to it? Regards, -sm Oh my. Could somebody clarify what the current situation with respect to ABNF is? Our WG documents (HTTPbis) contain ABNF fragments all over the place, and we're definitively NOT going to insert a copyright statement everywhere. In the documents I've worked on, it seems that they just want to put the statement in the section that collects all the ABNF, ASN.1, XML, etc. spt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Obnoxious license
Can a copyright even be valid for just five lines of code? I'm told that in some jurisdictions even one line of code is sufficient. Wow. That seems patently silly. Am I too late to copyright all calls to malloc() and free()? :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Obnoxious license
Sean Turner wrote: ... In the documents I've worked on, it seems that they just want to put the statement in the section that collects all the ABNF, ASN.1, XML, etc. ... Who is they, and how is that consistent with what Joel just told us? BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Obnoxious license
Julian Reschke wrote: Sean Turner wrote: ... In the documents I've worked on, it seems that they just want to put the statement in the section that collects all the ABNF, ASN.1, XML, etc. ... Who is they, and how is that consistent with what Joel just told us? This might be overtaken by events, but I believe the they was the IESG because they added the following RFC editor notes to the ASN.1 modules in the these two documents: https://datatracker.ietf.org/idtracker/ballot/3053/ http://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=934k2=6530tid=1250356550 spt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Obnoxious license
I would consider that OBE. As I understand it, the trust procedures no longer require those license statements in RFCs. Yours, Joel Sean Turner wrote: Julian Reschke wrote: Sean Turner wrote: ... In the documents I've worked on, it seems that they just want to put the statement in the section that collects all the ABNF, ASN.1, XML, etc. ... Who is they, and how is that consistent with what Joel just told us? This might be overtaken by events, but I believe the they was the IESG because they added the following RFC editor notes to the ASN.1 modules in the these two documents: https://datatracker.ietf.org/idtracker/ballot/3053/ http://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=934k2=6530tid=1250356550 spt ___ 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: Obnoxious license
I would consider that OBE. As I understand it, the trust procedures no longer require those license statements in RFCs. As of a few days ago it certainly did. Otherwise we wouldn't have put the license into RFC 5617 for the two lines (five after folding for margins) of ABNF. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: review of draft-zorn-radius-pkmv1-04.txt
Bernard Aboba [mailto://bernard_ab...@hotmail.com] writes: ... encapsulation using RFC 2548 MPPE-Key attributes... I was unclear about how this is supposed to work. Is the idea to apply the MPPE-Key encryption mechanism to the attribute specified in the draft, No. or is the idea to actually use the MPPE-Key attributes themselves? Yes. If the former, more detail should be provided. If the latter, is it necessary to define two attribute formats or would it be simpler to go with one? The PKM-AUTH-Key Attributes contains data that is to be delivered via 802.16 to the Subscriber Station (SS); the Key field in that attribute is encrypted under the public key of the SS. However, the BAS also needs to know the key; that is what would be transferred (presumably and unfortunately) in the MPPE-Send-Key Attribute. If the RFC 2548 MPPE-Key attributes are used, is the format the same as that defined in RFC 2548 (just a wrapped key) or is the wrapping applied to a complex attribute? Just a copy of the contents of the Key field in the PKM-AUTH-Key Attribute. a four octet Integer should be used instead of a two octet data type (which doesn't exist in RADIUS) As I recall, the security exemption didn't apply to creation of new RADIUS data types, correct? It's a 2 octet string. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: AD review of draft-zorn-radius-pkmv1-04.txt
d.b.nel...@comcast.net wrote: Yeah. I've always been a bit uncomfortable with the security functionality escape clause in the RADIUS Design Guidelines draft. Lots of things can reasonably be claimed to be security related. I would have preferred the exception to be crafted a bit narrower, just for this reason. But, unless wording of Design Guidelines is changed, you have a legitimate argument. I believe the intent was related to RADIUS security. This statement puzzles me: section 2.1.3 of the design guidelines document says: As can be seen in Appendix B, most of the existing complex attributes involve authentication or security functionality. Supporting this functionality requires code changes on both the RADIUS client and server, regardless of the attribute format. As a result, in most cases, the use of complex attributes to represent these methods is acceptable, and does not create additional interoperability or deployment issues. But none of the Attributes mentioned in Appendix B have anything to do with RADIUS security as I understand it. Can you explain? The guidelines document could be updated to address this. RADIUS could transport parameters for *another* protocol. Like EAP? Those attributes are not security related. I see. What attributes (besides Message-Authenticator) are related to RADIUS security? They either follow the RADIUS data model (int, IP address, etc.), or they are opaque data that RADIUS is simply transporting on the behalf of the other protocol. Alan DeKok. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
