Re: Gen-Art Review: draft-ietf-nsis-qspec-22.txt

[Magnus Westerlund]

Hi Joel and Jerry,

Yes, these are clearly left overs before forcing all the documents into
experimental. I commented in AD review about registration rules
requiring standards track. Which I believe is fixed, but the comments in
the document seems to not have been fixed.

Secondly I think we need to have a discussion on the intended status of
the document. I think I personally do have a preference for publication
as experimental. I agree that it defines so much of the data format and
its rules that it makes sense to have it on the experimental track,
rather than informational.

More views and arguments please.

Magnus

Joel M. Halpern skrev:
> If the problem is that the base documents are experimental, then I am
> very confused by the repeated references in the document to standards
> track documents for defining new state machine transitions.  If that
> state machines are standards track, it would seem that the QoS encodings
> for those state machines ought to be standards track as well.
> 
> If the state machines are not standards track, then it would seem that
> this document should be experimental, to match the rest of the set.
> 
> Yours,
> Joel
> 
> Gerald Ash wrote:
>>
>> Joel,
>>  
>> Thanks for the quick review.  I agree with all your comments and
>> suggestions.
>>  
>> Regarding your suggestion on RFC type (change it from Informational to
>> PS), I believe it could not become PS since the other NSIS documents
>> (GIST & QoS-NSLP) are Experimental.
>>  
>> Thanks again,
>> Jerry
>>
>> --- On *Sat, 11/21/09, Joel M. Halpern //* wrote:
>>
>>
>> From: Joel M. Halpern 
>> Subject: Gen-Art Review: draft-ietf-nsis-qspec-22.txt
>> To: "General Area Review Team" , "Mary Barnes"
>> 
>> Cc: "Magnus Westerlun" , "IETF
>> discussion list" , n...@ietf.org,
>> draft-ietf-nsis-qs...@tools.ietf.org
>> Date: Saturday, November 21, 2009, 6:32 PM
>>
>> 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-nsis-qspec-22
>> QoS NSLP QSPEC Template
>> Reviewer: Joel Halpern
>> Review Date: 21-Nov-2009
>> IETF LC End Date: 25-Nov-2009
>> IESG Telechat date: N/A
>>
>> Summary: This document is almost ready for publication as an RFC.
>> I am concerned about the RFC type.  If a revision of the document is
>> needed, there are a few minor items to consider for inclusion.
>>
>> Major:
>> I am unclear about whether the intended status (Informational) for
>> this document is correct.
>> At first, it seemed correct.   The document is defined as providing
>> a template for a resource specification block (a QSPEC), and other
>> model specific documents are expected to define exactly what QoS
>> paramters they will use.
>> It even seemed fine that this document mandates that the QSPEC
>> include the indication of the QoS Model.  That is necessary
>> information.
>>
>> Where I start to have concerns is in section 3.1 of this document.
>> There, the document starts specifying requirements on any and of QoS
>> Model documents.  It says things like "A QOSM specification MUST
>> include the following:".  If this document is defining normative
>> requirements for standards track documents (and the text explicitly
>> states that QOSM definitions sometimes need to be standards track),
>> then I don't see how it can be an informational document.
>> If the QOSM requirements, and the QSPEC support requirements ("The
>> QSPEC objects ... MUST be supported by QNEs.") are actually copied
>> from some other document, then the problem is a lesser issue of
>> unclear referent.  But if this document is the source for these
>> normative requirements, it does seem that Informational is wrong.
>>
>> Given that this document actually defines bits to be used on the
>> wire, it may be appropriate to publish it as a PS.
>> Alternatively, BCP may be acceptable, although a bit unusual.
>>
>> The fact that this document defines the format of information fields
>> and includes the IANA registration for those fields to be used in
>> QOSM documents also suggests that informational is inappropriate as
>> it would create a conceptual dependence of all standards track QOSM
>> documents on an Informational RFC.  Also, this document includes
>> guidelines to follow in future IANA allocations.
>>
>>
>> Minor:
>> In describing the constraints parameters, the text in section 3.3.2
>> carefully describes the semantics, and the composition rule.
>> However, it seems to leave out the unit of measure. (The constraints
>> are given in the detailed message information formats section, but
>> 

Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)

[Simon Josefsson]

Russ Housley  writes:

> John-Luc:
>
> I am sending this note to help you understand the IETF IPR policies;
> they are fully described in BCP 79
> (http://www.ietf.org/rfc/bcp/bcp79.txt).  I hope this note clarifies
> the responsibilities of RIM employees (and anyone else) who
> participate in IETF.
>
> IETF participants engage as individuals, not as representatives of
> their employers (See Section B.1 of RFC 4677;
> http://www.ietf.org/rfc/rfc4677.txt).  The obligation to follow the
> IPR policies in BCP 79 is an individual one, not a corporate one.
> Section 6.1of BCP 79 is quite clear; IETF Participants are required to
> disclose IPR which they "reasonably and personally know" applies to a
> Contribution.  The BCP specifically excludes cases in which a
> participant is unaware of IPR held by their employer.

John-Luc said he is bound by confidentiality obligations from his
company, and I think the same applies to most employees of larger
organizations.  There is nothing explicit in BCP 79 to protect against
this apparent conflict of interest, or is there?

/Simon

> Please do not hesitate to contact me if you need further clarification.
>
> Russ Housley
> IETF Chair
>
>
> At 06:46 PM 11/19/2009, John-Luc Bakker wrote:
>>Dear all,
>>
>>With regard to the recent discussion regarding RIM's recent IPR
>>disclosures, I understand the community's concerns regarding the
>>timeliness of the disclosure.  As employees of companies we are bound by
>>confidentiality obligations and, in addition, cannot always control our
>>company's internal processes.  The community's concerns have been
>>brought to the attention of my employer and they are in the process of
>>evaluating the concerns.  My company has asked for your patience while
>>they take the time to evaluate the concerns and determine if there is an
>>appropriate course of action in this matter to alleviate the concerns of
>>the community.
>>
>>Your understanding is appreciated.
>>
>>Kind regards,
>>
>> John-Luc
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)

[Dave Cridland]

On Mon Nov 23 10:03:25 2009, Simon Josefsson wrote:

John-Luc said he is bound by confidentiality obligations from his
company, and I think the same applies to most employees of larger
organizations.  There is nothing explicit in BCP 79 to protect  
against

this apparent conflict of interest, or is there?


Being horribly naïve, I'd have thought that it was obvious that if  
you cannot satisfy both your obligations as an employee, and your  
obligations as an IETF participant, then one or other rôle has to be  
dropped - ie, either you quit your job, or cease to participate  
within the IETF. I simply don't see what other solution there is, or  
could be, and I don't see what on earth BCP 79 could usefully say.


So, as of now, it seems manifest that any RIM employees should not be  
participating within the IETF until they have resolved this conflict  
- indeed, I get the sense that this is RIM's decision, from the  
statements that RIM employees have made on this list.


As I say, though, I am horribly naïve in my understanding of the word  
"obligation", and I do appreciate that some organizations exist which  
might put pressure on employees to participate in willful disregard  
for the IPR rules. I also appreciate that those individuals affected  
- especially in these times - would then be placed in a very  
uncomfortable position - one I'm very glad not to be in.


The problem is, though, that an organization in such a position will  
end up eventually be seen to be in such a position, meaning that they  
are in the position of RIM as I outline above. That is, if the  
intention is to take commercial advantage of ignoring the IETF's  
rules for participants, then when such advantage is taken, it'll be  
obvious that the rules have indeed been ignored, and will threaten  
their ability to further participate.


There is an argument that RIM employees should be removed from all  
IETF mailing lists until such time as RIM publically states they  
shall henceforth follow IETF IPR rules, and order their employees to  
do the same. This has happened to individuals before, when they have  
clearly stated that they cannot follow the Note Well, and in this  
case the employees are clearly stating much the same. I'd like to  
think that this is not required - that, in effect, RIM have taken  
more or less this decision themselves - but I do look forward to  
RIM's explanation of how they intend to resolve the apparent conflict  
of obligations they have foisted upon their employees.


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: RIM patents using a mime body in a message (and ignores IETF IPR rules)

[Simon Josefsson]

Dave Cridland  writes:

> On Mon Nov 23 10:03:25 2009, Simon Josefsson wrote:
>> John-Luc said he is bound by confidentiality obligations from his
>> company, and I think the same applies to most employees of larger
>> organizations.  There is nothing explicit in BCP 79 to protect
>> against
>> this apparent conflict of interest, or is there?
>
> Being horribly naïve, I'd have thought that it was obvious that if you
> cannot satisfy both your obligations as an employee, and your
> obligations as an IETF participant, then one or other rôle has to be
> dropped - ie, either you quit your job, or cease to participate within
> the IETF. I simply don't see what other solution there is, or could
> be, and I don't see what on earth BCP 79 could usefully say.

The document could say just that, if that is indeed the general opinion.
It may be useful for employees to be able to point at such text when
discussing the IETF rules internally with their organization.

I'm not sure if that text would have helped in this instance because it
is not clear whether the RIM employees were unaware of the obligations
in the IETF rules, or if they decided (or were ordered) to pursue
anyway.  Referring to confidentiality obligations suggests the latter to
me, though, because otherwise you could simply have said you weren't
aware of the rules instead.

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

Re: silly legal boilerplate, was Regarding RIM's recent IPR disclosures

[Robert Elz]

Date:20 Nov 2009 05:36:18 -
From:John Levine 
Message-ID:  <20091120053618.8729.qm...@simone.iecc.com>

  | But I have often been sorely tempted to return messages like this with
  | boilerplate of my own explaining that since I cannot accept the
  | sender's alleged restrictions, the message has been returned unread,

That's the wrong response, it achieves nothing, the person who sent the
message usually cannot do anything about it.

A better response would be to send the stupid boilerplate (and only the
boilerplate, not the real message, or its headers) to the CEO (or corporate
lawyer, or similar) of the organisation that sent the message, along with text
something like...

I thank an employee of your organisation for the message sent
to me.  This note is to inform you that I do not accept, and
will not cooperate with your organisation's non disclosure
request (as shown herein).   If you did not intend the information
contained in the message to become available to the public, your
organisation should not have sent it to me.   While I respect your
copyright of the message itself, I will use the information I
learned from the message to my own advantage, and that of anyone
else I feel will be able to profit from its contents.   Once again,
thanks again for supplying me with this valuable information.

and nothing else.

kre

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

Re: I-D Action:draft-housley-iesg-rfc3932bis-12.txt

[Julian Reschke]

Julian Reschke wrote:


 
says:


   "Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org//rfc.html"

Can we please recommend *not* to put a file extension into the URL?

BR, Julian
...


Hi,

in the meantime I have finished a prototype implementation of the new 
boilerplate in rfc2629.xslt (*not* xml2rfc!). The implementation is 
available from , and 
requires the use of two new extension Processing Instructions to enable 
the new boilerplate:


  
  

(where the first enables the new format, while the second provides the 
information about whether there was consensus, something the current 
xml2rfc format doesn't provide).


I haven't found any problems in addition to what was reported before, 
except for a trailing dot in one of the boilerplate statements, and 
cases of repeating sentence beginnings -- maybe all of this can be fixed 
during AUTH48 (although I'd prefer to see this in a new draft for 
community review).


For the record, here's a complete summary:

-- snip --
3.1.  The title page header

 This describes the area where the work originates.
  Historically, all RFCs were labeled Network Working Group.
  "Network Working Group" refers to the original version of today's
  IETF when people from the original set of ARPANET sites and
  whomever else was interested -- the meetings were open -- got
  together to discuss, design and document proposed protocols
  [RFC0003].  Here, we obsolete the term "Network Working Group" in
  order to indicate the originating stream.

  The  is the name of the RFC stream, as defined in
  [RFC4844] and its successors.  At the time of this publication,
  the streams, and therefore the possible entries are:

  *  Internet Engineering Task Force

  *  Internet Architecture Board

  *  Internet Research Task Force

  *  Independent

JRE: as discussed earlier: should this be "Independent Submission"
instead of "Independent"?

   [:]  Some relations between RFCs in the
  series are explicitly noted in the RFC header.  For example, a new
  RFC may update one or more earlier RFCs.  Currently two
  relationships are defined: "Updates", and "Obsoletes" [RFC2223].
  Variants like "Obsoleted by" are also used (e.g in [RFC5143]).
  Other types of relationships may be defined by the RFC Editor and
  may appear in future RFCs.

JRE: "Obsoleted By" is not a variant of "Obsoletes" or "Updates".

3.2.2.  Paragraph 2

   The second paragraph of the "Status of This Memo" will now include a
   paragraph describing the type of review and exposure the document has
   received.  This is defined on a per-stream basis, subject to general
   review and oversight by the RFC Editor and IAB.  There is a specific
   structure defined here to ensure there is clarity about review
   processes and document types.  These paragraphs will need to be
   defined and maintained as part of RFC stream definitions.  Initial
   text, for current streams, is provided below.

   The paragraph may include some text that is specific to the initial
   document category, as follows: when a document is Experimental or
   Historic the second paragraph opens with:

   Experimental:  "This document defines an Experimental Protocol for
  the Internet community."

   Historic:  "This document defines a Historic Document for the
  Internet community."

JRE: the way paragraph 2 is generated, we end up with instances where
the 1st and 2nd sentence both start with "This document". This is ugly.
Is it too late to fix this?

  In addition a sentence indicating the consensus base within the
  IRTF may be added: "This RFC represents the consensus of the
   Research Group of the Internet Research Task Force
  (IRTF)." or alternatively "This RFC represents the individual
  opinion(s) of one or more members of the  Research
  Group of the Internet Research Task Force (IRTF)".

JRE: trailing dot missing in 2nd variant.


3.2.3.  Paragraph 3

   "Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org//rfc.html"

JRE: please do not bake a file extension into the permanent URL (see also
)

-- snip --

Best regards, Julian


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

Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)

[Scott Brim]

Simon Josefsson allegedly wrote on 11/23/2009 5:03 AM:
> John-Luc said he is bound by confidentiality obligations from his
> company, and I think the same applies to most employees of larger
> organizations.  There is nothing explicit in BCP 79 to protect against
> this apparent conflict of interest, or is there?

   Since disclosure is required
   for anyone submitting documents or participating in IETF discussions,
   a person who does not disclose IPR for this reason, or any other
   reason, must not contribute to or participate in IETF activities with
   respect to technologies that he or she reasonably and personally
   knows to be Covered by IPR which he or she will not disclose.

Also,

   If a Contributor first learns of IPR in its Contribution that meets
   the conditions of Section 6.6, for example a new patent application
   or the discovery of a relevant patent in a patent portfolio, after
   the Contribution is published in an Internet-Draft, a disclosure must
   be made as soon as reasonably possible after the IPR becomes
   reasonably and personally known to the Contributor.


___
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

[Dave Cridland]

On Mon Nov 23 00:17:45 2009, Lawrence Conroy wrote:
There have been a number of cases where things are not developed   
within the IETF

but are "out there".


Agreed.


Whether or not folk LIKE those schemes/the companies that  
promulgate  them/the author(s)

/the document style/the weather is not really important.


You make it sound like I have some trivial personal axe to grind - I  
do not, although I readily agree that I do not like the document  
style. (And I wasn't the only one to raise this comment about dns-sd,  
the sister document).


Having an Informational RFC to describe these protocols or file   
formats is useful.
If nothing else, it tells you what the heck is going on down the  
wire.


Right, this much I agree with. And if this was an isolated protocol,  
I would not be concerned with it at all - it is, as you imply, what  
Informational is *for* - well, modulo the marketing, anyway.


But there are, as I say, a number of standards-track protocols both  
in the IETF and other SDOs which depend on these two documents, just  
as was the case a year ago:


http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=44223&tid=1244548867

As it happens, the IETF documents haven't advanced - and I wonder if  
that's in part because mDNS and DNS-SD haven't been made  
standards-track.


I'm not arguing against the protocol's existence, and not against its  
documentation. I'm arguing that we should take the time to document  
it clearly, and ensure that it can be easily implemented in an  
interoperable manner from that documentation, and - potentially -  
make a handful of compatible changes where appropriate.


Burying it in a WG to try (and fail) to turn this into an IETF   
standards-track
document is not helpful. I fear that someone will go postal if we  
do  Zeroconf again.
There has been So much history that it is simply not worth   
repeating the pain.

(I seem to recall discussions on this starting out @IETF-41 in LA,
 since which time it's in very wide use "out there" :).


So you're primary argument against this not being made a standards  
track document is that it's an awful lot of work, and that it's bound  
to fail anyway.


Well, I can't deny that it *is* a substantial amount of work, but  
given that this protocol is, as you point out, deployed in the wild,  
I'm not really sure this is a problem, and arguing the IETF shouldn't  
put documents on the standards track, with a working group, because  
it's a lot of work and might fail to produce a useful result does -  
to me, anyway - sound my irony alarm full blast. Isn't this what the  
IETF is *for*?


So I reiterate - I see no reason not to charter a working group to  
revise this specification (and dns-sd), and I would welcome such a  
group being chartered such that it cannot make any incompatible  
changes to the protocol.


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: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC

[Arnt Gulbrandsen]

Dave Cridland writes:
So I reiterate - I see no reason not to charter a working group to  
revise this specification (and dns-sd), and I would welcome such a  
group being chartered such that it cannot make any incompatible  
changes to the protocol.


+1

Except that I'd put the compatibility requirement in terms of deployed 
code rather than the current draft. Mumble SRV RR mumble compression 
mumble. "The final RFC must be compatible with  version ,  
version  and  version , and if possible with other deployed 
implementations known to the WG" for some values of a-f.


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

Re: silly legal boilerplate, was Regarding RIM's recent IPR disclosures

[John R. Levine]

 | But I have often been sorely tempted to return messages like this with
 | boilerplate of my own explaining that since I cannot accept the
 | sender's alleged restrictions, the message has been returned unread,

That's the wrong response, it achieves nothing, the person who sent the
message usually cannot do anything about it.

A better response would be to send the stupid boilerplate (and only the
boilerplate, not the real message, or its headers) to the CEO (or corporate
lawyer, or similar)


You must know different CEOs and lawyers than I do.  The CEO's secretary 
will send it to the lawyer, and the lawyer will say "yes, that's what I 
told them to do", under the well-known principle that a lawyer will always 
recommend any measure, no matter how expensive, to defend against any 
risk, no matter how trivial.*


The only hope of change is if there's enough pushback that the staff 
reports it's making it hard for them to do their jobs.


R's,
John

* - For a good example, see the ever expanding RFC legal boilerplate.
___
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

[Peter Saint-Andre]

On 11/23/09 6:49 AM, Dave Cridland wrote:
> On Mon Nov 23 00:17:45 2009, Lawrence Conroy wrote:
> 
>> Having an Informational RFC to describe these protocols or file 
>> formats is useful.
>> If nothing else, it tells you what the heck is going on down the wire.
> 
> Right, this much I agree with. And if this was an isolated protocol, I
> would not be concerned with it at all - it is, as you imply, what
> Informational is *for* - well, modulo the marketing, anyway.
> 
> But there are, as I say, a number of standards-track protocols both in
> the IETF and other SDOs which depend on these two documents, just as was
> the case a year ago:
> 
> http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=44223&tid=1244548867
> 
> As it happens, the IETF documents haven't advanced - and I wonder if
> that's in part because mDNS and DNS-SD haven't been made standards-track.
> 
> I'm not arguing against the protocol's existence, and not against its
> documentation. I'm arguing that we should take the time to document it
> clearly, and ensure that it can be easily implemented in an
> interoperable manner from that documentation, and - potentially - make a
> handful of compatible changes where appropriate.
> 
>> Burying it in a WG to try (and fail) to turn this into an IETF 
>> standards-track
>> document is not helpful. I fear that someone will go postal if we do 
>> Zeroconf again.
>> There has been So much history that it is simply not worth 
>> repeating the pain.
>> (I seem to recall discussions on this starting out @IETF-41 in LA,
>>  since which time it's in very wide use "out there" :).
> 
> So you're primary argument against this not being made a standards track
> document is that it's an awful lot of work, and that it's bound to fail
> anyway.
> 
> Well, I can't deny that it *is* a substantial amount of work, but given
> that this protocol is, as you point out, deployed in the wild, I'm not
> really sure this is a problem, and arguing the IETF shouldn't put
> documents on the standards track, with a working group, because it's a
> lot of work and might fail to produce a useful result does - to me,
> anyway - sound my irony alarm full blast. Isn't this what the IETF is
> *for*?
> 
> So I reiterate - I see no reason not to charter a working group to
> revise this specification (and dns-sd), and I would welcome such a group
> being chartered such that it cannot make any incompatible changes to the
> protocol.

There are two separate actions that could be taken here:

a. Publish draft-cheshire-dnsext-multicastdns as an Informational RFC
(call it "mDNS 1.0" if that makes people happy).

b. Charter a WG to complete work on a standards-track protocol for the
same or similar functionality (call it "mDNS 1.1").

Are you in favor of a-and-b, or b-only?

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-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC

[Cullen Jennings]

Pretty much all the emails I have received on this have suggested we should 
just go publish it now. To be clear, I was not talking about forming a WG to go 
do a standards track version of this. I was talking about clicking one flag in 
the data tracker and changing it from information to standards track and 
publishing the draft  "as is" as standards track. 

The consensus seems to be: this document is important to get publish soon and 
is used by many other standards. Because of this, this draft is too important 
to publish it as standards track and we should publish it as informational 
instead. Anyways, I'm convinced that having this as a RFC is important and 
decided that I, like most other people, could care less if it was experimental 
or full standard as that will be close to irrelevant for what interoperability 
this enables on the internet. 

> 
> On 18 Nov 2009, at 15:41, Cullen Jennings wrote:
>> 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
> 

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

Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)

[Steven M. Bellovin]

On Mon, 23 Nov 2009 08:16:49 -0500
Scott Brim  wrote:

> Simon Josefsson allegedly wrote on 11/23/2009 5:03 AM:
> > John-Luc said he is bound by confidentiality obligations from his
> > company, and I think the same applies to most employees of larger
> > organizations.  There is nothing explicit in BCP 79 to protect
> > against this apparent conflict of interest, or is there?
> 
>Since disclosure is required
>for anyone submitting documents or participating in IETF
> discussions, a person who does not disclose IPR for this reason, or
> any other reason, must not contribute to or participate in IETF
> activities with respect to technologies that he or she reasonably and
> personally knows to be Covered by IPR which he or she will not
> disclose.
> 
Precisely.  The conflict Simon mentions was of course known to most of
the WG; that's one reason we have that clause.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: silly legal boilerplate, was Regarding RIM's recent IPR disclosures

[Robert Elz]

Date:23 Nov 2009 10:54:09 -0500
From:"John R. Levine" 
Message-ID:  

  | You must know different CEOs and lawyers than I do.  The CEO's secretary 
  | will send it to the lawyer, and the lawyer will say "yes, that's what I 
  | told them to do",

You mean, to give away corporate information to outsiders?  You know
laywers who recommend that - weird...   That's what my message said happened
- note there is no complaint at all about the boilerplate, that's pointless,
just a statement that I am not bound by it (there is no agreement between me
and them) , and that I intend to take full advantage of the information they
sent me - regardless of their admonitions that I must not.

I don't, and won't, tell them what the information was - that's (partly)
why the comment about "respecting copyright" was there - the author of the
message owns its copyright, even when they have sent it to you, you cannot
generally make copies without permission.   That means I cannot send them
their message back again, or not until they have proved to me that they are
the copyright owner of the message, which is probably not so easy to do when
they have no idea what the message was (or who sent it)

  |  under the well-known principle that a lawyer will always 
  | recommend any measure, no matter how expensive, to defend against any 
  | risk, no matter how trivial.*

Believe me, I fully understand both how that happens, and even why.

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

Re: RFC levels and I-D "levels"

[Alfred Hönes]

At Fri, 13 Nov 2009 13:42:32 +0200, Yaron Sheffer wrote:

> - Make the "tools" URL for an I-D into the mainstream way to access
>   I-Ds.  Specifically, include this URL in the I-D announcement mail.
>   This would have the benefit of pointing people to related RFCs and
>   to relevant IPR statements.

I had made a similar change proposal [1] in February for the IESG's
Last call announcements, but there has not been any positive echo
on this proposal -- besides a single voice from outside the IESG.

Kind regards,
  Alfred Hönes.


[1]
  http://www.IETF.ORG/mail-archive/web/ietf/current/msg55563.html

-- 

+++
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254  Ditzingen |  E-Mail:  a...@tr-sys.de |
+++

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

secdir review of draft-ietf-6man-overlap-fragment-03

[Carl Wallace]

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 RFC 2460 to forbid overlapping fragments.  I have
no issues with this draft.

 

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

Re: Gen-Art Review: draft-ietf-nsis-qspec-22.txt

[Gerald Ash]

Joel,
 
Thanks for the quick review.  I agree with all your comments and suggestions.
 
Regarding your suggestion on RFC type (change it from Informational to PS), I 
believe it could not become PS since the other NSIS documents (GIST & QoS-NSLP) 
are Experimental.
 
Thanks again,
Jerry

--- On Sat, 11/21/09, Joel M. Halpern  wrote:


From: Joel M. Halpern 
Subject: Gen-Art Review: draft-ietf-nsis-qspec-22.txt
To: "General Area Review Team" , "Mary Barnes" 

Cc: "Magnus Westerlun" , "IETF discussion list" 
, n...@ietf.org, draft-ietf-nsis-qs...@tools.ietf.org
Date: Saturday, November 21, 2009, 6:32 PM


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-nsis-qspec-22
    QoS NSLP QSPEC Template
Reviewer: Joel Halpern
Review Date: 21-Nov-2009
IETF LC End Date: 25-Nov-2009
IESG Telechat date: N/A

Summary: This document is almost ready for publication as an RFC.
I am concerned about the RFC type.  If a revision of the document is needed, 
there are a few minor items to consider for inclusion.

Major:
I am unclear about whether the intended status (Informational) for this 
document is correct.
At first, it seemed correct.   The document is defined as providing a template 
for a resource specification block (a QSPEC), and other model specific 
documents are expected to define exactly what QoS paramters they will use.
It even seemed fine that this document mandates that the QSPEC include the 
indication of the QoS Model.  That is necessary information.

Where I start to have concerns is in section 3.1 of this document. There, the 
document starts specifying requirements on any and of QoS Model documents.  It 
says things like "A QOSM specification MUST include the following:".  If this 
document is defining normative requirements for standards track documents (and 
the text explicitly states that QOSM definitions sometimes need to be standards 
track), then I don't see how it can be an informational document.
If the QOSM requirements, and the QSPEC support requirements ("The QSPEC 
objects ... MUST be supported by QNEs.") are actually copied from some other 
document, then the problem is a lesser issue of unclear referent.  But if this 
document is the source for these normative requirements, it does seem that 
Informational is wrong.

Given that this document actually defines bits to be used on the wire, it may 
be appropriate to publish it as a PS.
Alternatively, BCP may be acceptable, although a bit unusual.

The fact that this document defines the format of information fields and 
includes the IANA registration for those fields to be used in QOSM documents 
also suggests that informational is inappropriate as it would create a 
conceptual dependence of all standards track QOSM documents on an Informational 
RFC.  Also, this document includes guidelines to follow in future IANA 
allocations.


Minor:
In describing the constraints parameters, the text in section 3.3.2 carefully 
describes the semantics, and the composition rule.  However, it seems to leave 
out the unit of measure. (The constraints are given in the detailed message 
information formats section, but it would seem sensible to include them in 
3.3.2.)

Editorial:
Should there be an editorial note when "minimum QoS" is first described 
indicating that the term "minimum" is used generically, as for many parameters, 
like loss rate or latency, what needs to be specified is the maximum acceptable 
value?



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

Re: Gen-ART LC review of draft-klensin-ftp-registry-02

[Alfred Hönes]

Ben,
thanks for your GenART review.
Please see my responses inline.


Ben Campbell wrote:

> 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-klensin-ftp-registry-02
> Reviewer: Ben Campbell
> Review Date: 2009-11-20
> IETF LC End Date: 2009-11-23
> IESG Telechat date: (if known)
>
> Summary:
>
> This draft is very close to ready to publish as a proposed standard.
> I have one minor clarification question, and a few nits.
>
> Major issues:
>
> None.
>
> Minor issues:
>
> -- section 2.4:
>
> The section indicates that "base" FTP commands are not to be included
> in the registry. Is IANA expected to verify that any newly registered
> extensions do not conflict with base commands?

If that's indeed an issue, it might affect the legacy command names
in Section 2.5 as well.

However, the first paragraph of Section 2.3 already states:

| "This registry is primarily intended to avoid conflicting uses of the
|  same extension names and keywords for different purposes, not to
   demonstrate that an extension is somehow "approved".  [...]"

... restating that awareness of name conflicts was the primary
driving force for the document.  It would be entirely silly
(as far as we understand) for the author(s) of an FTP extension
to define 'new' command names conflicting with, and hence improperly
overlaying existing standard command names documented in RFCs.

In the case of item 1. in Section 2.3, the requested "peer review"
of the specification was assumed to guarantee that such sillyness
did not occur; in the case of item 2., actual implementation of the
new extension is required, which would be impossible in a manner
still conformant with STD 9, if a conflict were present.

We did not want to exclude the possibility to list already defined
command names in the registry again once a new extension adds new
functionality to an existing command, as already has happened for
the RFC 2228 commands AUTH, PBSZ, and PROT -- cf. Table 1.  Hence,
a simplistic formal uniqueness requirement for command opcodes does
not exist.

Thus, we reasonably expected that the applicants themselves take care
of conflict avoidance; this should not be a burden to IANA, which is
not expected to have the knowledge and resources to judge what is
"different purpose".

However, if it is deemed necessary, the text in Section 2.3 could be
slightly amended, e.g.:

  "This registry is primarily intended to avoid conflicting uses of the
   same extension names and keywords for different purposes, not to
   demonstrate that an extension is somehow "approved".  Applicants
   need to make sure that new command names do not conflict with the
   (current or legacy) standard opcodes listed in sections 2.4 and 2.5
   as well.  [...]"


> Nits/editorial comments:
>
> -- Section 2.2, "Extension name" section.
>
> The text states that this column is called "FEAT Code". Should the
> paragraph be entitled "FEAT Code" rather than "Extension name" ?

No.  We have created the term "FEAT Code" to also accommodate the
corner cases described in the text, as an umbrella term for actual
(primary) FEAT keywords and 'placeholder' keywords for pre-RFC 2389
cases.  New 'placeholder' keywords are not expected or deemed useful
in the future, only actual, primary FEAT keywords.
Thus using "FEAT Code" as a *replacement* for "Extension name"
in the template could be misinterpreted as allowing/suggesting
the registration of further 'placeholder' keywords, which we do
not want to happen.


> -- Section 3, last paragraph prior to table:
>
> s/marke/marked

Sure.  (Noticed by other parties as well.)

>
> -- IDNITS returns the following. In the case of the downref, I
> understand why it is there and do not object per se, but I wonder if
> it would not make more sense for that to be an informational reference.
> That is, it does not seem necessary to understand or implement the
> referenced document to understand or implement this one.
>
>   == Unused Reference: 'RFC2119' is defined on line 355, but no
>  explicit reference was found in the text

Mandatory-to-implement requirements have been demoted from normative
language to informal language (last paragraph above Table 1), and that
indeed now has made the reference to RFC 2119 unnecessary.  It will be
dropped, as already communicated in response to another review.

>
>   ** Downref: Normative reference to an Experimental RFC: RFC 2773
>
>   -- Obsolete informational reference (is this intentional?): RFC 1545
>  (Obsoleted by RFC 1639)

Yes, we wanted to document the history in Section 2.5.
RFC 1639, the successor of RFC 1545, is now Historical as well.
Similarly, RFC 775 was Experimental and arguably could also have
been declared as "Obsoleted by RFC 959" in the RFC index.

We leave i

Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before

[Phillip Hallam-Baker]

The problem is that there will inevitably be falloff in attendance on
the last day

The solution is obvious, extend the meeting to cover Saturday so that
is the last day but schedule no WG meetings for that day so that
everybody can miss the last day.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Logging the source port?

[Phillip Hallam-Baker]

I think these legal requirements are stupid.

But there is no way that I would regard adherence to Rob and Ari's
slapped together log format a defense against non-compliance. If you
have a legal obligation you have an obligation, end of story.

The W3C log format I designed is supported by all the Web servers I
use and allows for most data imaginable to be logged.


On Fri, Nov 13, 2009 at 4:49 AM, Arnt Gulbrandsen
 wrote:
> A really big NAT serving, say, eighteen million customers, can easily be so
> dense that if there's a bit of clock skew between a web server and the NAT
> operator, another customer might have used the same port at the time
> recorded by the web server.
>
> Therefore, I think it's safer to say that it's the NAT operator's
> responsibility to log enough. Umpteen million web sites will continue to use
> apache's common log format, so the NAT operator has to log what's needed to
> work with that format anyway.
>
> Arnt
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Gen-ART LC review of draft-dusseault-http-patch-15.txt

[Phillip Hallam-Baker]

I agree that a mechanism for atomicity would be nice.

I also agree that POST is in a sense a superset of PATCH.

So if I want a mechanism such as 2-phase commit I really would want it
for POST as well as PATCH, more so really. So I don't want to see the
issue addressed in PATCH if it is addressed at all. At most I want a
not in Lisa's draft to say 'hey we don't do this'.


For example, one can imagine a new HTTP header Transaction-ID and a
mechanism for querying the status of missed acknowledgements. This
would be available for PUT and POST, not just PATCH.

I don't think I would want a traditional 2-phase commit, I would
prefer something similar to sliding windows so that I can pipeline
requests and avoid the need for responses to be synchronous.


For example, the request might have the following header

Transaction-ID: we3292j239023i9i9== 42
Transaction-Rack: we3292j239023i9i9== 36


Where we3292j239023i9i9==  is a pseudo-unique transaction stream ID.
The transaction IDs advance by 1 each time. The client is specifying
that it has received notice (reacknowledgement) of all transaction IDs
it cares about up to number 36, the server can thus drop all state
associated with any transaction number 36 or less for that stream.

The response might have the following header:

Transaction-Ack: we3292j239023i9i9== 37-39 41

This is loosely NNTP format from memory. The server has completed
transactions 37, 38, 39 and 41. Transactions 40 and 42 are
outstanding.

What this approach does not do of course is to manage the status
return. A transaction can be closed but have failed.I am not really
sure you would want to bind that into HTTP protocol. But if you did it
would be with a new method (STATUS) that allows you to pull up the
response code for your previously declared transaction.



On Fri, Nov 13, 2009 at 11:13 PM, David Morris  wrote:
>
>
> On Fri, 13 Nov 2009, Roy T. Fielding wrote:
>
>>
>> Yes, and that is exactly what would happen even if HTTP supported
>> full two-phase commit, with all of its painful consequences, if the
>> response to commit was lost.  This is an application problem, not
>> a protocol requirement.  It can be "fixed" (to the degree that any
>> fix is possible in a distributed system) by providing the client
>> with a status resource within the same page as the SUBMIT, such
>> that the client can see the change in server state when it takes
>> place even if the specific 200 response is lost.  In other words,
>> provide the client with the information necessary to check the bill
>> before the final transaction is submitted.
>>
>
> It can also be checked on the server is a serial number is included
> in the POSTed data which can be used to determine if the original
> post was already processed.
>
> Dave Morris
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Logging the source port?

[Phillip Hallam-Baker]

If people are required to track the source port, it is hardly
unrealistic to expect them to abandon a file format that does not meet
their legal obligations. The technology required to address this issue
has only been around for 13 years.

If I was a part of a police investigation and a site operator had not
logged information that I thought they were obliged to log, I would be
putting them up on a charge irregardless of whether they considered it
the job of the NAT operator to do the work.

It is never safer to say that it is someone else's responsibility to
ensure that you meet your legal obligations.


Some parts of the Internet change very slowly, but others change
quickly. The parts that change quickly are those where the person who
has an interest in the change has the ability to make it.

On Mon, Nov 16, 2009 at 4:47 AM, Arnt Gulbrandsen
 wrote:
> Stephane Bortzmeyer writes:
>>
>> On Fri, Nov 13, 2009 at 10:49:36AM +0100,
>>  Arnt Gulbrandsen  wrote a message of 11  lines
>> which said:
>>
>>>  Therefore, I think it's safer to say that it's the NAT operator's
>>>  responsibility to log enough. Umpteen million web sites will  continue to
>>> use apache's common log format, so the NAT operator has  to log what's
>>> needed to work with that format anyway.
>>
>> How could it be possible? The only way I see for the NAT operator to
>> be able to say that the customer X went to www.priv.no at 2241 UTC is
>> to log not only the source-address/source-port mapping but also the
>> *destinations*, which create obvious privacy issues (and would make the
>> log *much* larger).
>
> Yes. But do you see a way to avoid that, except by unrealistic declarations
> such as "all apache installations that use the common log format must be
> changed"? It's not just apache either, all other (web and other) servers
> that don't log source port.
>
> (Btw, there is no www.priv.no, and these days I don't think you can get
> anything else under .priv.no either. The dozen-odd people who have .priv.no
> domains are allowed to keep them, that's all.)
>
> Arnt
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Gen-ART LC review of draft-dusseault-http-patch-15.txt

[Phillip Hallam-Baker]

I agree with John on this one.

We do not need to provide the mechanism, we do need to provide the warning.


On Mon, Nov 16, 2009 at 10:24 AM, John C Klensin  wrote:
>
>
> --On Sunday, November 15, 2009 14:54 -0800 "Roy T. Fielding"
>  wrote:
>
>> On Nov 15, 2009, at 12:03 PM, John C Klensin wrote:
>>...
>>> We should not be adopting a "patch" protocol that lacks both
>>> the tools for, or a serious discussion of, transactional
>>> integrity.
>>
>> John, HTTP is not SQL.  The transactional integrity is inside
>> the resource implementation.  The entire transaction consists
>> of a single request message and a single response message.
>> HTTP is responsible for the communication interface, not the
>> implementation of specific resources, and cannot proscribe a
>> specific transaction semantic because it is NOT WANTED by
>> many resources.
>
> Roy, I certainly agree with the first part of this.  HTTP is not
> SQL.  If it were, I (at least) would be loudly insisting on an
> integrity mechanism.  However, normal IETF practice includes
> being explicit about issues and traps with specifications.  So,
> while it is plausible to take the position you express above,
> that just about requires that the specification explicitly
> indicate that verifying transactional integrity is the
> responsibility of the calling application.  I'm also suggesting
> that it should at least point to ways to do that.   The
> paragraph in Security Considerations (Section 5) that reads:
>
>        "A document that is patched might be more likely to be
>        corrupted than a document that is overridden in
>        entirety, but that concern can be addressed through the
>        use of mechanisms such as conditional requests using
>        ETags and the If-Match request header."
>
> is not, IMO, adequate in that regard, at least absent a
> normative reference.  It is also the key to the issue as I see
> it: while POST can be used to simulate PATCH, the normal and
> obvious use of POST is to supply some information to the server
> or to replace ("override") an entire document, PATCH would seem
> to have, well, patching as its primary purpose.
>
>> For example, a collaborative whiteboard in which many people
>> are patching at once, the patches consisting of context diffs
>> that are internally capable of distinguishing conflicts, would
>> be impossible to implement via standard etag behavior.
>
> Sure.  So say that in the document.   My problem is _not_ with
> the mechanism, it is with what you apparently assume people will
> figure out for themselves or learn through oral tradition.
>
>> Standard etag conflict resolution is not required because
>> it is not desirable for many applications of PATCH.  For
>> other applications of PATCH, it is already defined by HTTP
>> and does not need to be reiterated here.
>
> We disagree.  I believe it does "need to be reiterated here",
> either in-line or by an explicit, normative, pointer to the
> relevant portion of the HTTP spec.
>
>    john
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)

[Phillip Hallam-Baker]

I don't see the issue as being whether the decision would have been
different, the rules were not followed. Rescinding the decision is
certainly appropriate.

It would be useful to know whether any other parties have implemented
this spec to date. If so the situation is rather different since the
other parties would be affected in two ways, first by the withdrawal
of the registration itself but secondly as it may affect defenses
against a RIM infringement claim under the Dell decision.

We should remember that the intention of the rules was to make them
self-policing by attempting to engage legal sanctions in the case of
default. If a company does not make timely disclosure of its IPR it
risks having damaged it.



On Wed, Nov 18, 2009 at 9:13 PM, Brian E Carpenter
 wrote:
> 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
>



-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)

[Phillip Hallam-Baker]

This was the case in the past. Recently one of my lawyers suggested
that this is not necessarily the case at present. The USPTO appears to
be (slowly) getting its act together.

While USPTO behavior has been rent-seeking in recent years, preferring
to issue stupid patents rather than risk being sued by the applicant,
the frequency of re-examination requests during court proceedings has
increased substantially and is providing more of a counterbalancing
interest.

In this case there are only applications, not actual patent claims.
The applicant is obliged to provide any information received that
might affect the validity of the patent to the USPTO. Failure to do so
can lead to the patent being invalidated. So it is not a question of a
re-exam.

As always, IANAL and this is not legal advice.

On Thu, Nov 19, 2009 at 3:32 PM,   wrote:
> On Thu, Nov 19, 2009 at 10:51:16AM -0800, Stephan Wenger wrote:
>> The mechanisms to challenge the validity of a patent depend on the
>> legislation.  In the US, one example is a request for re-examination.  A
>> good foundation for such a request would be the presence of Prior Art not
>> considered during the prosecution phase.  The effort and cost involved is
>> significant and can be compared to the prosecution of a patent.  One problem
>> with re-examination is that one has to show that the patent office was wrong
>> in issuing the patent originally.  That is, one does not only fight the
>> interests of the rightholder, but also the established opinion of the patent
>> office.  No one likes to be proven wrong, and, therefore, re-examination is
>> often an uphill battle against an established bureaucracy.
>
> Worse yet, if you don't have all of your expensive patent lawyers
> lined up, and the patent office decides it doesn't want to admit that
> it screwed up, the patent actually ends up being *stronger* afterwards
> --- that is, a patent which survives a re-exam is presumed by the
> courts to be more likely valid.
>
> This brings up an interesting strategy by patent trolls to secretly
> get a sock-puppet to deliberately launch a incompentent patent
> re-examine, just to make the patent appear stronger.  As a result,
> some patent attorneys, upon examination of the unique facts of a
> particular patent, might decide that it's better to not try to
> challenge the patent, and wait for the troll to make the first strike.
>
> It's amazing how screwed up the US Patent system is, isn't it?
>
>                                                 - Ted
>
> P.S. This is not legal advice, and I don't play a lawyer on TV.
>
> P.P.S.  The opinions expressed in this e-mail are my own, and do not
> reflect the views or business strategies of my employer.
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/
___
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

[Martin J. Dürst]

Hello Cullen,

I have started reading draft-cheshire-dnsext-multicastdns for an Apps 
Area review. I also started asking myself the question of "standards 
track vs. informational". However, this was not in the general sense, 
but in regards to some very specific issues. In the general sense, I was 
assuming that this was Informational because it documented an existing 
practice and deployment by an existing company.


Where I wasn't at all sure about whether Informational was appropriate 
was things such as reserving the top-level domain name ".local" with 
ICANN (Section 3). Of course the IETF has the rigth to do this, but 
shouldn't this be done in a standards track or BCP document?


Regards,Martin.

On 2009/11/19 0:41, Cullen Jennings wrote:


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



--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:due...@it.aoyama.ac.jp
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf