RE: SECDIR review: draft-hammer-hostmeta

[Eran Hammer-Lahav]

Thanks for the review.

I will add these points to the security consideration section, but will keep it 
as a host level document, not service level. This well-known document is 
appropriate when looking for host metadata, and application choosing to use it, 
must consider the implications. By itself, host-meta means very little. 
Applications need to "buy-into" the document (and spell out how to use it) in 
order for it to have meaning. When doing so, they must consider its 
implications.

EHL

> -Original Message-
> From: Kurt Zeilenga [mailto:kurt.zeile...@isode.com]
> Sent: Friday, July 16, 2010 7:18 AM
> To: IETF
> Cc: draft-hammer-hostm...@tools.ietf.org; Security Area Directorate; IESG
> IESG
> Subject: SECDIR review: draft-hammer-hostmeta
> 
> 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 should treat these comments just like any other
> last call comments.
> 
> I have a number of security-related concerns with this specification.
> 
> First, I'm concerned by assumptions in the document that each of:
>   http://example.com
>   http://example.com:8080
>   https://example.com
>   https://example.com:8443
> 
> identify resources under the control of same entity.   It is fairly common to
> there to be multiple http/https services running on a single host, each 
> service
> possibly operated by different entities as delegated by the "host"
> administrator.  I think it would be better (from a security perspective) to
> have "service"-level metadata, not "host" level meta data.  That is, make no
> assumption that the above URIs are under control of the same entity, or
> even if so, that it desirable to a single policy/metadata covering multiple
> services.
> 
> And I think it very important to always fetch the meta data from the service
> one is accessing.  The document calls for client to fetch
> https://example.com/.well-known/host-meta even when
> https://example.com:8443 is URI wants policy for.
> 
> Even worse, the document calls for the client to, if the above fetch does not
> produce a "valid" hostmeta document, for the client to fetch
> http://example.com/.well-known/host-meta.  An attacker could easily cause
> https://example.com/.well-known/host-meta to fail to produce a "valid"
> hostmeta document, and serve its own hostmeta document in response to
> the client's http://example.com/.well-known/host-meta, without
> supplanting the https://example.com:8443 service.
> 
> The document fails to discuss such attacks.
> 
> I recommend reworking this document to provide service-level, not host-
> level, metadata.  In particular, the metadata document should always be
> retrieved through the service the client is interested in using, such as by
> fetching "/.well-known/metadata".
> 
> If the authors rather continue pursuing a "host-based" solution, the security
> considerations should include a discussion of the above issues.
> 
> Regards, Kurt
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Second Last Call: (Web Host Metadata) to Proposed Standard -- feedback

[Eran Hammer-Lahav]

Hannes,

None of the current OAuth WG document address discovery in any way, so clearly 
there will be no use of XRD. But the OAuth community predating the IETF had 
multiple proposals for it. In addition, multiple times on the IETF OAuth WG 
list, people have suggested using host-meta and XRD for discovery purposes.

The idea that XRD was reused without merit is both misleading and 
mean-spirited. Personally, I'm sick of it, especially coming from standards 
professionals.

XRD was largely developed by the same people who worked on host-meta. XRD 
predated host-meta and was designed to cover the wider use case. Host-meta was 
an important use case when developing XRD in its final few months. It was done 
in OASIS out of respect to proper standards process in which the body that 
originated a work (XRDS) gets to keep it.

I challenge anyone to find any faults with the IPR policy or process used to 
develop host-meta in OASIS.

XRD is one of the simplest XML formats I have seen. I bet most of the people 
bashing it now have never bothered to read it. At least some of these people 
have been personally invited by me to comment on XRD while it was still in 
development and chose to dismiss it.

XRD was designed in a very open process with plenty of community feedback and 
it was significantly simplified based on that feedback. In addition, host-meta 
further simplifies it by profiling it down, removing some of the more complex 
elements like Subject and Alias (which are very useful in other contexts). XRD 
is nothing more than a cleaner version of HTML  elements with literally a 
handful of new elements based on well defined and widely supported 
requirements. It's entire semantic meaning is based on the IETF Link relation 
registry RFC.

There is something very disturbing going on these days in how people treat 
XML-based formats, especially form OASIS.

