My Internet experience in the West at times is comparable to female foeticide

[Krishna Birth]

I believe that I am being banned, treated badly and threatened to stop
posting from certain Linux, PC, Software and Font internet forums and
mailing lists because I have a beyond religion or spiritual realm
cause in the projects that I am posting about.

When I read / listen about female infanticide / female foeticide, it
shows that this is happening why -- there is the cultural factor
operating.  My content is different and thus that is the reason that
I am being banned, treated badly and threatened to stop posting from
certain Linux, PC, Software and Font internet forums and mailing
lists.

To be fair there are some useful responses on  some internet forums /
mailing lists and threads.  Not all members are the same.

On the other hand for example in Britain Linux User Groups (LUGs) --
Swlug (South Wales) has banned my posting to it's Linux group,
Staffslug (Staffordshire)  only yesterday threatened me with banning.
Oxlug (Oxfordshire) does not allow me to post.  Same with the other
Sheflug (Sheffield).

Some not all internet forums/mailing list organisers need some
educating and need to educate others for example by having some
by-laws and rules so that I am treated without these problems.


Regards


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

Re: whine, whine, whine

[Ray Bellis]

On 21 Jun 2011, at 14:44, Klaas Wierenga wrote:

> otoh, not having to go through US immigrations saves you about as much
> time as you would have saved with a direct flight, not to mention the
> "terrorist until proven innocent" treatment. ;-)

Thus far I've been lucky with the TSA and found them courteous and reasonably 
efficient.

The longest queue by far I've ever had for immigration was at Vancouver for 
IETF70, where the shape of the queueing system coincidentally resembled the 
Hilbert space-filling curves we were playing with at the time.
 
I am slightly concerned about the relatively short time for my connection at 
YUL, though - I've only got 1h05 between scheduled landing from LHR and the hop 
out to YQB.

Ray



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

Re: My Internet experience in the West at times is comparable to female foeticide

[Ray Bellis]

On 22 Jun 2011, at 09:59, Krishna Birth wrote:

Some not all internet forums/mailing list organisers need some
educating and need to educate others for example by having some
by-laws and rules so that I am treated without these problems.

Oh, but they do!

The most common rule being that postings are *ON TOPIC*

Ray

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

Re: whine, whine, whine

[Scott Brim]

On Wed, Jun 22, 2011 at 06:35, Ray Bellis  wrote:
> I am slightly concerned about the relatively short time for my connection at 
> YUL, though - I've only got 1h05 between scheduled landing from LHR and the 
> hop out to YQB.

First I think you'll make it, but second I would not be too concerned,
apparently there are 15 flights on Sunday.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: My Internet experience in the West at times is comparable to female foeticide

[Dave Cridland]

On Wed Jun 22 09:59:14 2011, Krishna Birth wrote:

Swlug (South Wales) has banned my posting to it's Linux group,


You were banned there because your posts were (very) off-topic,  
you're not local to South Wales, and finally because we felt like it  
- you have no particular right to post to SWLUG's mailing list, after  
all.


HTH,

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

tools.ietf.org problem with RFC-to-be6282 (AUTH48)

[Mathieu Goessens]

Hi folks,

http://tools.ietf.org/html/draft-ietf-6lowpan-hc-15 has a link to 
RFC-to-be as the document looks in AUTH48 phrase:


http://tools.ietf.org/rfcmarkup?rfc-repository=http://www.rfc-editor.org/authors&doc=rfc6282&topmenu=true&document=draft-ietf-6lowpan-hc-15&docreplaces=draft-ietf-6lowpan-hc-15&title=RFC-EDITOR+AUTH48+REVIEW+COPY&extrastyle=body+{background-color:%23fee%3b}

This link is not working and outputs a python error.

Best regards,

--
Mathieu Goessens,
IRISA, Campus de Beaulieu, 35042 Rennes cedex, France
Tel: +33 (0) 2 99 84 71 00, Fax: +33 (0) 2 99 84 71 71
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: My Internet experience in the West at times is comparable to female foeticide

