Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
How about the IESG simply rescinds its decision in this week's meeting? I don't see any need for an appeal; if there's a prima facie violation of the disclosure rules, it's just a management item. Much less bother than an appeal. Of course, the rescission would be subject to appeal, but that's another story. Brian On 2009-11-19 15:02, Cullen Jennings wrote: > > On October 8, the IESG approved the registration of > application/3gpp-ims+xml Media Type. On Nov 2, RIM filed an IPR > disclosure related to this at > > https://datatracker.ietf.org/ipr/1219/ > > The associated patent, filed Oct 2008, is at > > http://www.google.com/patents?id=Mk7GEBAJ > > and the related draft is > > http://tools.ietf.org/html/draft-bakker-sipping-3gpp-ims-xml-body-handling > > I will note John-Luc Bakker from RIM is an author of both the patent > and and the draft. The draft has been widely discussed at IETF with no > mention of IPR before this. As an IESG member, I was not aware of this > IPR at the time the approval was made and I do not believe any other > IESG members were aware of it. I do believe the discussion would have > been different had the IESG been aware of this IPR. > > If anyone thinks this is, ah, inappropriate, I would recommend they > appeal the IESG decision to approve this. (see section 6.5 of RFC 2026 > for how this works). An IETF LC on this in the future would allow the > community to make an decision that was informed of the IPR. > > Cullen > > > > > > > > ___ > 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
RIM patents using a mime body in a message (and ignores IETF IPR rules)
On October 8, the IESG approved the registration of application/3gpp- ims+xml Media Type. On Nov 2, RIM filed an IPR disclosure related to this at https://datatracker.ietf.org/ipr/1219/ The associated patent, filed Oct 2008, is at http://www.google.com/patents?id=Mk7GEBAJ and the related draft is http://tools.ietf.org/html/draft-bakker-sipping-3gpp-ims-xml-body-handling I will note John-Luc Bakker from RIM is an author of both the patent and and the draft. The draft has been widely discussed at IETF with no mention of IPR before this. As an IESG member, I was not aware of this IPR at the time the approval was made and I do not believe any other IESG members were aware of it. I do believe the discussion would have been different had the IESG been aware of this IPR. If anyone thinks this is, ah, inappropriate, I would recommend they appeal the IESG decision to approve this. (see section 6.5 of RFC 2026 for how this works). An IETF LC on this in the future would allow the community to make an decision that was informed of the IPR. Cullen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RIM patents a URN (and ignores IETF IPR rules)
I'd like to draw peoples attention to the IPR disclosure https://datatracker.ietf.org/ipr/1213 on http://tools.ietf.org/html/draft-montemurro-gsma-imei-urn The associated patent seems to be http://www.google.com/patents/about?id=O7qXEBAJ Let me point out Mr. Allen is an author of both and a long time participant in IETF. Seems the 00 draft was from Oct 2006, the patent filed Jun 2005, and it seems we are just getting the IPR disclosure now. Given there are many ways to solve this sort of problem, and many of them are less likely to be IPR encumbered, I'd consider the possibility that the IESG should send this to the DISPATCH WG to see if they want to work on finding an appropriate solution to it. What do other people think the IESG should do with this draft? Cullen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
On Nov 18, 2009, at 9:45 AM, Paul Vixie wrote: >>> The IESG has received a request from an individual submitter to consider >>> the following document: >>> >>> - 'Multicast DNS ' >>>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 2009-12-16. 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. > > i support this proposal. +1 Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
Cullen Jennings wrote: > > Can someone walk me through the pro/cons of this being standards track > vs informational? > Apple supports it. Linux supports it (mostly). BSD supports it (mostly). So half the world supports it. When Microsoft too supports it, it is a standard. I do support it (becomming a standard). Well, making this a standard keeps people from building something colliding with existing implementations. Kind regards Peter -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: pe...@peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ULA= fd80:4ce1:c66a::/48 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Gen-art] Gen-ART LC review of draft-dusseault-http-patch-15.txt
Roy, At this point I think we're arguing in a circle, so I will simply wait to see what the authors and Area Director want to do next. A Gen-ART review has no more standing than any other Last Call comment. Regards Brian Carpenter On 2009-11-18 15:18, Roy T. Fielding wrote: > On Nov 17, 2009, at 11:53 AM, Brian E Carpenter wrote: > >> These are the sort of changes that would, I believe, give >> sufficient indication to a would-be user of PATCH of how >> to make it somewhat safe. Personally I'd prefer to see it >> made more prominent by starting with something like: >> >> Clients requiring to verify the consistent application of a >> patch document to a known entity SHOULD first acquire an ETag... >> >> Rationale: the use of a normative keyword will draw the >> attention of implementors who might otherwise not think >> about this issue. > > It would also be wrong, because it is neither a requirement > for interoperation nor a potential for causing harm (RFC 2119). > Aside from which, it makes the original purpose of PATCH > non-compliant with its own specification. > > The purpose of PATCH is to request that the server apply a > set of changes to the current state of the target resource. > The assumption that these changes will be dependent on a > specific prior representation of that resource is false. > The server is fully capable of detecting and reporting > conflicts when they occur with the current state, as only > truly known by the server. > > In other words ... > > If the client wants to prevent the PATCH method from being > applied to a resource for which the state has changed since > the last state known by the client, then it SHOULD use one > or more of the conditional request mechanisms of HTTP > (If-Match and If-Unmodified-Since request headers [RFC2616]) > or WebDAV (If request header [RFC4918]) with the > associated metadata from that prior resource state. > However, if the patch media type contains its own mechanism > for detecting conflicts, such as embedded context or metadata > designed to allow non-overlapping changes to be safely applied, > then the conditional request mechanisms SHOULD NOT > be used with PATCH because they would interfere with > collaborative applications, such as shared editors and > whiteboards. > > FTR, the prior sentence, that PATCH is somehow more likely > to result in corrupted state than a PUT, is simply false for > any patch format that contains context or post-application > integrity checks. The only reason it was in the spec is > because earlier versions assumed a patch format that contains > nothing but byte-vector manipulations. It should be removed, > or at least altered to be factual. > > Roy > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
SECDIR review of draft-ietf-pkix-new-asn1-07
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document updates the ASN.1 descriptions of several security- relevant data objects (e.g., CMS messages and S/MIME objects) from the 1988 version of ASN.1 to the 2002 version, without changing the structure expressed by these definitions -- there are no changes to bits on the wire. The document correctly states that this document itself creates no security issues, because it makes no changes to any protocols (it simply expresses the structure of those protocols in a different, updated syntax). The only minor concern I have is to be sure that the above claims about the lack of changes are true, i.e., that the ASN.1 syntax is correct. To ensure this correctness, I would recommend an expert review focused on the ASN.1, if one has not already been done. --Richard___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
> >The IESG has received a request from an individual submitter to consider > >the following document: > > > >- 'Multicast DNS ' > > 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 2009-12-16. 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. i support this proposal. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
On Wed Nov 18 15:41:18 2009, Cullen Jennings wrote: Can someone walk me through the pro/cons of this being standards track vs informational? Cons: For one thing, it's a lot of work to make a specification like this up to the quality of the standards-track. Some of the 20 or so mentions of Apple™ and its trademarks may be removed during the standardization work. It's much harder to get away with using apple.com™ for most of the example domains, for instance. The standards track doesn't mean anything anymore. It's so last decade. mDNS™ only really needs an RFC number, and a couple of trendy (preferably French™-sounding) product names carefully placed in the document. What if changes are demanded by those annoying DNS experts? That might break backwards compatibility with the existing deployment, starting from Apple™ Jaguar™ OS X™ 10™, in case I've not mentioned that in a few paragraphs. Pros: Only really annoying old stick-in-the-muds would think of anything positive to come out of making a consensus-driven, interoperable standards-track specification, which'd be almost completely out of the control of a single entity. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Question about draft-housley-iesg-rfc3932bis-12
> On Wed, Nov 18, 2009 at 12:54:35PM +1300, Brian E Carpenter wrote: > > > > Since we're (presumably) trying to write rules that will > > work when common sense has failed, it seems prudent to have > > a clear path for disputes of an unknown nature. > I get the sentiment, and I think it comes from a noble impulse, but I > think it's a temptation that should be avoided. Agreed. > If we get to the point where the IESG, the RFC Editor, and the IAB > can't among them work out a sensible compromise (because common sense > has failed), then we have much bigger problems than getting things > published on the Independent Submissions track. > Maybe I watched too much _Brazil_ on the weekend, but this all seems > to me to be the sort of arrangement that can only lead to harm. Given > the number of iterations the draft has been through, and the volume of > mail it has attracted, I expect the current form is likely as close to > good as it will get (since we still have a fail safe: the IAB can put > a pox on all the houses). But I don't believe solving a problem we > don't actually have is a good idea. Exactly my thinking on the matter. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Question about draft-housley-iesg-rfc3932bis-12
>If we get to the point where the IESG, the RFC Editor, and the IAB >can't among them work out a sensible compromise (because common sense >has failed), then we have much bigger problems than getting things >published on the Independent Submissions track. +1 We're software and network guys (and gals, of course) which means that we delight in identifying and dealing with edge cases to try and cover every possibility. In human affairs, though, no matter how many cases you try to anticipate, down at the bottom of the list of alternatives you always end with else die(); If we get anywhere near that point, I see little reason to think that the parties involved, who would by then have been arguing for months if not years, would be inclined to follow any procedure at all. For better or worse, the IETF only works because the people involved are more or less reasonable, and nothing we could write down would change that. R's, John PS: Note that this principle applies to any process we might design, not just this one. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
Can someone walk me through the pro/cons of this being standards track vs informational? Thanks, Cullen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Question about draft-housley-iesg-rfc3932bis-12
On Wed, Nov 18, 2009 at 12:54:35PM +1300, Brian E Carpenter wrote: > > Since we're (presumably) trying to write rules that will > work when common sense has failed, it seems prudent to have > a clear path for disputes of an unknown nature. I get the sentiment, and I think it comes from a noble impulse, but I think it's a temptation that should be avoided. If we get to the point where the IESG, the RFC Editor, and the IAB can't among them work out a sensible compromise (because common sense has failed), then we have much bigger problems than getting things published on the Independent Submissions track. Maybe I watched too much _Brazil_ on the weekend, but this all seems to me to be the sort of arrangement that can only lead to harm. Given the number of iterations the draft has been through, and the volume of mail it has attracted, I expect the current form is likely as close to good as it will get (since we still have a fail safe: the IAB can put a pox on all the houses). But I don't believe solving a problem we don't actually have is a good idea. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-melnikov-imap-keywords-06
Hi Samuel, Thank you for the review. Samuel Weiler wrote: I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. From a security perspective, I have no issues with this document. It creates a new registry and defines two sets of assignment metrics, one for "common use" keywords, and one for vendor-specific keywords. It also registers four keywords. (I'm wondering if it shouldn't be registering more.) Further registrations will be done by the designated expert. I am concerned that if I put all of them in the document, then the document will never finish. I'm finding the IANA assignment metrics to be a little more ambiguous that I'd like. Starting with the vendor-specific text: Registration of vendor specific IMAP keywords is done on First Come First Serve [RFC5226] basis and doesn't require the Expert Review. However such review is still encouraged. Should the review be requested, ... Who requests the review? The registrant or IANA? Good question. I was thinking about the registrant. But IANA requesting review would be a good idea as well. Does IANA need to encourage the review? Perhaps it would be better to have all requests (including vendor-specific) be sent to the mailing list, with IANA assignment of the vendor-specific ones being automatic following a (short) delay for comment and optional revision. Ok, I've implemented this procedure in my copy. And for the common-use: Registration of an IMAP keyword intended for common use (whether or not they use the "$" prefix) requires Expert Review [RFC5226]. IESG appoints one or more Expert Reviewer, one of which is designated as the primary Expert Reviewer. IMAP keywords intended for common use SHOULD be standardized in IETF Consensus [RFC5226] documents. ... In cases when an IMAP Keyword being registered is already deployed, Expert Reviewers should favour registering it over requiring perfect documentation. Would it be better to say: "requires either IETF Consensus or Expert Review"? Not everybody is subscribed to ietf or ietf-announce mailing lists, so I would like for all common use registrations to go through the expert. (For example: do the registrations made in this doc have to go through Expert Review? No, because they are a part of the document that creates the registry ;-). Isn't it enough to have them in a consensus doc?") And how do you expect the expert to encourage/enforce the SHOULD, given the "favour registering it over requiring perfect documentation" guideline? Again, the current text isn't as clear as I'd like. This is intentional. This is a judgment call by the expert. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