When host-meta's predecessor - side–meta – was originally proposed a few years 
ago, Mark Nottingham proposed an XML format not that different from XRD. There 
is nothing wrong with JSON taking over as a simpler alternative. I personally 
prefer JSON much better. But it would be reckless and counter productive to 
ignore a decade of work on XML formats just because it is no longer cool. Feels 
like we back in high school.

If you have technical arguments against host-meta, please share. But if your 
objections are based on changing trends, dislike of XML or anything OASIS, grow 
up.

EHL



From: Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>>
Date: Sun, 3 Jul 2011 00:36:29 -0700
To: Mark Nottingham mailto:m...@mnot.net>>
Cc: Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>>, 
"ietf@ietf.org<mailto:ietf@ietf.org> IETF" 
mailto:ietf@ietf.org>>, Eran Hammer-lahav 
mailto:e...@hueniverse.com>>, oauth WG 
mailto:oa...@ietf.org>>
Subject: Re: Second Last Call:  (Web Host 
Metadata) to Proposed Standard -- feedback

I also never really understood why XRD was re-used.

Btw, XRD is not used by any of the current OAuth WG documents, see 
http://datatracker.ietf.org/wg/oauth/


On Jun 22, 2011, at 8:08 AM, Mark Nottingham wrote:

* XRD -- XRD is an OASIS spec that's used by OpenID and OAuth. Maybe I'm just 
scarred by WS-*, but it seems very over-engineered for what it does. I 
understand that the communities had reasons for using it to leverage an 
existing user base for their specific user cases, but I don't see any reason to 
generalise such a beast into a generic mechanism.


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

RE: [IAOC] Request for community guidance on issue concerning a future meeting of the IETF

[Eran Hammer-Lahav]

If by engage you mean continue to discuss the terms of having a meeting in 
China, then I agree. If the government there really wants to host an IETF 
meeting, they should be able to help changes these terms to focus on 
individuals and not the entire event or organization.

But to suggest that without holding a meeting in China the IETF does not engage 
its Chinese members, that is simply false.

Personally, I doubt I will be attending a meeting in China. Not because of any 
political reasons, but simply because the cost of such a meeting compared to 
the value it brings my employer (that is attending a meeting, not general IETF 
participation).

My concerns are having access to the meeting via IRC and voice streams and not 
having to worry about where the meeting it taking place. I think bad behavior 
is more likely from people participating from outside China than at the event. 
And if all it takes to shut down such channels is someone saying something 
about Tibet on the IRC channel, then that's simply not acceptable.

EHL



> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
> Marshall Eubanks
> Sent: Saturday, September 19, 2009 3:17 PM
> To: Steve Crocker
> Cc: IAOC IAOC; IETF Discussion
> Subject: Re: [IAOC] Request for community guidance on issue concerning
> a future meeting of the IETF
> 
> Speaking just for myself, I agree with Steve. I think it that is
> better to engage than to retreat. Nothing is certain, but I also think
> that it is highly likely that we would have a good meeting.
> 
> Regards
> Marshall
> 
> 
> On Sep 19, 2009, at 3:55 PM, Steve Crocker wrote:
> 
> > The choice is between engaging and not engaging.  Engaging is
> > better.  Not engaging isn't constructive.  The Internet and the IETF
> > are all about engaging, expanding, communicating and being open.
> > Much of this dialog has been worried about possible extreme
> > situations.  Let's focus on the center.  More than a billion people
> > live in China and their use of the Internet is expanding rapidly.
> > They are building much of the technology and contributing
> > technically.  It's to everyone's advantage to have comfortable,
> > constructive interaction.  Our first slogan was "Networks Bring
> > People Together."
> >
> > If you prefer to focus on the negatives, here's my analysis:
> >
> > If we don't go to China, we have charted a downhill course and the
> > rest of the world will come together without us.  The IETF will lose
> > relevance.
> >
> > If we do go to China and something bad happens, the consequences
> > will be much worse for China than for the IETF.  The work of the
> > IETF will suffer a bit, but we'll recover quickly enough.  However,
> > China's quest for engagement with the rest of the world will be hurt
> > more seriously.
> >
> > Bottom line: We should go to China with a positive attitude.  We're
> > robust enough to deal with any consequences.  If we don't go to
> > China, however, we have weakened ourselves.
> >
> > Steve
> >
> > ___
> > IAOC mailing list
> > i...@ietf.org
> > https://www.ietf.org/mailman/listinfo/iaoc
> >
> 
> ___
> 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: Last Call: draft-hammer-oauth (The OAuth Core 1.0 Protocol) to Informational RFC