[Ted Ts'o]

On Wed, Jun 22, 2011 at 01:59:49PM +0100, Dave Cridland wrote:
> On Wed Jun 22 09:59:14 2011, Krishna Birth wrote:
> >Swlug (South Wales) has banned my posting to it's Linux group,
> 
> You were banned there because your posts were (very) off-topic,
> you're not local to South Wales, and finally because we felt like it
> - you have no particular right to post to SWLUG's mailing list,
> after all.

Furthermore, (putting on my IETF's Sargeant at Arms hat) Krishna's
complaint isn't on-topic for the IETF list, either.

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

External IPR Disclosures vs IPR disclosures in the document.

[Michael StJohns]

A quick couple of questions to the list based on a document I saw recently.

If a document (an ID in this case) contains encumbered material (in this case 
consists of 90%+ encumbered material), and the document is authored by the 
organization (or members of the organization) that holds the encumbrance, 
should the document contain an IPR disclosure itself or is it sufficient to 
submit a IPR disclosure through the IETF web interface?  

Should the ID Nits tool check for the inclusion of the notices for IPR required 
by section 5.1 of RFC 3978?

If a document contains primarily encumbered material, is authored by the owner 
of the encumbered material or its employees and is a non-work group document, 
is it appropriate to tag such document as "Intended Status: Standards Track"? 

For the first question, RFC3979 appears to say no.  However, I'm not sure the 
specific case I cite was considered.

For the last question - my guess is that it depends - specifically on the grant 
of license for the encumbered material and whether or not there are 
alternatives.  Given that, would RAND terms be sufficient in any case to 
advance this as a standard?

Thanks - Mike


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

Re: External IPR Disclosures vs IPR disclosures in the document.

[John C Klensin]

Mike,

Answer from a 10Km altitude perspective...

Our rules do not have dependencies on particular licensing
terms, whether RAND, free license, free without any notification
or specific license, defensive/reciprocal, or otherwise.   The
obligation of authors and companies is to disclose whatever it
is they need to disclose and, optionally whatever licensing
terms they feel they want to disclose along with it.  After
that, it is up to the WG and, ultimately, the community on Last
Call.   Absolutely nothing in the rules would prohibit us from
standardizing a technology that requires an expensive license,
negotiated on an individual basis and with no promises of fair
or equitable treatment for license applicants.  

In practice, I have doubts that any technology with those sorts
of restrictions would actually be standardized by the IETF
community, but there is no formal bar to trying (or to
identifying an I-D with an intended Standards-Track status).

  john


--On Wednesday, June 22, 2011 11:11 -0400 Michael StJohns
 wrote:

> A quick couple of questions to the list based on a document I
> saw recently.
> 
> If a document (an ID in this case) contains encumbered
> material (in this case consists of 90%+ encumbered material),
> and the document is authored by the organization (or members
> of the organization) that holds the encumbrance, should the
> document contain an IPR disclosure itself or is it sufficient
> to submit a IPR disclosure through the IETF web interface?  
> 
> Should the ID Nits tool check for the inclusion of the notices
> for IPR required by section 5.1 of RFC 3978?
> 
> If a document contains primarily encumbered material, is
> authored by the owner of the encumbered material or its
> employees and is a non-work group document, is it appropriate
> to tag such document as "Intended Status: Standards Track"? 
> 
> For the first question, RFC3979 appears to say no.  However,
> I'm not sure the specific case I cite was considered.
> 
> For the last question - my guess is that it depends -
> specifically on the grant of license for the encumbered
> material and whether or not there are alternatives.  Given
> that, would RAND terms be sufficient in any case to advance
> this as a standard?
> 
> Thanks - Mike
> 
> 
> ___
> 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: whine, whine, whine

[John Levine]

>I am slightly concerned about the relatively short time for my
>connection at YUL, though - I've only got 1h05 between scheduled
>landing from LHR and the hop out to YQB.

I presume you're coming in on the BA flight, since that's the only one
that has a 1:05 connection.  If you miss the 21:00 flight, there's a
23:00.  If the later flight is full, which seems unlikely since it's
currently showing more than 9 available seats, you can take the 21:45
bus.

R's,
John
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: External IPR Disclosures vs IPR disclosures in the document.

[Scott Brim]

On Wed, Jun 22, 2011 at 11:11, Michael StJohns  wrote:
> A quick couple of questions to the list based on a document I saw recently.
>
> If a document (an ID in this case) contains encumbered material (in this case 
> consists of 90%+ encumbered material), and the document is authored by the 
> organization (or members of the organization) that holds the encumbrance, 
> should the document contain an IPR disclosure itself or is it sufficient to 
> submit a IPR disclosure through the IETF web interface?

IPR statements are never put in RFCs unless on occasion they are
informational transplants from outside.  The IPR claims or other
aspects might change over time and the right place to track all that
is in the IPR disclosures.

> Should the ID Nits tool check for the inclusion of the notices for IPR 
> required by section 5.1 of RFC 3978?

IMHO that would be good.

> If a document contains primarily encumbered material, is authored by the 
> owner of the encumbered material or its employees and is a non-work group 
> document, is it appropriate to tag such document as "Intended Status: 
> Standards Track"?

As John says, we don't have any rules about what IPR is acceptable,
and actual practice depends on the WG and the situation.  In one case
terms were accepted because the patents were to expire in 2-3 years.
RFC3669 is pretty old but might still be a useful read.

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

Re: Gen-ART LC Review of draft-ietf-v6ops-6to4-to-historic-04

[Ole Troan]

Ben,

splendid comments! I've tried to incorporate all of them, and will either issue 
a new revision or make the changes during AUTH48 depending on other LC feedback.

cheers,
Ole

> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
> please see the FAQ at 
> .
> 
> Please resolve these comments along with any other Last Call comments you may 
> receive.
> 
> Document: draft-ietf-v6ops-6to4-to-historic-04
> Reviewer: Ben Campbell
> Review Date: 2011-06-17
> IETF LC End Date: 2011-06-20
> IESG Telechat date: 2011-06-23
> 
> Summary:
> 
> The draft is essentially ready for publication as an informational RFC. I 
> have a few editorial comments that may be worth considering prior to final 
> publication.
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments:
> 
> -- general: 
> 
> Idnits reports some potential issues. please check.
> 
> -- abstract:
> 
> The headers say this draft obsoletes these RFCs. Does moving to historical 
> obsolete then in that sense? Perhaps the abstract should say something like 
> "obsoletes, and moves to historical"
> 
> -- section 1, 2nd paragraph: "...designed to help transitioning the 
> Internet..."
> 
> Help transition, help in transitioning, or help the transition of
> 
> -- section 1, last paragraph:
> 
> Please expand 6rd on first mention. Also, Is this meant as an explicit 
> recommendation of 6rd as an alternative?
> 
> -- section 3, third paragraph: "...same operational burden has manually 
> configured tunnels..."
> 
> s/has/as
> 
> -- section 3, first bullet: "... and in the case the relay is overloaded 
> packet loss."
> 
> "overloaded, packet loss."
> 
> -- section 3, third bullet: "...customer relationship or..."
> 
> "... customer relationship between the end-user and the relay operator, or..."
> 
> -- section 3, 4th bullet: "In case of the reverse path 6to4 relay and the 
> anycast forward 6to4 relay, these have to be open for any address. Only 
> limited by the scope of the routing advertisement. "
> 
> Awkward sentence followed by a sentence fragment. Can these be reworded?
> 
> -- section 3, 5th bullet: "black hole"
> 
> Please define "black hole" in this context, or use a more descriptive (I.e. 
> less jargony) term.
> 
> 
> -- section 4, 2nd paragraph: "It is expected that disabling 6to4 in the IPv6 
> Internet will take some time."
> 
> Who expects it? The IETF? v6ops? The authors? (or can we just drop "It is 
> expected that")
> 
> "...deploy native IPv6 service."
> 
> s/service/services
> 
> -- section 4, numbered list:
> 
> It's not clear to me why this is a numbered list rather than an ordinary 
> paragraph
> 

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

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

[Paul E. Jones]

Mark,

> Generally, it's hard for me to be enthusiastic about this proposal, for
> a few reasons. That doesn't mean it shouldn't be published, but I do
> question the need for it to be Standards Track as a general mechanism.

I believe standards track is appropriate, since the objective is to define
procedures that are interoperable and the specification defines a set of
procedures that would be implemented by multiple software products.

> Mostly, it's because I hasn't really seen much discussion of it as a
> general component of the Web / Internet architecture; AFAICT all of the
> interest in it and discussion of it has happened in more specialised /
> vertical places. The issues below are my concerns; they're not
> insurmountable, but I would have expected to see some discussion of them
> to date on lists like this one and/or the TAG list for something that's
> to be an Internet Standard.

You might be right that more discussion has happened off the apps-discuss
list, but I would not equate that with not being a component of the web
architecture.  On the contrary, host-meta has a lot of utility and is an
important building block for the web architecture.  With host-meta, it is
possible to advertise information in a standard way, discover services, etc.
Some of the latter is not fully defined, but cannot be defined without this
standard in place.

> * 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.

XRD is not complicated.  It's an XML document spec with about seven elements
defined.  In order to convey metadata, one must have some format defined and
XRD is as good as any other.  I don't think the use of XRD should be
considered as negative aspect.  OpenID uses (through Yadis) a precursor to
XRD called XRDS. I'm not sure about Oauth's usage of XRD.  Either way, does
this matter?

> * Precedence -- In my experience one of the most difficult parts of a
> metadata framework like this is specifying the combination of metadata
> from multiple sources in a way that's usable, complete and clear.
> Hostmeta only briefly mentions precedence rules in the introduction.

I assume you are referring to the processing rules in 1.1.1?  How would you
propose strengthening that text?
 
> * Scope of hosts -- The document doesn't crisply define what a "host"
> is.

This might be deliberate and not really fault of this document.  The
"hostname" that we are all used to using for a "host" may or may not refer
to a physical host.  It might refer to a virtual host or a virtually hosted
domain.  In any case, this term is consistent with the term used on the HTTP
spec and the header line "Host:".

> * Context of metadata -- I've become convinced that the most successful
> uses of .well-known URIs are those that have commonality of use; i.e.,
> it makes sense to define a .well-known URI when most of the data
> returned is applicable to a particular use case or set of use cases.
> This is why robots.txt works well, as do most other currently-deployed
> examples of well-known URIs.
> 
> Defining a bucket for potentially random, unassociated metadata in a
> single URI is, IMO, asking for trouble; if it is successful, it could
> cause administrative issues on the server (as potentially many parties
> will need control of a single file, for different uses -- tricky when
> ordering is important for precedence), and if the file gets big, it will
> cause performance issues for some use cases.

All of the use cases are not defined, but the host-meta document provides
some examples, such as finding the author of a web page, copyright
information, etc.  There has been discussion of finding a user's identity
provider.  The particular uses.  Each of these examples fits well within the
host-meta framework.  It builds upon the "web linking" (RFC 5988) work you
did in a logical and consistent way, and I see these as complementary
documents.  To your concern, host-meta is flexible, but the functionality is
bounded.
 
> * Chattiness -- the basic model for resource-specfic metadata in
> hostmeta requires at least two requests; one to get the hostmeta
> document, and one to get the resource-specific metadata after
> interpolating the URI of interest into a template.

This is true, but the web is all about establishing links to other
information.  I view this is a "good thing" about host-meta: it provides a
very simple syntax with a way to use well-defined link relation types to
discover other information.
 
> For some use cases, this might be appropriate; however, for many others
> (most that I have encountered), it's far too chatty. Many use cases find
> the latency of one extra request unacceptable, much less two. Many use
> cases require fetch

Google to Host IETF Meeting

[IETF Administrative Director]

The IAOC and the Internet Society are very pleased to announce that Google will 
be be the Host for IETF 84
in Vancouver in 2012.  Google most recently was the Host for IETF 73 in 
Minneapolis in 2008.

We want to thank our benefactors.  The IETF cannot support its technical 
standards efforts, including the 
Secretariat and RFC Editor, without the generous support of its hosts and 
sponsors.

Been thinking about hosting or sponsoring a future meeting?  The meetings 
calendar through 2017 
 shows some of the possibilities. Just 
send Drew Dvorshak an
email at dvors...@isoc.org and he can walk you through the opportunity. 

Thanks again Google!  We couldn't do it without you.
 
Hope to see you in Quebec City at IETF 81in 31 days!  More than 500 are 
currently registered.
Registration is still open!  http://www.ietf.org/meeting/81/index.html

Ray Pelletier
IETF Administrative Director
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of 
> Douglas Otis
> Sent: Tuesday, June 21, 2011 6:51 PM
> To: ietf@ietf.org; Barry Leiba; iesg-secret...@ietf.org; Sean Turner
> Subject: Last Call:  (DomainKeys 
> Identified Mail (DKIM) Signatures) to Draft Standard
> 
> [...]
> 
> This indicates the DKIM specification is seriously flawed.  While DKIM
> may not offer author validation, it was intended to establish an
> accountable domain for the signed message content that at a minimum
> includes the From header field.  There are NO valid reasons for a valid
> signature to include multiple From header fields!  Allowing multiple
> From header fields is _EVIL_ and destroys DKIM's intended purpose as
> defined by prior work.

This purported security flaw and surrounding FUD was discussed at huge length 
in the working group, and consensus was clearly against the idea of dealing 
with this in DKIM because it's the wrong place to address the problem.  The 
record, both in the issues tracker and in the working group's archive, is quite 
clear about this, and both are open to public scrutiny.

And I find the tactic of taking a lost battle from a working group to the IETF 
as a whole to be akin to the "Mom said no, I'll go ask Dad!" strategy that I 
outgrew by the time I was a teenager...

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

Re: Last Call: (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard

[Scott Kitterman]

On Wednesday, June 22, 2011 01:17:16 pm Murray S. Kucherawy wrote:
> > -Original Message-
> > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
> > Douglas Otis Sent: Tuesday, June 21, 2011 6:51 PM
> > To: ietf@ietf.org; Barry Leiba; iesg-secret...@ietf.org; Sean Turner
> > Subject: Last Call:  (DomainKeys
> > Identified Mail (DKIM) Signatures) to Draft Standard
> > 
> > [...]
> > 
> > This indicates the DKIM specification is seriously flawed.  While DKIM
> > may not offer author validation, it was intended to establish an
> > accountable domain for the signed message content that at a minimum
> > includes the From header field.  There are NO valid reasons for a valid
> > signature to include multiple From header fields!  Allowing multiple
> > From header fields is _EVIL_ and destroys DKIM's intended purpose as
> > defined by prior work.
> 
> This purported security flaw and surrounding FUD was discussed at huge
> length in the working group, and consensus was clearly against the idea of
> dealing with this in DKIM because it's the wrong place to address the
> problem.  The record, both in the issues tracker and in the working
> group's archive, is quite clear about this, and both are open to public
> scrutiny.
> 
> And I find the tactic of taking a lost battle from a working group to the
> IETF as a whole to be akin to the "Mom said no, I'll go ask Dad!" strategy
> that I outgrew by the time I was a teenager...

While I'm not thrilled by the post-4871 changes in general, I think on this 
point there's not an issue.  I recently worked through the multiple From case 
for a DKIM implementation I'm helping on and found sufficient guidance in RFC 
4871 to deal with it reasonably.  This was definitely beat to death in the WG.

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

Re: Last Call: (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard

[Dave CROCKER]

Folks,

The bottom line about Doug's note is that the working group extensively 
considered the basic issue of multiple From: header fields and Doug is raising 
nothing new about the topic.


A quick summary of the technical point at the core of Doug's concern is that the 
presence of multiple rfc5322.From header fields does appear to represent a 
plausible attack vector, but it also violates RFC5322 -- and RFC822, if anyone 
is worried about the history of this issue.  DKIM (RFC4871) requires that the 
signing engine be handed a valid RFC5322 message.  Hence the burden of ensuring 
that there is only one From: field rests outside DKIM.


For reference, Doug posted a related blog recently and I posted a response 
yesterday:


   

Others are posting responses also. The Comment mechanism, to the Circleid 
article, is being used to list these additional responses.



Inline comments...


On 6/21/2011 6:50 PM, Douglas Otis wrote:But,

RFC4686 Introduction states:

...

While several threats to DKIM were considered, multiple From header fields were
neglected. This document only focused on use of multiple addresses within the
 From header field.


Any possible omissions in an Informational threats document -- done 6 years ago 
and before the signing specification (RFC4871) was written -- is of marginal 
relevance, at best.




It should be noted that Signing Practices are referenced off a domain found in
the From header field which also assumes only one will be present.


It also should be noted that Signing Practices (ADSP) issues are irrelevant to 
the candidate RFC4871bis effort, which pertains only to the signing specification.





This indicates the DKIM specification is seriously flawed.


It indicates that there is an issue, not that it is DKIM's responsibility to 
solve it.




While DKIM may notoffer author validation,


Does not.  Not may not.  It's a simple and direct fact.


>it was intended to establish an accountable domain for

the signed message content that at a minimum includes the From header field.


And it does that.  But it does not make any assertions about the /validity/ of 
any of the data it signs, nevermind any of the data it does NOT sign.




There are NO valid reasons for a valid signature to include multiple From header
fields! Allowing multiple From header fields is _EVIL_ and destroys DKIM's
intended purpose as defined by prior work.


It actually has no discernible effect on DKIM's utility, nor have there been 
reports from the field of problems in 6 years of deployed use.




Free email providers likely use DKIM to gain increased acceptance by taking
advantage of their "too big to block" volumes. For these domains, their
reputation is understood to offer little assurance of their overall integrity
while perhaps limiting what is allowed in the domain portion of the From header
field.


This appears to be a political rant.



By allowing a pre-pended From header field to not affect the validity of a DKIM
signature according to the specification means the UNDERSTOOD source of a
message can NEVER be trusted through the aid of DKIM.


That statement well might be correct, but that's OK, since DKIM does not make 
assertions about "source" validity, except in terms of the separate DKIM signing 
identifier (in the DKIM-Signature: header field.)  The signer is sometimes 
referred to as a source.  However DKIM makes no assertions concerning the Author 
or Originator [RFC5598].




The general goal of DKIM cryptographically binding at a minimum the From header
field of the message content to a domain was to act as a trust basis for
acceptance.


The general goal is to attach an identifier than is reliable and valid, and it 
does that.  The identifier can be used for developing a reputation assessment of 
message streams signed with that identifier.




 DKIM also purports to allow incremental deployment without requiring
additional undefined filtering be introduced in mail transfer or mail user
agents. Clearly, the incremental deployment statement conflicts with the
original goals due to the neglected input validation flaw.


I have no idea what the above means.



Details of this concern were stated in the tracker at:
http://trac.tools.ietf.org/wg/dkim/trac/ticket/24


And it nicely shows that the working group considered the issue.



This version of DKIM also introduced use of RFC5890 instead of RFC3490, which
allows use of the German esset and the Greek final sigma, drops string-prep, and
defines 3,329 invalid code points. Unfortunately, this version of the DKIM also
failed to exclude use of Fake A-Labels, which when presented to the user may
also prove highly deceptive.


Excellent.  Now it is also DKIM's job to fix problems with Unicode...



Details of this concern were stated in the tracker at:
http://trac.tools.ietf.org/wg/dkim/trac/ticket/24


wrong citation.


d/
--

  Dave Crocker
  Brandenburg Internet

Re: My Internet experience in the West at times is comparable to female foeticide

[Krishna Birth]

On Wed, Jun 22, 2011 at 12:59 PM, Dave Cridland  wrote:

> You were banned there because your posts were (very) off-topic, you're not
> local to South Wales, and finally because we felt like it - you have no
> particular right to post to SWLUG's mailing list, after all.
>
> HTH,
>
> Dave.

Your banning with a due process is baseless, there is not any by-laws
or rules quotation from the Swlug main document/s which should be
fixed with an unchangeable date stamp and any amendments to the main
document/s should also have an unchangeable date stamp, for example on
a Usenet public group.  You and other that have banned, intimidated me
need some education on how to run mailing lists.  There are no grounds
for you to ban me.

Alug (Anglian) is another linux user group today in Britain who have
joined the weasel worded racists chants by more or less banning me.

The mid to late banners have questioned my linux projects as to why I
wish to do them? When I have answered them that this is for spiritual
reasons -- they then ban me by conjuring some lies, the rabbit in the
hat trick.  This is cheating and it does not give linux operating
systems a good name.

All the banners should unban me.  This is racial law matter.  Justice
needs to be delivered.  These professional salaried / fee-earning
banners are not honest.  They are cunning in their ways.  I have a
huge evidence against these modern day 'journeymen' at linux user
groups in Britain and also in other areas.

While I write this for the IETF under this subject, I also wish to
complain about IETF being separate from the humanities, for example
the new domain suffix proposed by The Internet Corporation for
Assigned Names and Numbers (ICANN)  .xxx should not be put into use as
it demeans females through pornography.  Senior IETF members must
voice their concerns.


Regards


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

Re: My Internet experience in the West at times is comparable to female foeticide

[Krishna Birth]

Correction:

"Your banning without a due process is baseless"

On Wed, Jun 22, 2011 at 7:48 PM, Krishna Birth  wrote:
> On Wed, Jun 22, 2011 at 12:59 PM, Dave Cridland  wrote:
>
>> You were banned there because your posts were (very) off-topic, you're not
>> local to South Wales, and finally because we felt like it - you have no
>> particular right to post to SWLUG's mailing list, after all.
>>
>> HTH,
>>
>> Dave.
>
> Your banning with[out] a due process is baseless, there is not any by-laws
> or rules quotation from the Swlug main document/s which should be
> fixed with an unchangeable date stamp and any amendments to the main
> document/s should also have an unchangeable date stamp, for example on
> a Usenet public group.  You and other that have banned, intimidated me
> need some education on how to run mailing lists.  There are no grounds
> for you to ban me.
>
> Alug (Anglian) is another linux user group today in Britain who have
> joined the weasel worded racists chants by more or less banning me.
>
> The mid to late banners have questioned my linux projects as to why I
> wish to do them? When I have answered them that this is for spiritual
> reasons -- they then ban me by conjuring some lies, the rabbit in the
> hat trick.  This is cheating and it does not give linux operating
> systems a good name.
>
> All the banners should unban me.  This is racial law matter.  Justice
> needs to be delivered.  These professional salaried / fee-earning
> banners are not honest.  They are cunning in their ways.  I have a
> huge evidence against these modern day 'journeymen' at linux user
> groups in Britain and also in other areas.
>
> While I write this for the IETF under this subject, I also wish to
> complain about IETF being separate from the humanities, for example
> the new domain suffix proposed by The Internet Corporation for
> Assigned Names and Numbers (ICANN)  .xxx should not be put into use as
> it demeans females through pornography.  Senior IETF members must
> voice their concerns.
>
>
> Regards
>
>
> Meeku
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: External IPR Disclosures vs IPR disclosures in the document.

[Michael StJohns]

At 11:42 AM 6/22/2011, Scott Brim wrote:
>On Wed, Jun 22, 2011 at 11:11, Michael StJohns  wrote:
>> A quick couple of questions to the list based on a document I saw recently.
>>
>> If a document (an ID in this case) contains encumbered material (in this 
>> case consists of 90%+ encumbered material), and the document is authored by 
>> the organization (or members of the organization) that holds the 
>> encumbrance, should the document contain an IPR disclosure itself or is it 
>> sufficient to submit a IPR disclosure through the IETF web interface?
>
>IPR statements are never put in RFCs unless on occasion they are
>informational transplants from outside.  The IPR claims or other
>aspects might change over time and the right place to track all that
>is in the IPR disclosures.

Hmm.. even though this was labeled like a normal run of the mill ID, it really 
was an informational transfer from the outside - at least at this point in the 
process.  I.e. - single corporate author, long held IPR as opposed to "here's 
something brand new and never seen before and while parts of it may derive from 
work from company A, this use of it is new and people from company B and C are 
figuring out new ways to work with it."

I think tracking disclosures via the IPR system is reasonable for most 
documents, but something like "This document consists primarily of intellectual 
property claimed to owned by .  Please consult the IETF disclosures section 
for the current terms and conditions for this IPR." may be useful.It's 
pretty hard to tell from any given document whether or not consulting the IPR 
disclosures is useful or somewhat necessary.

Not a big problem, I guess, but somewhat dissonant to the process.

Mike


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

Re: External IPR Disclosures vs IPR disclosures in the document.

[Scott O. Bradner]

see RFC 3979 section 4 A - a note like Mike asks for is called for

but the other Scott is also right - do not be specific - see section 11 of the 
same RFC

Scott

On Jun 22, 2011, at 3:56 PM, Michael StJohns wrote:

> At 11:42 AM 6/22/2011, Scott Brim wrote:
>> On Wed, Jun 22, 2011 at 11:11, Michael StJohns  wrote:
>>> A quick couple of questions to the list based on a document I saw recently.
>>> 
>>> If a document (an ID in this case) contains encumbered material (in this 
>>> case consists of 90%+ encumbered material), and the document is authored by 
>>> the organization (or members of the organization) that holds the 
>>> encumbrance, should the document contain an IPR disclosure itself or is it 
>>> sufficient to submit a IPR disclosure through the IETF web interface?
>> 
>> IPR statements are never put in RFCs unless on occasion they are
>> informational transplants from outside.  The IPR claims or other
>> aspects might change over time and the right place to track all that
>> is in the IPR disclosures.
> 
> Hmm.. even though this was labeled like a normal run of the mill ID, it 
> really was an informational transfer from the outside - at least at this 
> point in the process.  I.e. - single corporate author, long held IPR as 
> opposed to "here's something brand new and never seen before and while parts 
> of it may derive from work from company A, this use of it is new and people 
> from company B and C are figuring out new ways to work with it."
> 
> I think tracking disclosures via the IPR system is reasonable for most 
> documents, but something like "This document consists primarily of 
> intellectual property claimed to owned by .  Please consult the IETF 
> disclosures section for the current terms and conditions for this IPR." may 
> be useful.It's pretty hard to tell from any given document whether or not 
> consulting the IPR disclosures is useful or somewhat necessary.
> 
> Not a big problem, I guess, but somewhat dissonant to the process.
> 
> Mike
> 
> 
> ___
> 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: My Internet experience in the West at times is comparable to female foeticide

[Ole Jacobsen]

Seargent at Arms:

Please have this individual banned from the IETF list at your earliest 
convenience. He apparently has no idea what "on topic" means.

Ole


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

Re: My Internet experience in the West at times is comparable to female foeticide

[Dave CROCKER]

On 6/22/2011 3:39 AM, Ray Bellis wrote:


On 22 Jun 2011, at 09:59, Krishna Birth wrote:


Some not all internet forums/mailing list organisers need some
educating and need to educate others for example by having some
by-laws and rules so that I am treated without these problems.


Oh, but they do!

The most common rule being that postings are *ON TOPIC*



But the most important rule is to refrain from feeding obviously useless 
threads.

d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Mark Nottingham]

On 23/06/2011, at 2:04 AM, Paul E. Jones wrote:

> Mark,
> 
>> Generally, it's hard for me to be enthusiastic about this proposal, for
>> a few reasons. That doesn't mean it shouldn't be published, but I do
>> question the need for it to be Standards Track as a general mechanism.
> 
> I believe standards track is appropriate, since the objective is to define
> procedures that are interoperable and the specification defines a set of
> procedures that would be implemented by multiple software products.

That can be said of pretty much every specification that comes along; does this 
imply that you think everything should be standards track?

At the end of the day, it's standards track if the IESG says it is. They asked 
for feedback on the Last Call, and I gave mine. It's not the end of the world 
if this becomes Standards Track, but I felt that it shouldn't pass without 
comment.


>> Mostly, it's because I hasn't really seen much discussion of it as a
>> general component of the Web / Internet architecture; AFAICT all of the
>> interest in it and discussion of it has happened in more specialised /
>> vertical places. The issues below are my concerns; they're not
>> insurmountable, but I would have expected to see some discussion of them
>> to date on lists like this one and/or the TAG list for something that's
>> to be an Internet Standard.
> 
> You might be right that more discussion has happened off the apps-discuss
> list, but I would not equate that with not being a component of the web
> architecture.  

... and I didn't equate it with that either; I said it was concerning that it 
hadn't been discussed broadly.


> On the contrary, host-meta has a lot of utility and is an
> important building block for the web architecture.  With host-meta, it is
> possible to advertise information in a standard way, discover services, etc.
> Some of the latter is not fully defined, but cannot be defined without this
> standard in place.

A "lot of utility" and being "an important building block" are completely 
subjective, of course. I'd agree with a statement that it's an important 
building block of OAuth, for example, but it seems quite premature to call it 
an important building block of the Web arch. 


>> * 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.
> 
> XRD is not complicated.  It's an XML document spec with about seven elements
> defined.  In order to convey metadata, one must have some format defined and
> XRD is as good as any other.  I don't think the use of XRD should be
> considered as negative aspect.  OpenID uses (through Yadis) a precursor to
> XRD called XRDS. I'm not sure about Oauth's usage of XRD.  Either way, does
> this matter?

Choosing your foundations well matters greatly.


>> * Precedence -- In my experience one of the most difficult parts of a
>> metadata framework like this is specifying the combination of metadata
>> from multiple sources in a way that's usable, complete and clear.
>> Hostmeta only briefly mentions precedence rules in the introduction.
> 
> I assume you are referring to the processing rules in 1.1.1?  How would you
> propose strengthening that text?

It's not a matter of strengthening the text, it's a matter of agreeing upon and 
defining an algorithm. As it sits, the document doesn't do much more than wave 
its hands about precedence.


>> * Scope of hosts -- The document doesn't crisply define what a "host"
>> is.
> 
> This might be deliberate and not really fault of this document.  The
> "hostname" that we are all used to using for a "host" may or may not refer
> to a physical host.  It might refer to a virtual host or a virtually hosted
> domain.

You use "might" a lot here. Do you know what it is, or are you just speculating?


> In any case, this term is consistent with the term used on the HTTP
> spec and the header line "Host:".

The Host header field conveys a host and a port, where this document seems to 
attach a very ephemeral concept to the term.


>> * Context of metadata -- I've become convinced that the most successful
>> uses of .well-known URIs are those that have commonality of use; i.e.,
>> it makes sense to define a .well-known URI when most of the data
>> returned is applicable to a particular use case or set of use cases.
>> This is why robots.txt works well, as do most other currently-deployed
>> examples of well-known URIs.
>> 
>> Defining a bucket for potentially random, unassociated metadata in a
>> single URI is, IMO, asking for trouble; if it is successful, it could
>> cause administrative issues on the server (as potentially many parties
>> will need control of a single file, for different uses -- tricky when
>> ordering is 

Re: Last Call: (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard

[Barry Leiba]

To add chair support to Murray's comment:

On Wed, Jun 22, 2011 at 13:17, Murray S. Kucherawy  wrote:
>> -Original Message-
>> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of 
>> Douglas Otis
>> Sent: Tuesday, June 21, 2011 6:51 PM
>> To: ietf@ietf.org; Barry Leiba; iesg-secret...@ietf.org; Sean Turner
>> Subject: Last Call:  (DomainKeys 
>> Identified Mail (DKIM) Signatures) to Draft Standard
>>
>> [...]
>>
>> This indicates the DKIM specification is seriously flawed.  While DKIM
>> may not offer author validation, it was intended to establish an
>> accountable domain for the signed message content that at a minimum
>> includes the From header field.  There are NO valid reasons for a valid
>> signature to include multiple From header fields!  Allowing multiple
>> From header fields is _EVIL_ and destroys DKIM's intended purpose as
>> defined by prior work.
>
> This purported security flaw and surrounding FUD was discussed at huge length
> in the working group, and consensus was clearly against the idea of dealing 
> with
> this in DKIM because it's the wrong place to address the problem.  The 
> record, both
> in the issues tracker and in the working group's archive, is quite clear 
> about this,
> and both are open to public scrutiny.

Indeed.  We gave this issue at least two clear consensus calls, and
it's very clear that the rough consensus considers the kind of
validation that Doug is asking for to be a good idea, but outside the
scope of the DKIM protocol.  That is, the validation ought to be done
in another part of the software system.  The document does actually
advise that, and that advice is all that working group consensus was
behind.  Consensus also is that Doug is severely overstating the
problem.

This has been decided and re-decided.

> And I find the tactic of taking a lost battle from a working group to the 
> IETF as
> a whole to be akin to the "Mom said no, I'll go ask Dad!" strategy that I 
> outgrew
> by the time I was a teenager...

I, too, have a problem with how IETF last call is sometimes being used
by working group participants to rehash issues.  But that's a subject
for a separate conversation, and not for here.

Barry, DKIM working group chair
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf