Re: where to send RFC 5378 license forms
On Mon, Dec 29, 2008 at 11:19 AM, Simon Josefsson si...@josefsson.orgwrote: Donald Eastlake d3e...@gmail.com writes: On Fri, Dec 19, 2008 at 5:30 AM, Simon Josefsson si...@josefsson.org wrote: ... If you are updating a pre-RFC 5378 document that contains trademarked words, it isn't sufficient for the old contributor to have signed the IETF Trust form if the document contains trademarks. You need to contact him anyway, to get permission to reproduce the trademark. /Simon You should consult an attorney but, as far as I know, at least in the US, there is no magic permission needed to reproduce a trademark. Usually trademarks are to indicate the source of a product or service and as long as you don't mislead people about that, you are fine. Then what use does section 3.4 of RFC 5378 serve? There is a reason I suggested you consult a real lawyer, but I suppose bars the authors of an RFC from later making a claim that the RFC or derivative works infringe on the trade mark, that is to say, leads to confusion as to the source of some good of service. 3.4. Rights to Use Trademarks Contributors may wish to seek trademark or service mark protection on any terms that are coined or used in their Contributions. The IETF makes no judgment about the validity of any such trademark rights. However, the IETF requires each Contributor, under the licenses described in Section 5.3 below, to grant the IETF Trust a perpetual license to use any such trademarks or service marks solely in exercising rights to reproduce, publish, discuss, and modify the IETF Contribution. This license does not authorize the IETF or others to use any trademark or service mark in connection with any product or service offering. It was co-authored by the IETF attorney, so I suspect it is intended to serve some purpose. See my comment above. If it serves a purpose, contributors needs to get the necessary right and be able to transfer it to the IETF Trust in order to submit a contribution. As far as I understand, that would involve talking with the old contributor if trademarks are involved. That does not follow. No license is needed for non-infringing use of a trade mark but granting even an unnecessary license probably makes it harder to get very far with a law suit against the IETF transferring some of a very small risk from the IETF to the contributor. There is no way to be perfectly safe in the current legal system but doing anything, including producing or publishing any document, probably increases your risk. Do you believe that Jon Postel or its current authors needed to get the necessary right to publish each of the large number of trademarks in STD 1 (currently RFC 5000)? /Simon Thanks,Donald = Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: The internet architecture
I spent several years trying to discern what the IETF's Internet Architecture became when we abandoned our historic architecture and started growing the middle of the hour glass through middleboxes and telephony-originated techniques. For several years in the early 2000s I became convinced that we had no architecture and I lamented that fact. Recently I realized that we had stumbled upon a common architecture but hadn't yet realized it -- map-and-encaps is our current Internet architecture. I believe that the techniques described in Fred Templin's current I-D trilogy should be re-written to state that those techniques describe our current de facto Internet architecture. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART Last Call review of draft-korhonen-mip4-service-06
Hi Spencer, On Dec 29, 2008, at 6:13 PM, Spencer Dawkins wrote: Hi, Jouni, Thanks for your quick response - I'm OK with most of your proposed changes. I should emphasize that my comments here are Last Call comments that you (and the document shepherd, and the AD) can decide to ignore - I'm just telling you what I'm seeing when I read the text. Just to finish up: Some of the potential use-cases were listed earlier in this section. The general aim is better manageability of services and service provisioning from both operators and service providers point of view. However, it should be understood that there are potential deployment possibilities where selecting a certain service may restrict simultaneous access to other services from an user point of view. For example, services may be located in different administrative domains or external customer networks that practice excessive filtering of inbound and outbound traffic. Spencer: I wasn't clear on who this understanding is directed to - it almost reads like you're warning users that bad things might happen if you use a specific service, but surely the user specifies the service because an operator requires this? We had this discussion earlier on RFC5149.. and concerns were raised whether the Service Selection is a potential tool for enabling walled gardens etc. Thus this note here was added to emphasize that point. I understand your point from your explanation, but can't get that understanding from the draft text. If you said s/from a user point of view/from a user point of view (for example, a walled garden)/ that would be as clear as your explanation. Ok. Thanks. Will add this. 3. Service Selection Extension At most one Service Selection extension MAY be included in any Mobile IPv4 Registration Request message. It SHOULD be included at least in Spencer: seems to be missing a qualifier: When a non-default service is selected, the Service Selection extension SHOULD be included ...? Spencer: If this is qualified, could the SHOULD be a MUST? Hmm.. right. New text would be: At most one Service Selection extension MAY be included in any Mobile IPv4 Registration Request message. When a non-default service is selected, the Service Selection extension SHOULD be included at least in the Registration Request message that is sent for the initial binding registration when the mobile node and the home agent do not have an existing binding. The Service Selection extension MUST be placed in the Registration Request message as follows: Spencer: If it remains as SHOULD, what happens if the Service Selection extension is not included in the initial binding registration, but is included in subsequent binding registrations? The first RRQ would be treated as the selection of the default service. The subsequent RRQs with the service selection would cause reauthorization evaluation of the requested service. If the newly requested service conflicts with the default service from the HA point of view, then an appropriate error is returned and the binding is dropped. I'm still confused by When a non-default service is selected, the Service Selection extension SHOULD be included at least in the Registration Request message that is sent for the initial binding registration when the mobile node and the home agent do not have an existing binding. My understanding from your explanation is that, by definition, if you don't include the Service Selection extension, you aren't selecting a non-default service until you DO send an RRQ that includes the Service Selection extension - right? If I'm tracking you, you're talking about two cases at the same time - what happens if you DO include the extension in the first RRQ, and what happens if you DON'T include the extension in the first RRQ, then switch to a non-default service by including the Service Selection extension in a subsequent RRQ - that would be why I was confused. I think your explanation is way clearer than the draft text - perhaps you could insert it into the draft text? A new try: At most one Service Selection extension MAY be included in any Mobile IPv4 Registration Request message. The Service Selection extension SHOULD be included at least in the Registration Request message that is sent for the initial binding registration when the mobile node and the home agent do not have an existing binding. In absence of a specifically indicated service in the Registration Request for the initial binding registration, the home agent MUST act as if the default service, such as plain Internet access had been requested. The absence of the Service Selection extension in a Registration Request that refreshes an existing binding MUST be treated as if the existing service selection is maintained. The Service Selection extension MUST be placed in the Registration
Re: The internet architecture
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tony == Tony Finch d...@dotat.at writes: Most networkable consumer electronics ships with at least two network interfaces. Host multihoming is only rare because it doesn't work. Why do you say it doesn't work ? Tony The kind of multihoming I am talking about is where you are Tony using multiple links for redundncy or resilience - i.e. the Tony same reasons for site multihoming. I did not mean other kinds I think it says something to the extreme *rarity* of host multihoming (for systems that initiate connections) that there is even this confusion. You can be multihomed with one physical interface. This is rather more common for machines that mostly accept connections (web servers), as you can do relatively simple source address based policy routing. (If it's ISP-A's address in the source field, use ISP-A) I haven't read every one of the emails in this thread: but where are the shim6 people? Maybe they are busy writing drafts + code. - -- ] Y'avait une poule de jammé dans l'muffler!| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic(Just another Debian GNU/Linux using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSVqY7ICLcPvd0N1lAQK4LAf9FlJKpbcjCSDs/R3/C4xPvi7j4vBsLn0V b1POJgfZ1T3dbbVV1nBsDDgnnV3RWoimToSvsUC0ZSiJ7rCfuiDDpfcwrSvPfPP+ 6B9/R2hE0BkgJfn9zKj/25cASkqfH9HBs6ZKOl5i6WwWMamDLqp6dfdT+cVUdGtV TZTAMcBpk/IOpFYtwqvN3x5TyKFnkokArEbje0c+ceWjXbHaM/eh30tR/knbPrTh JadZoeGmB2NyoLG6243aBIDydwC7AB2O4Uz74Ivx73qCAj1UYFR592miA6O+tQAH /M9fqUtdJetnRkhCdDf5JjmIbjF2Jmw7We2vqzQkJWfiwc4UUJQJsQ== =KDlL -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
ISOC BOT selection timeline
L.S. The IAB is announcing its timeline for the appointment of a member of the Internet Society (ISOC) Board of Trustees, as described in BCP 77 (RFC3677). The IAB selects one person for a three-year ISOC BoT term every year. This year, the IAB will select one person for a term ending in spring 2012. The IAB will issue a call for nominations on the ietf-announce at ietf.org list on January 12 with an open nomination period running until February 22. The names of all people who declare themselves willing to serve will be made public on the ietf-announce at ietf.org list after the end of the solicitation period. The IAB expects to finalize its selection on April 2. The IESG will confirm the candidate by May 15 and he or she will begin serving as the new board of trustee member in June. Olaf Kolkman, IAB Chair. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
The Internet architecture - pointer to MIF (Multiple Interfaces) discussion
Hello,all We have setup an mailing list to discuss the host which would like to use multiple interfaces. several issues has been identified based on problem statement. http://www.ietf.org/internet-drafts/draft-blanchet-mif-problem-statement-00.txt Please be awared that it is different from multihoming (site with multiple interfaces). Please feel free to join our discussion over there, https://www.ietf.org/mailman/listinfo/mif thanks -Hui ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 Trademarks (was where to send RFC 5378 license forms)
--On Tuesday, December 30, 2008 10:32:12 AM -0500 Contreras, Jorge jorge.contre...@wilmerhale.com wrote: For background, the trademark license was included in RFC 3978 because someone was concerned about Contributors who submitted documents to IETF for standards-track use and included trademarked product names in them. The IETF wanted to ensure that the IETF process would not be hindered by the Contributor, and also wanted to ensure that the trademarks were identified so that implementers would not be surprised by the trademark owner's claim after a standard was adopted. To be clear, this was not idle paranoia. Like many (not all) of the poor behaviors our processes attempt to protect against, this is something that working groups have actually seen happen. -- Jeffrey T. Hutzelman (N3NHS) jhu...@cmu.edu Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-pkix-rfc4055-update (Update for RSAES-OAEP
Algorithm Parameters) to Proposed Standard Reply-to: i...@ietf.org CC: ietf-p...@imc.org The IESG has received a request from the Public-Key Infrastructure (X.509) WG (pkix) to consider the following document: - 'Update for RSAES-OAEP Algorithm Parameters ' draft-ietf-pkix-rfc4055-update-01.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-01-19. Exceptionally, comments may be sent to i...@ietf.org 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-pkix-rfc4055-update-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16882rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-pim-rpf-vector (The RPF Vector TLV) to Informational RFC
The IESG has received a request from the Protocol Independent Multicast WG (pim) to consider the following document: - 'The RPF Vector TLV ' draft-ietf-pim-rpf-vector-06.txt as an Proposed Standard 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 i...@ietf.org mailing lists by 2009-01-19. Exceptionally, comments may be sent to i...@ietf.org 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-pim-rpf-vector-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=12986rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
ISOC BOT selection timeline
L.S. The IAB is announcing its timeline for the appointment of a member of the Internet Society (ISOC) Board of Trustees, as described in BCP 77 (RFC3677). The IAB selects one person for a three-year ISOC BoT term every year. This year, the IAB will select one person for a term ending in spring 2012. The IAB will issue a call for nominations on the ietf-announce at ietf.org list on January 12 with an open nomination period running until February 22. The names of all people who declare themselves willing to serve will be made public on the ietf-announce at ietf.org list after the end of the solicitation period. The IAB expects to finalize its selection on April 2. The IESG will confirm the candidate by May 15 and he or she will begin serving as the new board of trustee member in June. Olaf Kolkman, IAB Chair. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