[Eran Hammer-Lahav]

This draft is the original community specification created outside the IETF. It 
was this work that inspired the creation of the OAUTH WG and is explicitly set 
as the initial draft for the WG in its charter. The draft is submitted as an 
informational RFC to document existing deployment and practices. It is not a WG 
product.

EHL

> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
> Cullen Jennings
> Sent: Tuesday, October 27, 2009 7:12 AM
> To: IESG IESG
> Cc: IETF Discussion
> Subject: Re: Last Call: draft-hammer-oauth (The OAuth Core 1.0
> Protocol) to Informational RFC
> 
> 
> I'm very confused about the relationship of this draft and the work
> the OAUTH WG is doing. Can you explain?
> 
> 
> On Oct 9, 2009, at 15:38 , The IESG wrote:
> 
> > The IESG has received a request from an individual submitter to
> > consider
> > the following document:
> >
> > - 'The OAuth Core 1.0 Protocol '
> >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-11-06. 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-hammer-oauth-03.txt
> >
> >
> > IESG discussion can be tracked via
> >
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag
> =17736&rfc_flag=0
> >
> > ___
> > IETF-Announce mailing list
> > ietf-annou...@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf-announce
> 
> ___
> 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: Regarding RIM's recent IPR disclosures

[Eran Hammer-Lahav]

Is every single RIM employee going to send this to the list?

EHL

From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Andrew 
Allen
Sent: Thursday, November 19, 2009 6:11 PM
To: ietf@ietf.org
Subject: Regarding RIM's recent IPR disclosures


With regard to the recent discussion on the IETF-Discussion list regarding 
RIM's recent IPR disclosures, I understand the community's concerns regarding 
the timeliness of the disclosure.  As I'm sure everyone can understand, 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

Best regards

Andrew Allen

Manager Standards

Research In Motion Ltd

Office +1 847-793-0861 x20824

BlackBerry Mobile +1 847 809 8636

http://www.rim.com/

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC

[Eran Hammer-Lahav]

I am supportive of updating *a* registry.

The OAuth working group has an open requirement for standard identifiers to 
describe hash/digest functions.

What is not clear to me is the relationship of this registry and:

http://www.iana.org/assignments/hash-function-text-names/

which seems to overlap.

I am not sure why we need both, and if we do (because they are protocol 
specific and required for interoperability), how should a new specification 
decide which to use or if a new registry is required. For example my uneducated 
reading of 4572 suggests it is not exactly the same use case as the previous 
RFCs using that registry.

In addition, using different tokens for the same algorithm across protocols 
seems like a bad idea (lower case, upper case, SHA vs sha-1).

And since both include MD5... arguments about appropriate hash algorithm to 
increase security fail.

EHL


> -Original Message-
> From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-
> boun...@ietf.org] On Behalf Of The IESG
> Sent: Friday, December 04, 2009 6:44 AM
> To: IETF-Announce
> Subject: Last Call: draft-bryan-http-digest-algorithm-values-update
> (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC
> 
> The IESG has received a request from an individual submitter to consider the
> following document:
> 
> - 'Additional Hash Algorithms for HTTP Instance Digests '
> 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 2010-01-01. 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-bryan-http-digest-algorithm-
> values-update-03.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
> 19094&rfc_flag=0
> 
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC

[Eran Hammer-Lahav]

This raises the obvious question - shouldn't we take greater action than simply 
update one of them? Should we consider combining them? Perhaps update the 
reason why we have them and make them more useful for other use cases?

I am just looking for clarifications.

EHL


> -Original Message-
> From: Anthony Bryan [mailto:anthonybr...@gmail.com]
> Sent: Friday, December 04, 2009 5:21 PM
> To: Eran Hammer-Lahav
> Cc: ietf@ietf.org; HTTP Working Group (ietf-http...@w3.org)
> Subject: Re: Last Call: draft-bryan-http-digest-algorithm-values-update
> (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC
> 
> Eran, to my knowledge there is no relationship between the two registries,
> besides some overlap. The registry you mention appears to be just hash
> function names and references a few X.509 RFCs.  I don't know about the
> history but it seems to be a more generic list. (We reference that registry in
> draft-bryan-metalink).
> 
> Here is the registry draft-bryan-http-digest-algorithm-values-update
> would update:
> Hypertext Transfer Protocol (HTTP) Digest Algorithm Values
> http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml
> 
> RFC 3230, which created this registry, doesn't refer to it by name, which 
> isn't
> too helpful in finding it. The algorithms haven't been updated, so the newest
> entry is SHA, and some other references were inconsistent (different base64
> RFCs) and outdated (SHA), which this draft fixes. It also includes values 
> which
> are not in the other
> registry: UNIXsum, UNIXcksum. "All digest-algorithm values are case-
> insensitive."
> (We also reference this registry in draft-bryan-metalinkhttp).
> 
> I agree, SHA vs sha-1 in the registries could be confusing but both these
> registries have co-existed for 7 years. I don't know how much either has
> been used in practice, besides our 2 drafts.
> 
> On Fri, Dec 4, 2009 at 12:42 PM, Eran Hammer-Lahav
>  wrote:
> > I am supportive of updating *a* registry.
> >
> > The OAuth working group has an open requirement for standard identifiers
> to describe hash/digest functions.
> >
> > What is not clear to me is the relationship of this registry and:
> >
> > http://www.iana.org/assignments/hash-function-text-names/
> >
> > which seems to overlap.
> >
> > I am not sure why we need both, and if we do (because they are protocol
> specific and required for interoperability), how should a new specification
> decide which to use or if a new registry is required. For example my
> uneducated reading of 4572 suggests it is not exactly the same use case as
> the previous RFCs using that registry.
> >
> > In addition, using different tokens for the same algorithm across protocols
> seems like a bad idea (lower case, upper case, SHA vs sha-1).
> >
> > And since both include MD5... arguments about appropriate hash algorithm
> to increase security fail.
> >
> > EHL
> >
> >
> >> -Original Message-
> >> From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-
> >> boun...@ietf.org] On Behalf Of The IESG
> >> Sent: Friday, December 04, 2009 6:44 AM
> >> To: IETF-Announce
> >> Subject: Last Call: draft-bryan-http-digest-algorithm-values-update
> >> (Additional Hash Algorithms for HTTP Instance Digests) to
> >> Informational RFC
> >>
> >> The IESG has received a request from an individual submitter to
> >> consider the following document:
> >>
> >> - 'Additional Hash Algorithms for HTTP Instance Digests '
> >>     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 2010-01-01. 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-bryan-http-digest-algorithm
> >> -
> >> values-update-03.txt
> >>
> >>
> >> IESG discussion can be tracked via
> >> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dT
> >> ag=
> >> 19094&rfc_flag=0
> >>
> >> ___
> >> IETF-Announce mailing list
> >> ietf-annou...@ietf.org
> >> https://www.ietf.org/mailman/listinfo/ietf-announce
> >
> 
> 
> 
> --
> (( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
>   )) Easier, More Reliable, Self Healing Downloads
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Motivation to submit an idea in IETF?

[Eran Hammer-Lahav]

The IETF, like any other standard body, isn't about publishing idea or 
inventing things, but all about enabling interoperability between discrete 
implementations and parties. Patents do not enable interoperability on their 
own because of their nature and limitations (at least in the US). However, 
patents are often involved when engineering interop solutions.

The questions you have to ask yourself are: Are you looking to create a new 
market? Is this market more likely to succeed if it is open for all and free to 
participate or fee-based? Are you going to make a greater profit in an open 
(bigger) market or in a closed (usually smaller) market?

EHL


On 1/21/10 4:57 PM, "Abhishek Verma"  wrote:

Hi,

I have a basic question relating to patents and IETF.

Assume that i have a nifty idea on how i can speed up, lets say, a
database exchange in OSPF. My doubt is that why should i submit an
IETF draft describing this, which can later become an RFC, when i can
very well patent this idea? I understand that if i submit this to
IETF, then there will be an RFC and all vendors will come out with
inter-operable implementations. However, if i dont give it to IETF and
rather submit a patent, i can do very well for the vendor that i work
for. All customers using this vendor's boxes will now have access to
patented database exchange in OSPF, which will effectively mean more
business for this vendor.

So, the question is, what is the motivation for somebody to write an
internet-draft when the person can file a patent?

I spoke to several people offline and i couldnt get any good answers.
The typical response was that most ISPs prefer multiple vendors, and a
patented solution will cause issues as the other vendor will not have
that support. Is this the only  reason?

Thanks,
Abhishek
___
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: Internet Society joins Liberty Alliance Management Board: Why?

[Eran Hammer-Lahav]

My concern regarding this announcement is the fact that it gives support to a 
misguided effort by Liberty Alliance. I think it is somewhat irresponsible for 
the ISOC to actively support an effort without first engaging the community at 
large to fully understand the dynamics of the identity communities involved.

The people behind the IDtbd effort have been going around trying to sell this 
effort for a while. The reality is that at this point, the communities behind 
two of the most successful identity related protocols, OAuth and OpenID, have 
rejected this effort by Liberty, including many of the individual companies 
that support these communities.

I find it personally offensive that Liberty have been going behind the OAuth's 
community's back trying get corporations to move their OAuth and OpenID efforts 
to IDtbd instead of the communities that drive these efforts forward.

IDtbd is an effort to create a full-blown standard body to manage all identity 
related protocols, with its own set of IPR rules, process, and governance. They 
seek to nullify existing communities by positioning themselves as the authority 
in the space. Supporting this effort directly contradicts the current IETF 
effort to form an OAuth working group.

EHL



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

Re: Consensus Call for draft-housley-tls-authz

[Eran Hammer-Lahav]

When you say IETF RFC, do you also include RFC-Editor track informational RFCs?

EHL


On 3/10/09 3:08 PM, "Lawrence Rosen"  wrote:

Phillip Hallam-Baker wrote:
> Institute the policy as you suggest and you have just given the patent
> trolls the power to place an indefinite hold on any IETF proposal.

I have never suggested placing any kind of hold on any IETF proposal.
Propose all you want. Publish the proposal. Try to convince people that it
is a good proposal. Establish a WG to design away

An IPR Disclosure has been filed in accordance with standard IETF procedure.


What I've suggested is due diligence to determine the implications of that
disclosure. Only THEN is publication as an IETF RFC justified. Experimental
or not, industry standard or not, an IETF RFC encourages companies to
implement and use the technology, and that may be patent infringement.

Or it may be a bogus IPR disclosure that intelligent people could decide to
ignore.

I am certainly not giving patent trolls any more power than they deserve. In
fact, I hope to dispose of this particular TLS patent troll once we get a
small group of patent attorneys to analyze the IPR disclosure like
professionals do it.

Just like W3C does it. They don't give patent trolls power either.

/Larry



> -Original Message-
> From: Hallam-Baker, Phillip [mailto:pba...@verisign.com]
> Sent: Tuesday, March 10, 2009 1:24 PM
> To: lro...@rosenlaw.com; Paul Hoffman; ietf@ietf.org
> Subject: RE: Consensus Call for draft-housley-tls-authz
>
> Institute the policy as you suggest and you have just given the patent
> trolls the power to place an indefinite hold on any IETF proposal.
>
> So instead of extorting payment for exercise of the claims they hold the
> standard hostage.
>
>
> > -Original Message-
> > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On
> > Behalf Of Lawrence Rosen
> > Sent: Tuesday, March 10, 2009 3:28 PM
> > To: 'Paul Hoffman'; ietf@ietf.org
> > Subject: RE: Consensus Call for draft-housley-tls-authz
> >
> > Lawrence Rosen wrote:
> > > >If we use different terminology to identify this IETF RFC,
> > how does
> > > >that
> > > change anything?
> >
> > Paul Hoffman replied:
> > > Because you earlier complained about IETF standards having known
> > > patent issues. Now we are talking about experimental protocols that
> > > are not standards.
> >
> > And I am saying that it doesn't make a bit of difference
> > legally. If you infringe for experimental reasons, that is
> > still infringement.
> >
> > I don't think we should publish under the IETF imprimatur if there are
> > *unresolved* known patent issues about which ignorant and
> > cautious people continue to speculate blindly. Why should any
> > of us waste time and money on IETF and commercial and FOSS
> > "experiments" if they may cost us too much money downstream?
> >
> > Its authors are free to publish draft-housley-tls-authz
> > already. Google is free to index that document already. Why
> > do you insist upon granting it an IETF RFC status without
> > first deciding if the disclosed patent claims are likely bogus?
> >
> > /Larry
> >
> >
> > > -Original Message-
> > > From: Paul Hoffman [mailto:paul.hoff...@vpnc.org]
> > > Sent: Tuesday, March 10, 2009 10:31 AM
> > > To: lro...@rosenlaw.com; ietf@ietf.org
> > > Subject: RE: Consensus Call for draft-housley-tls-authz
> > >
> > > At 10:22 AM -0700 3/10/09, Lawrence Rosen wrote:
> > > >If we use different terminology to identify this IETF RFC,
> > how does
> > > >that
> > > change anything?
> > >
> > > Because you earlier complained about IETF standards having known
> > > patent issues. Now we are talking about experimental protocols that
> > > are not standards.
> > >
> > > --Paul Hoffman, Director
> > > --VPN Consortium
> >
> > ___
> > 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

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

Re: Does being an RFC mean anything?

[Eran Hammer-Lahav]

If someone fails to read the front page of an RFC which clearly states what 
that document is and is not, that is their problem. There is no excuse for 
stupidity or laziness.

There is a real problem with people thinking that RFC == Free License. We need 
to educate people and maybe consider new ways to get that message out. But it 
has nothing to do with the status of the document. The purpose of RFCs is in 
the *name*: Request For Comments. How much more clear can you get? It is a memo 
publication channel for documents related to internet technologies. It is a way 
for people to communicate ideas and preserve them. Standards are just a small 
part of it.

There is no connection between the document status (standard, info, 
experimental, etc.) to its IPR status. Yes, most standards tend to be free, but 
that is still a document by document distinction. And to argue that it is 
different elsewhere is wrong. For example, OASIS has plenty of standards that 
are not free. I am willing to bet that there are more fee-based licensed 
standards in the world than free ones. You have to understand the wide range of 
topics discussed in the IETF and the fact that a lot of it might be of no 
consequences to open source developers. It is not the job of the IETF to fight 
against the patent system. What we need to make sure is that the communities 
creating standards ensure that their expected audience can implement it.

If you don't understand how something works, saying its broken is the lazy way 
out. Should we do a better job educating people about the IPR consequences of 
using RFCs? Of course! Should we make it harder for encumbered tech to make it 
into standards? Hell yeah! But we need to solve the problem where it belongs.

As for TSG's comments: show me an organization this size that doesn't have 
people who worry more about their ass than the community they are in. You 
comment makes as much sense as saying that you would not vote for president 
because politics is dirty and all about self promotion. Grow up.

EHL






On 3/11/09 3:54 PM, "TSG"  wrote:

Lawrence Rosen wrote:

Because Larry - many of those here owe their ongoing $$$ livelihood to
the lie the IETF has become. And so what you are suggesting is
increasing the rolls of the unemployed by adding these individuals who's
whole existence is the IETF. Its also these people in my opinion that
make the IETF the laughingstock its become as you so rights notice that
RFC's and the process for creating standards has degraded into a model
where there really is no standard.

Just my two cents

Todd Glassey
>
> The recent threads about draft-housley-tls-authz have taught me
> something I didn't know about IETF, and I don't like what I've learned.
>
> There are, it appears, many types of IETF RFCs, some which are
> intended to be called "Internet standards" and others which bear other
> embedded labels and descriptions in their boilerplate text that are
> merely "experimental" or "informational" or perhaps simply "proposed
> standard". One contributor here described the RFC series as "a
> repository of technical information [that] will be around when I am no
> longer around."
>
> The world is now full of standards organizations that treat their
> works as more significant than merely "technical information." Why do
> we need IETF for that purpose? If all we need is a repository of
> technical information, let's just ask Google and Yahoo to build it for
> us. Maybe our Internet standards should instead be created in an
> organized body that pays serious attention to the ability of the wide
> world to implement those standards without patent encumbrances.
>
> But even if IETF isn't willing to amend its patent policy that far-and
> most SDOs still aren't, unfortunately-at the very least we should take
> our work seriously. When someone proposes a serious RFC, we should
> demand that the water around that RFC be swept for mines-especially
> **disclosed** patent mines that any serious sailor would want to
> understand first.
>
> If IETF isn't willing to be that serious, maybe we should recommend
> that our work go to standards organizations that do care? As far as my
> time to volunteer for a better Internet, there are far better ways to
> do it than listening here to proposals that are merely "technical
> information." At the very least, separate that into a different list
> than IETF.org so I know what to ignore!
>
> By the way, many of the same companies and individuals who are
> involved here in IETF are also active participants in W3C, OASIS, and
> the new Open Web Foundation, all of which organizations pay more
> attention to patents and the concept of "open standards" than what
> IETF seems to be doing here. So let's not be disingenuous, please.
> Almost everyone here has previous experience doing this the right way.
>
> /Larry
>
> Lawrence Rosen
>
> Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com
> )
>
> 3001 King Ran

RE: Does being an RFC mean anything?

[Eran Hammer-Lahav]

> -Original Message-
> From: Mohsen BANAN [mailto:lists-i...@mohsen.banan.1.byname.net]
> Sent: Wednesday, March 11, 2009 6:01 PM
> 
> >>>>> On Wed, 11 Mar 2009 17:31:27 -0700, Eran Hammer-Lahav
>  said:
> 
>   Eran> There is no connection between the document status (standard,
> info,
>   Eran> experimental, etc.) to its IPR status.
> 
> You are dead wrong.
> 
> See Section 10.3.2 of RFC-2026.

If you are going to use strong language, you should at least make sure you are 
not contradicting yourself.

There is no connection between the document status to its IPR status. Any of 
the document types can have any IPR status. The only thing the section you 
referenced says in relation to this discussion is that if a disclosure is made, 
the IETF has to attempt to obtain a RAND license and either way, has to 
document the result of this effort.

> Note that after 13 years
>  RFC-2026 -- The Internet Standards Process --  Revision 3
>  October 1996
> is still the latest.
> 
> In other words, despite knowing about severe
> process problems nothing has been done for 13 years.
> 
> As I said before, the real problem is that even
> RFC-2026 is mostly imaginary and that IETF has
> become a cult dominated by interests of
> proprietary big business. As we are seeing.

My work obtaining licenses for open community specs and my role in the Open Web 
Foundation is all based on the view that standards should be free and 
unencumbered. There is nothing to prevent working groups from rejecting 
encumbered contribution or technology by consensus. Since the IETF process is 
completely open, it is easy for a committed community to make sure the right 
thing is done.

In addition, while the IETF process has indeed failed to catch-up with the 
time, the community around it is getting pretty sophisticated. The recent work 
of the FSF (no matter how misguided) is proof that the "little guy" still has a 
voice here. The entire IETF process depends on community consensus. There is no 
reason to significantly alter the culture and openness of this organization for 
something that can be accomplished via other means.

Big companies with deep pockets will find new avenues for their work if they 
don't like the way things are going on. There are many known examples of work 
leaving W3C to OASIS, etc. because some companies didn't like the terms. But 
the real damage is that the more strict the policy is, and the more rigid the 
process is, the less likely are people to participate. We all have jobs and 
employers and in most cases they control our IP and ability to participate in 
any such process.

People come to the IETF because this is where the knowledge is. This is where 
the experience is for many internet technologies. The IETF does not have the 
power or means to stop anyone from changing their work or proposing competing 
standards. What it has is the voice of a community that still matters more than 
many.

I have a lot of criticism for the IETF IPR process, or complete lack of 
meaningful protections. But I don't go around pointing fingers and make up 
conspiracy theories. I just talk to people, bring small and big players to the 
table, and try to be creative about it. And guess what, people are actually 
listening to what we are doing in the OWF.

If you think I am full of it, just wait a year or two and let's talk again then.

EHL




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