date:20060525

> > Yes, that individual I-D is productized as a proprietary protocol by one
> > company (Cisco).
> 
> As I understand it, EAP over UDP is one of the items proposed for
> standardization in the NEA WG.  

You misunderstood it, despite the clear text in their charter:

...

  Requirements need to
  be defined for an EAP over L3 transport for L3 access scenarios.

...

  * Review ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG)
and work with ADs to identify the WG responsible for accommodating
protocol requirements that are not currently being met.


> That leads me to wonder whether the IETF
> will be chartering multiple WGs to standardize EAP encapsulation over IP.
> 
> Although my understanding of both PANA and NEA is no doubt
> incomplete/wrong/confusled, having multiple EAP encapsulation standards
> seems duplicative to me.

It is not suggested anyways.

> > As for 3GPP2, I can get into really gory details of what has been
> happening
> > there, but it's not technical at all (if you are familiar with 3GPP2 and
> the
> > relevant players in this discussion, you can guess).
> 
> The issue is that integration of PANA with link layer technologies
> requires the support of the organizations that own those link layers.

Not necessarily. Why do you think so? 802.11 is a counter example. DSL is a
counter example. 

> Without that link layer integration (for whatever reason) the scenarios
> can't be realized, at least in a mainstream way.
> 
> It seems to me that one of the motivations for PANA is to *avoid* link
> layer
> dependencies in situations where link layer technology is inadequate/can't
> be deployed, and a forklift upgrade isn't in the budget.  In those
> circumstances, integration with link layers or IPsec VPN technology is
> not under consideration -- because that would require a forklift upgrade.
>
> For example, the wireless hotspot case where something more sophisticated
> than a Web portal is needed, but a forklift upgrade to WPA2 or a VPN
> deployment isn't a realistic alternative.  Or the shared wired media case
> where "network port authentication" doesn't really work, and wholesale
> switch port replacements aren't affordable.  In both of those cases, EAP
> over IP might provide a light weight, easily deployed solution.

Are you referring to NACP as "EAP over IP"? You acknowledged it is designed
for wired networks. It is not even useful for wireless. Won't work.

> Yet, rather than focusing on the specific scenarios in which PANA might
> be compelling, the PANA framework document tries to cover a wide
> range of potential uses, trying to position PANA for use in scenarios
> where the case is less obvious.

I think that would have been unnecessarily limiting, given that we designed
a protocol that can naturally work in variety of scenarios.

Alper








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

Re: The Emperor Has No Clothes: Is PANA actually useful?

2006-05-25 Thread Yoshihiro Ohba

On Thu, May 25, 2006 at 09:24:03PM -0700, Bernard Aboba wrote:
> > I have other security-related issues on NACP.  My view is that secure
> > enhancement of NACP will be equivalent to the EAP over UDP protocol
> > the IETF is standardizing, PANA.
> 
> Can you describe why the security of PANA is better than EAP over UDP 
> (NACP)?  I had thought that they were more or less equivalent, since 
> neither approach mandates protection. 

NACP does not have its own integrity protection mechanism while PANA
has.  It is true that PANA AUTH AVP is optional, but the use of
protection is mandatory when an EAP method that is capable of deriving
keys is used.  This is described in the PANA specification draft.

We can discuss security aspects more, but what I would really like to
say in this thread is that discussing usefulness of PANA or any other
EAP transport without deep security analysis does not appear to be the
right thing.

Yoshihiro Ohba

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

Re: The Emperor Has No Clothes: Is PANA actually useful?

> I have other security-related issues on NACP.  My view is that secure
> enhancement of NACP will be equivalent to the EAP over UDP protocol
> the IETF is standardizing, PANA.

Can you describe why the security of PANA is better than EAP over UDP 
(NACP)?  I had thought that they were more or less equivalent, since 
neither approach mandates protection. 

But maybe I am missing something? 

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

RE: The Emperor Has No Clothes: Is PANA actually useful?

> Yes, that individual I-D is productized as a proprietary protocol by one
> company (Cisco). 

As I understand it, EAP over UDP is one of the items proposed for 
standardization in the NEA WG.  That leads me to wonder whether the IETF 
will be chartering multiple WGs to standardize EAP encapsulation over IP. 

Although my understanding of both PANA and NEA is no doubt 
incomplete/wrong/confusled, having multiple EAP encapsulation standards 
seems duplicative to me.

> As for 3GPP2, I can get into really gory details of what has been happening
> there, but it's not technical at all (if you are familiar with 3GPP2 and the
> relevant players in this discussion, you can guess).

The issue is that integration of PANA with link layer technologies 
requires the support of the organizations that own those link layers.  
Without that link layer integration (for whatever reason) the scenarios 
can't be realized, at least in a mainstream way. 

It seems to me that one of the motivations for PANA is to *avoid* link layer 
dependencies in situations where link layer technology is inadequate/can't 
be deployed, and a forklift upgrade isn't in the budget.  In those 
circumstances, integration with link layers or IPsec VPN technology is 
not under consideration -- because that would require a forklift upgrade.

For example, the wireless hotspot case where something more sophisticated 
than a Web portal is needed, but a forklift upgrade to WPA2 or a VPN 
deployment isn't a realistic alternative.  Or the shared wired media case 
where "network port authentication" doesn't really work, and wholesale 
switch port replacements aren't affordable.  In both of those cases, EAP 
over IP might provide a light weight, easily deployed solution.

Yet, rather than focusing on the specific scenarios in which PANA might 
be compelling, the PANA framework document tries to cover a wide 
range of potential uses, trying to position PANA for use in scenarios 
where the case is less obvious. 

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

Re: The Emperor Has No Clothes: Is PANA actually useful?

2006-05-25 Thread Yoshihiro Ohba

On Thu, May 25, 2006 at 04:45:39PM -0700, Bernard Aboba wrote:
>
> I do understand the potential need for EAP to be encapsulated over IP.  
> However, in practice PANA is more complex than EAP over UDP 
> (see draft-thomson-nacp-02.txt), which looks like it is on the road 
> to becoming the defacto standard for EAP encapsulation over IP. 

I don't think draft-thomson-nacp-02.txt is something to become an IETF
standard EAP over UDP protocol because of its lack of security.  In
fact the draft admits:

"
   If breach of confidentiality and deliberate attacks on the integrity
   of the NACP protocol itself are a significant risk in certain
   deployment environments, NACP should be protected by a protocol that
   offers confidentiality and/or packet authentication, integrity and
   protection against replay e.g.  IPSEC [RFC2401].
"

Why IPsec is needed to carry EAP?  What is authentication protocol for
bootstrapping IPsec to protect NACP, perhaps EAP over IKEv2??

I have other security-related issues on NACP.  My view is that secure
enhancement of NACP will be equivalent to the EAP over UDP protocol
the IETF is standardizing, PANA.

Yoshihiro Ohba


> 
> So from what I can tell, in each potential usage scenario PANA is 
> either not feasible, is more complex than an established alternative, 
> or has been rejected by the SDOs that have examined it.
> 
> ---
> Sam Hartman said:
> 
> Hi.  Speaking as an individual, I'd like to make an explicit call for
> members of the IETF community not involved in the PANA working group
> to review draft-ietf-pana-framework.  Please speak up if you have done
> such a review or attempted such a review and been unsuccessful.  Let
> us know what you think PANA is intended to be useful for and whether
> you think it is actually useful.
> 
> My strong hunch is that we've chartered work for some reason, and now
> that the working group is nearing the end of its charter, we still
> don't understand why we want this thing we've built and whether it's a
> good idea.  People aren't screaming not so much because they are happy
> with results but because no one actually understands PANA.
> 
> I understand that there's a strong presumption that once chartered,
> work is useful.  I'd like to challenge this presumption enough to get
> people to actually read the document.  If people not involved in the
> effort sit down, read the document and understand what it's all about,
> my concern is satisfied.  But if enough people try to read the
> document, try to understand and fail, we're not done yet.  We
> certainly cannot have consensus to publish something we've tried and
> failed to understand.
> 
> It's not just me.  I've been trying to find people outside of PANA who
> claim to understand the effort and what it's good for and why
> link-layer solutions are not better.  When the first discussion of
> PANA hit the IESG, I asked other IESG members why PANA was a good idea
> and what problem it solved.  "Don't go there," was the advice I got
> from the responsible AD.
> 
> At that time (a year and a half ago) there was no one on the IESG who
> claimed to understand PANA or to think it was a good idea.
> 
> I'm fairly sure that with the possible exception of Jari (who is a
> technical advisor to PANA), that's still true.
> 
> The security community has been trying to understand PANA.  I've sent
> multiple security reviewers at the PANA document.s They always come
> back fundamentally confused about what PANA is trying to do or about
> whether it is a good idea.  They end up focusing on some detail or
> another and asking for some minor part of the system to be fixed.  But
> I don't get the impression from the reviews they understand the
> overall picture; explicit discussion of this also indicates that they
> are not confident in their understanding nor do they know whether it
> is a good idea.
> 
> We keep running back over the same ground, still confused and still
> trying to muddle through to no real effect.
> 
> I've tried to understand it myself.  I tried to understand in the BOF.
> It was very clear to me leaving the original PANA BOF that something
> was very confused.  Every year or so since I've tried to go back and
> figure out what I missed.  Eventually though I've started wondering
> whether the problem wasn't me, but was an actual lack of clarity.
> 
> So, folks can you please help us all out.  Especially if the internet
> area is not your primary focus, especially if you've never heard of
> PANA before, take a look at the framework document and all their other
> documents.  Do you get it?  Is it a good idea?
> 
> Thanks for your time.
> 
> P.S.  Again, this is me speaking as an individual.  At this late
> stage, it would be entirely inappropriate for me to take actions as an
> AD claiming that we didn't understand a problem without a strong
> community consensus.
> 
> ___
> I

RE: The Emperor Has No Clothes: Is PANA actually useful?

> 
> > Just below you are acknowledging the need for EAP over IP. I don't
> > understand how you can still claim you don't understand why PANA is
> > useful...
> 
> The framework doesn't seem to talk much about simple EAP over IP
> scenarios, so I have assumed this is not the major focus.

I am sure you read RFC 4058 (like anyone who claims they don't understand
PANA should have done). RFC 4058 said:

   PANA will carry EAP above IP in order to enable any authentication
   method on any link-layer.


> > You are aware that "virtual open-access AP" mode is OK. One of the
> > two alternatives we proposed had an issue, and the other one still
> holds.
> 
> Right.  I was referring only to the WPA/WPA2 scenarios.

Your earlier statement did give another impression, like PANA does not work
with 802.11i at all. Thanks for clarifying it now!


> > De-facto? Could you please elaborate how it is becoming a de-facto
> standard?
> 
> EAP over UDP is one of the foundation technologies for Network Endpoint
> Assessment (NEA).  As I understand it, EAPoUDP is being made available on
> most operating systems, and is in the process of being deployed by many
> enterprise customers.

Yes, that individual I-D is productized as a proprietary protocol by one
company (Cisco). Client-side software may be made available by them for
various platforms (note PANA is already made available as an open source
--both client and software side). If Cisco develops a proprietary protocol
on its own for a subset of our work, should we now stop what we do at IETF?
Is that where this whole fuss is coming from now?

> > Besides. Of course PANA is more complex than EAPoUDP. The latter (an
> > individual I-D) has very limited applicability.
> 
> As I understand it, EAP over UDP is mostly being deployed for wired access
> scenarios where IEEE 802.1X might not work well (e.g. multiple hosts
> sharing a port).
> 
> > Which SDOs? Please give us more detail.
> 
> As I understand it, 3GPP2 has considered PANA, and IEEE 802.11 has
> evaluated the PANA framework document.

How does this explain your "rejected by the SDOs" claim? IEEE 802.11
provided a review feedback and they fixed few important problems and
acknowledged the applicability of our other alternative solutions. How is
that a rejection?!? 

As for 3GPP2, I can get into really gory details of what has been happening
there, but it's not technical at all (if you are familiar with 3GPP2 and the
relevant players in this discussion, you can guess).


Alper





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

Re: Last Call: 'SMTP Submission Service Extension for Future Message Release' to Proposed Standard (draft-vaudreuil-futuredelivery)

2006-05-25 Thread Scott Kitterman

On Thursday 25 May 2006 18:39, The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
>
> - 'SMTP Submission Service Extension for Future Message Release '
> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by 2006-06-22.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-vaudreuil-futuredelivery-03.txt
>
This is the first time I've seen this document.  Based on a once through it 
seems technically complete and coherent.  The security considerations section 
addressed the issues that I thought of when reading the document.

I do have a couple of minor comments:

In the change log, it mentions that the term HOLD has been changed to HOLDFOR 
and HOLDUNTIL in this revision of the draft.  In paragraph 4.2.2, MSA 
interaction with DSN, the obsolete term HOLD still appears in sub-para 2.  
While minor, this should be corrected prior to publication.

There is no collected ABNF.  In general, I find having the entire ABNF 
together for reference to be useful as an implementer and so it would be nice 
to have in this document.  Additionally, I think that the omission mentioned 
in the previous comment would have been obvious in a collected ABNF.

Scott Kitterman

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

RE: I-D ACTION:draft-ash-alt-formats-02.txt

2006-05-25 Thread Ash, Gerald R $Jerry$, ALABS

Hi All,

Please see the updated draft "Proposed Experiment: Normative Format in
Addition to ASCII Text" at
http://www.ietf.org/internet-drafts/draft-ash-alt-formats-02.txt, .pdf
version available at
http://www.ietf.org/internet-drafts/draft-ash-alt-formats-02.pdf.


The draft describes an RFC 3933 Process Experiment allowing normative
PDF output be trialed for RFCs and I-Ds.  As discussed in Section 3,
documents in the Routing Area Working Group ([U-TURN]) and Network Time
Protocol Working Group ([NTP-ALGORITHM]) will be progressed through IESG
review and RFC Editor review in PDF format and also in ASCII format.
The ASCII format version may be limited to text only and not include
figures, diagrams, or equations.  The method to progress the PDF format
version is as specified in RFC2223bis
http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt: 

"When the .pdf version is submitted with the .txt version, the RFC
Editor will first edit the .txt version.  The final form of the .txt
version (or, when feasible, the diffs) will be returned to the author.
The author must then update the .pdf files to match, as closely as
possible, the content and format of the ASCII .txt file. When the RFC
Editor agrees that the .pdf version is acceptable, it is published
simultaneously with the .txt version."

The IESG (shepherded by Bill Fenner, Routing AD) has agreed to proceed
with the experiment.  

Please let us know of any comments or suggestions on the updated draft.

Thanks,
Jerry, Stewart, Yaakov 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 25, 2006 3:50 PM
To: i-d-announce@ietf.org
Subject: I-D ACTION:draft-ash-alt-formats-02.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


Title   : Proposed Experiment: Normative Format in
Addition to ASCII Text
Author(s)   : J. Ash, et al.
Filename: draft-ash-alt-formats-02.txt,.pdf
Pages   : 9
Date: 2006-5-25

Following RFC 3933, the authors propose an experiment allowing, in
   addition to ASCII text as a normative input/output format, PDF as an
   additional normative output format.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ash-alt-formats-02.txt

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

RE: LC on draft-mankin-pub-req-08.txt

2006-05-25 Thread Joel M. Halpern


I can live with that.
And I hope so can those who want to be restrictive as to what editing 
takes place.


Yours,
Joel

At 09:27 PM 5/25/2006, Stephen Hayes (TX/EUS) wrote:
After some consideration, I can understand how the current text in 
mankin-pub-req would be discouraging to the technical publisher.


If we changed "refrain from" to "exercise restraint in making" in 
requirements POSTEDIT-3 and POSTEDIT-4, I assume this would solve 
Joel and John's concerns.


The question now is if I will get shot from the "keep your grubby 
hands off my document" crowd.


Stephen



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

RE: LC on draft-mankin-pub-req-08.txt

2006-05-25 Thread John C Klensin

--On Thursday, 25 May, 2006 20:27 -0500 "Stephen Hayes (TX/EUS)"
<[EMAIL PROTECTED]> wrote:

> After some consideration, I can understand how the current
> text in mankin-pub-req would be discouraging to the technical
> publisher.
> 
> If we changed "refrain from" to "exercise restraint in making"
> in requirements POSTEDIT-3 and POSTEDIT-4, I assume this would
> solve Joel and John's concerns.

Yes, from my standpoint, that would be a very significant
improvement.

> The question now is if I will get shot from the "keep your
> grubby hands off my document" crowd.

One hopes not.  But that question is, of course, intimately
related to whether there is actually a plausible pre-approval
editing process (not just a suggestion process to editors, but
actual definitive editing).  If there is no such process, then,
for some very significant number of cases "keep your hands off
my document" would be equivalent to "publish ungrammatical,
badly-written and badly-organized trash".   And I don't think
anyone really wants that.

john

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

RE: The Emperor Has No Clothes: Is PANA actually useful?

> Just below you are acknowledging the need for EAP over IP. I don't
> understand how you can still claim you don't understand why PANA is
> useful... 

The framework doesn't seem to talk much about simple EAP over IP 
scenarios, so I have assumed this is not the major focus. 

> You are aware that "virtual open-access AP" mode is OK. One of the
> two alternatives we proposed had an issue, and the other one still holds.

Right.  I was referring only to the WPA/WPA2 scenarios. 

> De-facto? Could you please elaborate how it is becoming a de-facto standard?

EAP over UDP is one of the foundation technologies for Network Endpoint 
Assessment (NEA).  As I understand it, EAPoUDP is being made available on 
most operating systems, and is in the process of being deployed by many 
enterprise customers. 

> Besides. Of course PANA is more complex than EAPoUDP. The latter (an
> individual I-D) has very limited applicability.  

As I understand it, EAP over UDP is mostly being deployed for wired access 
scenarios where IEEE 802.1X might not work well (e.g. multiple hosts 
sharing a port).  

> Which SDOs? Please give us more detail.

As I understand it, 3GPP2 has considered PANA, and IEEE 802.11 has 
evaluated the PANA framework document. 

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

RE: The Emperor Has No Clothes: Is PANA actually useful?

Hi Bernard,

> -Original Message-
> From: Bernard Aboba [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 25, 2006 4:46 PM
> To: ietf@ietf.org
> Subject: Re: The Emperor Has No Clothes: Is PANA actually useful?
> 
> I have reviewed the PANA framework document, the PANA protocol spec, and
> the PANA/IPsec document. After reading all these documents, I still do
> not understand why PANA is useful.

Just below you are acknowledging the need for EAP over IP. I don't
understand how you can still claim you don't understand why PANA is
useful... 

> The PANA framework document claims that it can be used along with IEEE
> 802.11i.  However, IEEE 802.11 reviewed the document, and came to a
> different conclusion:
> http://www.drizzle.com/~aboba/IEEE/11-06-0577-01-ietf-liaison-response-
> IETF-PANA.doc

This is an inaccurate reading of the IEEE response (and you are the
liaison). You are aware that "virtual open-access AP" mode is OK. One of the
two alternatives we proposed had an issue, and the other one still holds.


> The other potential scenario outlined by the framework document is use
> along with IPsec.  However, IKEv2 already supports EAP authentication, so
> I don't understand why PANA would be used for that scenario instead of
> IKEv2.

You had commented on that earlier and I had explained it.
http://www1.ietf.org/mail-archive/web/pana/current/msg02234.html. If not
clear, please follow up from there (we don't need to go back to your
original question).

 
> I do understand the potential need for EAP to be encapsulated over IP.

Thank you. 

> However, in practice PANA is more complex than EAP over UDP
> (see draft-thomson-nacp-02.txt), which looks like it is on the road
> to becoming the defacto standard for EAP encapsulation over IP.

De-facto? Could you please elaborate how it is becoming a de-facto standard?


Besides. Of course PANA is more complex than EAPoUDP. The latter (an
individual I-D) has very limited applicability. If it were to handle
mobility and wireless, it'll also grow in complexity. Just to get some sense
of it, compare 802.1X and 802.11r.

> So from what I can tell, in each potential usage scenario PANA is
> either not feasible, is more complex than an established alternative,
> or has been rejected by the SDOs that have examined it.

Which SDOs? Please give us more detail.

Thank you.

Alper




> 
> ---
> Sam Hartman said:
> 
> Hi.  Speaking as an individual, I'd like to make an explicit call for
> members of the IETF community not involved in the PANA working group
> to review draft-ietf-pana-framework.  Please speak up if you have done
> such a review or attempted such a review and been unsuccessful.  Let
> us know what you think PANA is intended to be useful for and whether
> you think it is actually useful.
> 
> My strong hunch is that we've chartered work for some reason, and now
> that the working group is nearing the end of its charter, we still
> don't understand why we want this thing we've built and whether it's a
> good idea.  People aren't screaming not so much because they are happy
> with results but because no one actually understands PANA.
> 
> I understand that there's a strong presumption that once chartered,
> work is useful.  I'd like to challenge this presumption enough to get
> people to actually read the document.  If people not involved in the
> effort sit down, read the document and understand what it's all about,
> my concern is satisfied.  But if enough people try to read the
> document, try to understand and fail, we're not done yet.  We
> certainly cannot have consensus to publish something we've tried and
> failed to understand.
> 
> It's not just me.  I've been trying to find people outside of PANA who
> claim to understand the effort and what it's good for and why
> link-layer solutions are not better.  When the first discussion of
> PANA hit the IESG, I asked other IESG members why PANA was a good idea
> and what problem it solved.  "Don't go there," was the advice I got
> from the responsible AD.
> 
> At that time (a year and a half ago) there was no one on the IESG who
> claimed to understand PANA or to think it was a good idea.
> 
> I'm fairly sure that with the possible exception of Jari (who is a
> technical advisor to PANA), that's still true.
> 
> The security community has been trying to understand PANA.  I've sent
> multiple security reviewers at the PANA document.s They always come
> back fundamentally confused about what PANA is trying to do or about
> whether it is a good idea.  They end up focusing on some detail or
> another and asking for some minor part of the system to be fixed.  But
> I don't get the impression from the reviews they understand the
> overall picture; explicit discussion of this also indicates that they
> are not confident in their understanding nor do they know whether it
> is a good idea.
> 
> We keep running back over the same ground, still confus

RE: LC on draft-mankin-pub-req-08.txt

2006-05-25 Thread Stephen Hayes (TX/EUS)

After some consideration, I can understand how the current text in 
mankin-pub-req would be discouraging to the technical publisher.

If we changed "refrain from" to "exercise restraint in making" in requirements 
POSTEDIT-3 and POSTEDIT-4, I assume this would solve Joel and John's concerns.

The question now is if I will get shot from the "keep your grubby hands off my 
document" crowd.

Stephen

> -Original Message-
> From: Stephen Hayes (TX/EUS) [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 25, 2006 8:01 PM
> To: John C Klensin
> Cc: Joel M. Halpern; ietf@ietf.org
> Subject: RE: LC on draft-mankin-pub-req-08.txt
> 
> 
> John Klensin wrote:
> > Stephen, I routinely complain about too much editing -- if not
> > on every document I submit for RFC publication, at least most of
> > them.   I believe that, in the last couple of years there has
> > been a trend toward more editing that I consider gratuitous,
> > e.g., changing one correct and consistent style to another one.
> > So I may well be the source of some of the complaints you heard.
> > On the other hand, I'm appalled by the editorial and
> > presentation quality of some of the documents that I've seen go
> > to the RFC Editor, even after Last Call and IESG signoff.  
> > 
> > In my opinion, absent something that the document skirts, the
> > "current highly restrictive reading" goes much too far.  Yes, I
> > understand the desire to counterbalance both natural tendencies
> > and some history of over-editing.  But, to the extent to which
> > this document is expected, post-last-call, to form part of the
> > basis for solicitation of people who are interested in doing the
> > job and selection from among those people, and then of a
> > contract with the selected party, I believe it goes _much_ too
> > far: that degree of restrictiveness is simply not what we want
> > or need, IMO.
> 
> Do you have any suggested text?  What I am hearing is 
> something like be frugal in changes except when the document 
> needs it, which IMHO doesn't seem to help.
> 
> Stephen
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 

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

RE: LC on draft-mankin-pub-req-08.txt

2006-05-25 Thread Stephen Hayes (TX/EUS)

John Klensin wrote:
> Stephen, I routinely complain about too much editing -- if not
> on every document I submit for RFC publication, at least most of
> them.   I believe that, in the last couple of years there has
> been a trend toward more editing that I consider gratuitous,
> e.g., changing one correct and consistent style to another one.
> So I may well be the source of some of the complaints you heard.
> On the other hand, I'm appalled by the editorial and
> presentation quality of some of the documents that I've seen go
> to the RFC Editor, even after Last Call and IESG signoff.  
> 
> In my opinion, absent something that the document skirts, the
> "current highly restrictive reading" goes much too far.  Yes, I
> understand the desire to counterbalance both natural tendencies
> and some history of over-editing.  But, to the extent to which
> this document is expected, post-last-call, to form part of the
> basis for solicitation of people who are interested in doing the
> job and selection from among those people, and then of a
> contract with the selected party, I believe it goes _much_ too
> far: that degree of restrictiveness is simply not what we want
> or need, IMO.

Do you have any suggested text?  What I am hearing is something like be frugal 
in changes except when the document needs it, which IMHO doesn't seem to help.

Stephen

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

Re: Comments on draft-iab-rfc-editor: IETF control

2006-05-25 Thread Leslie Daigle

Howdy,

> I think though that the community ultimately needs to have the power
> to take back anything it has given.  Basically, I think it is critical
> that ultimately everything within the greater IETF context be
> accountable to the IETF community.  That is true of the IESG, the IAB
> and everything they do.
>
> I don't think this document represents that.

It is, at its heart, an -00 :-)  Let's work on trying to fix the
text before assuming the whole structure is wrong.

Let's set aside *which* community for a moment (IETF community
or something larger) and work on making sure the document
is clear where the IAB makes decisions versus where it facilitates
the detection of and action upon consensus. Can you propose
some text improvements?

Leslie.

Sam Hartman wrote:

"Leslie" == Leslie Daigle <[EMAIL PROTECTED]> writes:

Leslie> Sam,

Leslie> Some high-level responses, and I'm sure we'll hear other
Leslie> input:

Leslie> 1/ I think you're overlooking something in "IETF pays for
Leslie> RFC Editor"; RFC Editor has been paid by ISOC for years,
Leslie> and *that* largely comes out of contributions from
Leslie> corporations.  We actually have no data beyond the fact
Leslie> that they support the RFC Editor as currently constituted
Leslie> (i.e., including independent submissions).

Leslie> We've already heard (in IETF discussion in March) input
Leslie> that no in fact the IETF does not get to define the
Leslie> *in*dependent submission process; one purpose of the
Leslie> planned discussion is to ensure that the process is not at
Leslie> odds with the IETF's standards needs, but that is very
Leslie> different than having the IETF define it, as you describe.

OK. I was not paying that much attention in March,and if I'm too late,
I certainly have no problem with the community choosing to allow a
broader group to control the independent submission track, or to seed
that to the IAB.

I think though that the community ultimately needs to have the power
to take back anything it has given.  Basically, I think it is critical
that ultimately everything within the greater IETF context be
accountable to the IETF community.  That is true of the IESG, the IAB
and everything they do.

I don't think this document represents that.

--Sam

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

Re: Comments on draft-iab-rfc-editor: IETF control

2006-05-25 Thread Sam Hartman

> "Leslie" == Leslie Daigle <[EMAIL PROTECTED]> writes:

Leslie> Sam,

Leslie> Some high-level responses, and I'm sure we'll hear other
Leslie> input:

Leslie> 1/ I think you're overlooking something in "IETF pays for
Leslie> RFC Editor"; RFC Editor has been paid by ISOC for years,
Leslie> and *that* largely comes out of contributions from
Leslie> corporations.  We actually have no data beyond the fact
Leslie> that they support the RFC Editor as currently constituted
Leslie> (i.e., including independent submissions).

Leslie> We've already heard (in IETF discussion in March) input
Leslie> that no in fact the IETF does not get to define the
Leslie> *in*dependent submission process; one purpose of the
Leslie> planned discussion is to ensure that the process is not at
Leslie> odds with the IETF's standards needs, but that is very
Leslie> different than having the IETF define it, as you describe.



OK. I was not paying that much attention in March,and if I'm too late,
I certainly have no problem with the community choosing to allow a
broader group to control the independent submission track, or to seed
that to the IAB.

I think though that the community ultimately needs to have the power
to take back anything it has given.  Basically, I think it is critical
that ultimately everything within the greater IETF context be
accountable to the IETF community.  That is true of the IESG, the IAB
and everything they do.

I don't think this document represents that.

--Sam


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

Re: Comments on draft-iab-rfc-editor: IETF control

2006-05-25 Thread Leslie Daigle



Sam,

Some high-level responses, and I'm sure we'll hear other
input:

1/ I think you're overlooking something in "IETF pays for RFC
Editor"; RFC Editor has been paid by ISOC for years, and *that*
largely comes out of contributions from corporations.  We actually
have no data beyond the fact that they support the RFC Editor
as currently constituted (i.e., including independent submissions).

We've already heard (in IETF discussion in March) input that
no in fact the IETF does not get to define the *in*dependent
submission process; one purpose of the planned discussion is
to ensure that the process is not at odds with the IETF's
standards needs, but that is very different than having the
IETF define it, as you describe.

2/ Termination of any contract is always going to be based on
terms in said contract.  I assume ISOC BoT wouldn't approve
something that leaves them with dangerous exposure; that's
what they do.

This document is aiming to capture the principle of the
IAB's responsibility; the counter example is not
right, either (the IASA giving the IAB/IETF the news that
there is a new RFC Editor in town).

3/ Re. approval of ISOC BoT/IASA for creation of new streams:  we
need to be careful with terminology.  The IASA exists to implement
adminstrative support to meet the needs of the IETF & IAB & IRTFs
needs.

Leslie.

Sam Hartman wrote:


I finished reading the RFC editor document and have one major concern.

Ultimately, the rfc-editor function needs to be accountable to the
IETF community because we're the ones paying for it.


In particular I believe that the IETF should be able to pass a BCP
placing requirements on an rfc-editor stream.  We've done this with
RFC 3932 for example, and I think that was a good thing.

In effect, community consensus within the IETF should trump anything
else.


Now, we need to be careful about how to use that consensus.  Several
RFC streams serve communities broader than the IETF.  Unless we have
good reason to do so, we should not step on those communities by
overriding their requirements.

I also have specific concerns about how this document interacts with
the IAOC and IASA.

1) The document gives the IAB the authority to terminate the
rfc-editor contract.  Depending on when we do that, there may be
significant budget impacts and it may not be consistent with
ISOC's carrying out its financial responsibilities to terminate
the rfc-editor contract at an arbitrary point in time.

2) The document allows the IAB to create new streams of rfcs on its
   own authority.  It seems that we need ISOC and IAOC approval at
   least on the budget question to do so.

--Sam




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

Last Call: IETF Calendar 2008 - 2010 Ver 02

2006-05-25 Thread Ray Pelletier

This is a Last Call for feedback on Version 02 proposed 2008 - 2010 IETF 
Meeting dates. The IAOC anticipates taking action to formally adopt 
dates on 1 June. These dates differ from the version 01 dates based upon 
community feedback, a review of meeting dates of those organizations on 
the Clash List and maintenance of a reasonably similar period between 
meetings.


While every effort was made to avoid conflicts where known, it was not 
always possible with those organizations in the "should avoid" category 
and on many occasions the IETF meetings are back to back with the IEEE 
Plenaries. Future location decisions will take into consideration the 
location of other organization meetings with which the community 
interacts.  Your feedback to [EMAIL PROTECTED] on conflicts with these dates 
would be appreciated.


Proposed 2008 - 2010 meeting dates:

   2008
   IETF 71 Mar 23 - 28
   IETF 72 Jul 27 - Aug 1
   IETF 73 Nov 16 - 21

   2009
   IETF 74 Mar 22 - 27
   IETF 75 Jul 26 - 31
   IETF 76 Nov 8 - 13

   2010
   IETF 77 Mar 21 - 26
   IETF 78 Jul 25 - 30
   IETF 79 Nov 7 - 12

The schedules of other organization's meetings as known can be found at: 
http://www.ietf.org/meetings/events.cal.html. 
Thanks for your continuing assistance.


Ray Pelletier
IAD

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

Re: The Emperor Has No Clothes: Is PANA actually useful?

I have reviewed the PANA framework document, the PANA protocol spec, and 
the PANA/IPsec document. After reading all these documents, I still do 
not understand why PANA is useful.

The PANA framework document claims that it can be used along with IEEE 
802.11i.  However, IEEE 802.11 reviewed the document, and came to a 
different conclusion:
http://www.drizzle.com/~aboba/IEEE/11-06-0577-01-ietf-liaison-response-IETF-PANA.doc

The other potential scenario outlined by the framework document is use 
along with IPsec.  However, IKEv2 already supports EAP authentication, so 
I don't understand why PANA would be used for that scenario instead of 
IKEv2. 

I do understand the potential need for EAP to be encapsulated over IP.  
However, in practice PANA is more complex than EAP over UDP 
(see draft-thomson-nacp-02.txt), which looks like it is on the road 
to becoming the defacto standard for EAP encapsulation over IP. 

So from what I can tell, in each potential usage scenario PANA is 
either not feasible, is more complex than an established alternative, 
or has been rejected by the SDOs that have examined it.

---
Sam Hartman said:

Hi.  Speaking as an individual, I'd like to make an explicit call for
members of the IETF community not involved in the PANA working group
to review draft-ietf-pana-framework.  Please speak up if you have done
such a review or attempted such a review and been unsuccessful.  Let
us know what you think PANA is intended to be useful for and whether
you think it is actually useful.

My strong hunch is that we've chartered work for some reason, and now
that the working group is nearing the end of its charter, we still
don't understand why we want this thing we've built and whether it's a
good idea.  People aren't screaming not so much because they are happy
with results but because no one actually understands PANA.

I understand that there's a strong presumption that once chartered,
work is useful.  I'd like to challenge this presumption enough to get
people to actually read the document.  If people not involved in the
effort sit down, read the document and understand what it's all about,
my concern is satisfied.  But if enough people try to read the
document, try to understand and fail, we're not done yet.  We
certainly cannot have consensus to publish something we've tried and
failed to understand.

It's not just me.  I've been trying to find people outside of PANA who
claim to understand the effort and what it's good for and why
link-layer solutions are not better.  When the first discussion of
PANA hit the IESG, I asked other IESG members why PANA was a good idea
and what problem it solved.  "Don't go there," was the advice I got
from the responsible AD.

At that time (a year and a half ago) there was no one on the IESG who
claimed to understand PANA or to think it was a good idea.

I'm fairly sure that with the possible exception of Jari (who is a
technical advisor to PANA), that's still true.

The security community has been trying to understand PANA.  I've sent
multiple security reviewers at the PANA document.s They always come
back fundamentally confused about what PANA is trying to do or about
whether it is a good idea.  They end up focusing on some detail or
another and asking for some minor part of the system to be fixed.  But
I don't get the impression from the reviews they understand the
overall picture; explicit discussion of this also indicates that they
are not confident in their understanding nor do they know whether it
is a good idea.

We keep running back over the same ground, still confused and still
trying to muddle through to no real effect.

I've tried to understand it myself.  I tried to understand in the BOF.
It was very clear to me leaving the original PANA BOF that something
was very confused.  Every year or so since I've tried to go back and
figure out what I missed.  Eventually though I've started wondering
whether the problem wasn't me, but was an actual lack of clarity.

So, folks can you please help us all out.  Especially if the internet
area is not your primary focus, especially if you've never heard of
PANA before, take a look at the framework document and all their other
documents.  Do you get it?  Is it a good idea?

Thanks for your time.

P.S.  Again, this is me speaking as an individual.  At this late
stage, it would be entirely inappropriate for me to take actions as an
AD claiming that we didn't understand a problem without a strong
community consensus.

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

Re: The Emperor Has No Clothes: Is PANA actually useful?

2006-05-25 Thread Lakshminath Dondeti


At 05:07 PM 5/24/2006, Vijay Devarapallli wrote:
On 5/24/06, Lakshminath Dondeti <[EMAIL PROTECTED]> wrote: > ** 
EAP over IKEv2 seems like a more viable alternative: apparently > 
being proposed in 3G-WLAN interworking scenario as the access auth 
protocol. the 3G-WLAN interworking scenario is similar to an 
enterprise user gaining access to the enterprise via an IPsec 
gateway. a user who is subscribed to a mobile operator's services 
uses IKEv2 with a VPN-like gateway to access the operator's 
services. the mode is different. therefore I don't think this is an 
alternative to PANA and shouldn't be confused with PANA. we could 
discuss this more, but on a separate thread. Vijay 


Hi,

I guess there are differences in our understanding of 3G-WLAN 
interworking (and I could be wrong), but the point is that they (plan 
to) use EAP over IKEv2.  We can try and debate the details offline, 
as that is not central to the discussion here.


regards,
Lakshminath 



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

Comments on draft-iab-rfc-editor: IETF control

2006-05-25 Thread Sam Hartman



I finished reading the RFC editor document and have one major concern.

Ultimately, the rfc-editor function needs to be accountable to the
IETF community because we're the ones paying for it.


In particular I believe that the IETF should be able to pass a BCP
placing requirements on an rfc-editor stream.  We've done this with
RFC 3932 for example, and I think that was a good thing.

In effect, community consensus within the IETF should trump anything
else.


Now, we need to be careful about how to use that consensus.  Several
RFC streams serve communities broader than the IETF.  Unless we have
good reason to do so, we should not step on those communities by
overriding their requirements.

I also have specific concerns about how this document interacts with
the IAOC and IASA.

1) The document gives the IAB the authority to terminate the
rfc-editor contract.  Depending on when we do that, there may be
significant budget impacts and it may not be consistent with
ISOC's carrying out its financial responsibilities to terminate
the rfc-editor contract at an arbitrary point in time.

2) The document allows the IAB to create new streams of rfcs on its
   own authority.  It seems that we need ISOC and IAOC approval at
   least on the budget question to do so.

--Sam


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

Re: [Techspec] RFC Author Count and IPR

2006-05-25 Thread Lucy E. Lynch


On Thu, 25 May 2006, [EMAIL PROTECTED] wrote:


On Thu, May 25, 2006 at 06:42:06AM -0700, Lucy E. Lynch wrote:

On Thu, 25 May 2006, Harald Alvestrand wrote:


Lucy E. Lynch wrote:

Let me try re-stating my question. Is there a one-to-one relationship
between the listed authors on an IETF document and ownership of the
given document's Intellectual Property?

I can answer that one...

No.



Thank you!

Lucy E. Lynch   Academic User Services


not knowing Harolds legal background or current standing w/
the ABA, (or EU equivalent) I think that Bob's recommendation
on getting actual legal advice on your question puts you and
the organziation represented (IETF) on much better grounding
than a simple; "I can answer that... no" on an email list.

just my (uninformed) opinion.


Bill -

Understood, as I say, I'm just trying to get a handle the range of 
community opinion(s) and the scope of the problem. This issue

cuts across TechSpec, the IPR WG, the RFC-Editor's office, and
the IETF Trust (as well as individual authors etc.). Everyone sees 
this slightly differently. Before we ask for advise, I'd like to 
understand the problem set.



--bill



--
Lucy E. Lynch   Academic User Services
Computing CenterUniversity of Oregon
llynch  @darkwing.uoregon.edu   (541) 346-1774

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

Re: [Techspec] RFC Author Count and IPR

2006-05-25 Thread John C Klensin

(several  lists deleted)

--On Thursday, 25 May, 2006 10:44 +0200 Harald Alvestrand
<[EMAIL PROTECTED]> wrote:

> The Last Call on draft-rfc-editor-author-lists was issued on
> May 20, 2002, and the IESG approved that document on August
> 27, 2002, according to the tracker:
> 
> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
> w_id&dTag=8778&rfc_flag=0
> 
> On Jan 3, 2005, it was marked "dead" based on the fact that
> the text had been incorporated into the 2223bis draft.
> So it's been almost 4 years since IETF consensus was declared
> for this policy.

Since, as I understand it, completion and publication of 2223bis
has been put on indefinite hold, is it time to dust off
draft-rfc-editor-author-lists and publish it?

Also, since we have a last call on the IPOD/ION draft in effect,
could you, Harald, walk us quickly through how you would see
this situation being untangled, or handled in a more clear way,
were the ION series in effect?  Would the content of
draft-rfc-editor-author-lists fall into that series?  Would
2223bis?

 john

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

RE: LC on draft-mankin-pub-req-08.txt

2006-05-25 Thread John C Klensin

--On Thursday, 25 May, 2006 07:18 -0500 "Stephen Hayes (TX/EUS)"
<[EMAIL PROTECTED]> wrote:

> See inline.
> 
> Stephen Hayes
> 
>> -Original Message-
>> From: Joel M. Halpern [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, May 24, 2006 3:17 PM
>> To: ietf@ietf.org
>> Subject: Re: LC on draft-mankin-pub-req-08.txt
>...
> Although the wording could be tuned to be more permissive,
> it's not possible to satisfy everybody with the POSTEDIT
> requirements.  People just tend to end up at slightly
> different places along the "how much the technical publisher
> should do" curve.  People can point to examples with badly
> written documents that needed considerable clean-up or
> examples where changes were done that added little overall
> benefit to a document.
> 
> The natural tendency of a technical publisher will be to
> improve documents, since to a large degree they view
> themselves as responsible for the output quality.  The current
> highly restrictive wording was selected to counterbalance that
> tendency.  The current wording also reflects that I heard more
> complaints about too much editing than not enough editing.

Stephen, I routinely complain about too much editing -- if not
on every document I submit for RFC publication, at least most of
them.   I believe that, in the last couple of years there has
been a trend toward more editing that I consider gratuitous,
e.g., changing one correct and consistent style to another one.
So I may well be the source of some of the complaints you heard.
On the other hand, I'm appalled by the editorial and
presentation quality of some of the documents that I've seen go
to the RFC Editor, even after Last Call and IESG signoff.  

In my opinion, absent something that the document skirts, the
"current highly restrictive reading" goes much too far.  Yes, I
understand the desire to counterbalance both natural tendencies
and some history of over-editing.  But, to the extent to which
this document is expected, post-last-call, to form part of the
basis for solicitation of people who are interested in doing the
job and selection from among those people, and then of a
contract with the selected party, I believe it goes _much_ too
far: that degree of restrictiveness is simply not what we want
or need, IMO.

The exception case mentioned above would involve a shift to
doing substantially all editing prior to IETF Last Call and
doing it again if textual changes are made after Last Call, so
that the document that is approved is the document that is
published.  That is more or less the practice in a number of
other standards bodies.  For reasons of both cost and process,
it has never been embraced here and I don't take anything in
TechSpec as either forcing that model or as otherwise assuring
that documents that come into the process are of a quality that
would justify very restrictive text about post-editing.

regards,
 john

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

Re: [Techspec] RFC Author Count and IPR

2006-05-25 Thread todd glassey

L2,
The IETF's policy here has a couple of problems I think - and that is that
it limits the number of parties that can claim control over a document and
in doing so limits the representation of legal ownership or rights to the
filing.

This is a very bad thing, since each of those authors has legal control over
their portions of the work or derivatives of their contribution within the
work itself. I.e. they are all legal signatories to any conveyance of
copyrights or derivative use rights including implementaiton rights.

It also seems to limit who can converse with the Secretariat or WG in regard
to the management of any particular Document's Initiative which may prevent
legitimate IP owners from interacting with the IETF's processes.

Perhaps we need to apply the same standards to these that are applied to US
Patents, and BTW did you know that a person licensing someone to use a
patent can revoke that license for cause 20 years later...  that is an
important statement since it means that anything can be pulled out from
under anyone these days. The use of the IP for reprinting is Copyright
controlled - but the implementation of actual code or a 'system from the
description' is more specific to patent protection and should be dealt with
as such since it is not 'republication' but commercial/private use of the
described IP that is being dealt with.

The point is that the IP Control and Transfer model is to complex and needs
to be made simpler if the Trust idea is to work at all IMHO. For instance,
you have a piece of IP that is patented and there are four listed
Inventor's - that has very specific rights attached to it and it generally
similar if not the same for Author's of copyrighted works. And for this
example say one of those Four Inventor's is dissatisfied with a buy-out or
other matter and decides to rescind the transfer of the IP... there are of
course legal issues and processes to be addressed, but it does happen.

The point is that in any IP licensing model its critical to get continuing
agreement as to the intent and willingness of the AUTHORS/INVENTORS to
continue participating and that means that there needs to be an ongoing
process for getting that formal release. Say a RFC for instance was derived
from a document that had four authors and one of them decided to leave the
Vetting Team that submitted the document (notice also I snuck a new
Governance term in - "Vetting Team")... Now when each revision to that I-D
that is done the same four people would have to agree to the ongoing license
to use, which the one who left can clearly say no to... What does this
cause? nothing inside the IETF since its use rights are protected by the
Research Exemptions but anyone else? could be messy.

Todd

- Original Message - 
From: "Lucy E. Lynch" <[EMAIL PROTECTED]>
To: "Harald Alvestrand" <[EMAIL PROTECTED]>
Cc: ; "Bob Braden" <[EMAIL PROTECTED]>; ;
; 
Sent: Thursday, May 25, 2006 6:42 AM
Subject: Re: [Techspec] RFC Author Count and IPR

> On Thu, 25 May 2006, Harald Alvestrand wrote:
>
> > Lucy E. Lynch wrote:
> >> Let me try re-stating my question. Is there a one-to-one relationship
> >> between the listed authors on an IETF document and ownership of the
> >> given document's Intellectual Property?
> > I can answer that one...
> >
> > No.
>
>
> Thank you!
>
> -- 
> Lucy E. Lynch Academic User Services
> Computing Center University of Oregon
> llynch  @darkwing.uoregon.edu (541) 346-1774
>
> ___
> Ipr-wg mailing list
> Ipr-wg@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipr-wg

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

Re: [Techspec] RFC Author Count and IPR

2006-05-25 Thread Lucy E. Lynch


On Thu, 25 May 2006, Harald Alvestrand wrote:


Lucy E. Lynch wrote:
Let me try re-stating my question. Is there a one-to-one relationship 
between the listed authors on an IETF document and ownership of the
given document's Intellectual Property? 

I can answer that one...

No.



Thank you!

--
Lucy E. Lynch   Academic User Services
Computing CenterUniversity of Oregon
llynch  @darkwing.uoregon.edu   (541) 346-1774

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

'help'

2006-05-25 Thread Sheikh, Usman Fakhar $UMKC-Student$

the IESG, but I am not sure), but it was left to the RFC Editor to
> formulate the precise guideline.
The Last Call on draft-rfc-editor-author-lists was issued on May 20,
2002, and the IESG approved that document on August 27, 2002, according
to the tracker:

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=8778&rfc_flag=0

On Jan 3, 2005, it was marked "dead" based on the fact that the text had
been incorporated into the 2223bis draft.
So it's been almost 4 years since IETF consensus was declared for this
policy.

   Harald

--

Message: 5
Date: Thu, 25 May 2006 10:46:23 +0200
From: Harald Alvestrand <[EMAIL PROTECTED]>
Subject: Re: [Techspec] RFC Author Count and IPR
To: "Lucy E. Lynch" <[EMAIL PROTECTED]>
Cc: ipr-wg@ietf.org, Bob Braden <[EMAIL PROTECTED]>, ietf@ietf.org,
techspec@ietf.org, rfc-editor@rfc-editor.org
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Lucy E. Lynch wrote:
> Let me try re-stating my question. Is there a one-to-one relationship
> between the listed authors on an IETF document and ownership of the
> given document's Intellectual Property?
I can answer that one...

No.

--

Message: 6
Date: Thu, 25 May 2006 10:54:33 +0200
From: Harald Alvestrand <[EMAIL PROTECTED]>
Subject: Re: I-D ACTION:draft-alvestrand-ipod-01.txt
To: John C Klensin <[EMAIL PROTECTED]>
Cc: ietf@ietf.org
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Note:

The IPOD draft says that these notes can be approved by multiple
entities - I did not see any reason to insist that the mechanism impose
a further burden on the IESG for *every* document that needs to be
issued in the course of IETF operations.

So the reason for the "IETF" in "IETF Operational Notes" is "related to
the IETF", not "approved by the IETF".

Much like the way "Internet Engineering Task Force" is related to the
Internet, not approved by the Internet..

   Harald

--

Message: 7
Date: Thu, 25 May 2006 13:43:12 +0530
From: "Raju Sutar" <[EMAIL PROTECTED]>
Subject: Call for Entries, Deadline 15th June 2006
To: ietf@ietf.org
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"

*Call for Entries

*

After the major success of 'Young ART' 2005 and 'Project Calendar' 2006,
artExperiments.com is presenting a series of five international curated
exhibition

*'Expressions in miniature size' *is first to start from the series.

'Expressions in miniature size'* *is an inaugural annual event, from the
series of international curated exhibitions by artEperiments.com in
association with Waves Art Gallery.

Expression can never be judged by the scale, but by its depth and intensity.
Art in miniature size is like the Japanese 'Haiku' where the saturation is
at optimum of ones expression, and is sometimes has a lasting impact.

We intend to call entries from the artists all over the world, and at least
20 entries will be selected by artist/curator Raju Sutar for a physical as
well as online exhibition, along with a catalogue to be printed of the
select exhibits.

In case of more selections the exhibition will be held in sequence like 'I &
II'

Waves Art Gallery is located in Pune (INDIA), a city that is known to be the
city of knowledge and culture.

Our endeavor is to bring out the best possible works of art, to understand
the growth of the contemporary art.

*Eligibility*

Any artist from any country can participate, provided:

   - Art works falling under the category of painting, graphic, drawing,
   collage etc. except photography, installation and sculpture.

   - Size not more than 30 X 30 cms inclusive of frame.

Note: Processing fees INR 100/- or $ 2.5 per application (up to three
images)

Please submit your entries at
*www.artexperiments.com*
 online!

Deadline 15th June 2006.
-- next part --
An HTML attachment was scrubbed...
URL: 
http://www1.ietf.org/pipermail/ietf/attachments/20060525/0e9ac6d5/attachment.html

--

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

End of Ietf Digest, Vol 25, Issue 34

<>___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: LC on draft-mankin-pub-req-08.txt

2006-05-25 Thread Stephen Hayes (TX/EUS)

See inline.

Stephen Hayes

> -Original Message-
> From: Joel M. Halpern [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 24, 2006 3:17 PM
> To: ietf@ietf.org
> Subject: Re: LC on draft-mankin-pub-req-08.txt
> 
> 
> Reading this, a few items caught my eye.
> 
> The POSTEDIT requirements seem to be worded as if it is desirable to 
> minimize the changes that the document editor makes, or even the 
> changes the document editor can make.  The general tone of "don't 
> mess with the words we have carefully honed" is 
> understandable.  However, in practice many of the words have not been 
> carefully honed.  And they need to be.  For example, there is a 
> document I just reviewed to which my personal reaction is "this needs 
> massive editing."  It is not technically wrong.  But the language use 
> makes it hard for the reader to understand what is intended.  I would 
> sincerely hope that if it is approved as-is by the IESG that the RFC 
> Editor would edit the document.
> In general the editor has little or no way to tell which words are 
> "carefully crafted."  I would hate to have a presumption that all the 
> words a sacrosanct.
> I realize that the text calls out the special case of "don't touch a 
> letter of this", and even acknowledges that it is a rare case.  But 
> the wording of the earlier text is not in line with 
> that.  Specifically, POSTEDIT-4 reads "The IETF Technical editor 
> should refrain from changes to improve readability that may change 
> technical and consensus wording."  This appears to be a directive 
> that prohibits almost all changes, since in a formal sense all the 
> words in an WG and IETF LC approved document are "consensus 
> wording."  That leads to what I consider a bad situation where we 
> have essentially prohibited the editor from editing.
> 
> On a related note, POSTEDIT-3 seems to be inadvertently worded too 
> strongly.  It prohibits changes which "introduce a substantial review 
> load but only provides incremental increase in the clarity of the 
> specification."  However, by definition any change at all, even a 
> significant change that transforms a document from unintelligible to 
> highly readable, is always an "incremental increase in the clarity of 
> the specification."
>

Although the wording could be tuned to be more permissive, it's not possible to 
satisfy everybody with the POSTEDIT requirements.  People just tend to end up 
at slightly different places along the "how much the technical publisher should 
do" curve.  People can point to examples with badly written documents that 
needed considerable clean-up or examples where changes were done that added 
little overall benefit to a document.

The natural tendency of a technical publisher will be to improve documents, 
since to a large degree they view themselves as responsible for the output 
quality.  The current highly restrictive wording was selected to counterbalance 
that tendency.  The current wording also reflects that I heard more complaints 
about too much editing than not enough editing.

> With regard to the metrics, I think that it would be helpful to 
> separate the notion of having metrics from the specific values.  I 
> would suggest moving the specific values to an appendix, with a 
> notation that these values are advisory and based on IETF perception 
> at the time of writing.  I don't want to lose the numbers, but I 
> think that they have a different status as requirements than the 
> point that these time frames should be tracked, and should have well 
> understood targets.  Separating this also allows for negotiation of 
> cost-benefit tradeoffs without violating "requirements."
> 
I agree, the requirements to keep metrics and the recommended values for 
metrics are different and should be distinguished in some way.  I am not sure 
an appendix is the best way, but some separation is needed.
> 
> As a minor matter, figure one is trying to make a useful statement, 
> but one of the headings caused me to have to spend more time staring 
> at the figure, rather than making things clearer.  In the row labeled 
> "Actors", WGLC and IETF LC appear.  Those are states, not 
> actors.  Also, the action listed (Formal Reviewing) does not, as far 
> as I know, currently occur during those phases.  The formal reviewing 
> occurs after IETF LC ends, during IESG deliberations.

I guess some minor surgery would be to change WGLC->WG, IETF LC-> IETF, and 
Formal Reviewing-> Reviewing.
> 
> Yours,
> Joel M. Halpern
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 

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

Re: LC on draft-mankin-pub-req-08.txt

2006-05-25 Thread Joel M. Halpern


Reading this, a few items caught my eye.

The POSTEDIT requirements seem to be worded as if it is desirable to 
minimize the changes that the document editor makes, or even the 
changes the document editor can make.  The general tone of "don't 
mess with the words we have carefully honed" is 
understandable.  However, in practice many of the words have not been 
carefully honed.  And they need to be.  For example, there is a 
document I just reviewed to which my personal reaction is "this needs 
massive editing."  It is not technically wrong.  But the language use 
makes it hard for the reader to understand what is intended.  I would 
sincerely hope that if it is approved as-is by the IESG that the RFC 
Editor would edit the document.
In general the editor has little or no way to tell which words are 
"carefully crafted."  I would hate to have a presumption that all the 
words a sacrosanct.
I realize that the text calls out the special case of "don't touch a 
letter of this", and even acknowledges that it is a rare case.  But 
the wording of the earlier text is not in line with 
that.  Specifically, POSTEDIT-4 reads "The IETF Technical editor 
should refrain from changes to improve readability that may change 
technical and consensus wording."  This appears to be a directive 
that prohibits almost all changes, since in a formal sense all the 
words in an WG and IETF LC approved document are "consensus 
wording."  That leads to what I consider a bad situation where we 
have essentially prohibited the editor from editing.


On a related note, POSTEDIT-3 seems to be inadvertently worded too 
strongly.  It prohibits changes which "introduce a substantial review 
load but only provides incremental increase in the clarity of the 
specification."  However, by definition any change at all, even a 
significant change that transforms a document from unintelligible to 
highly readable, is always an "incremental increase in the clarity of 
the specification."


With regard to the metrics, I think that it would be helpful to 
separate the notion of having metrics from the specific values.  I 
would suggest moving the specific values to an appendix, with a 
notation that these values are advisory and based on IETF perception 
at the time of writing.  I don't want to lose the numbers, but I 
think that they have a different status as requirements than the 
point that these time frames should be tracked, and should have well 
understood targets.  Separating this also allows for negotiation of 
cost-benefit tradeoffs without violating "requirements."



As a minor matter, figure one is trying to make a useful statement, 
but one of the headings caused me to have to spend more time staring 
at the figure, rather than making things clearer.  In the row labeled 
"Actors", WGLC and IETF LC appear.  Those are states, not 
actors.  Also, the action listed (Formal Reviewing) does not, as far 
as I know, currently occur during those phases.  The formal reviewing 
occurs after IETF LC ends, during IESG deliberations.


Yours,
Joel M. Halpern


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

Call for Entries, Deadline 15th June 2006

2006-05-25 Thread Raju Sutar

Call for Entries
After the major success of 'Young ART' 2005 and 'Project Calendar' 2006, artExperiments.com is presenting a series of five international curated exhibition

'Expressions in miniature size'
is first to start from the series.'Expressions in miniature size'
is an inaugural annual event, from the series of international curated exhibitions by artEperiments.com
in association with Waves Art Gallery.

_expression_ can never be judged by the scale, but by its depth and intensity. Art in miniature size is like the Japanese 'Haiku' where the saturation is at optimum of ones _expression_, and is sometimes has a lasting impact.

We intend to call entries from the artists all over the world, and at least 20 entries will be selected by artist/curator Raju Sutar for a physical as well as online exhibition, along with a catalogue to be printed of the select exhibits.

In case of more selections the exhibition will be held in sequence like 'I & II'

Waves Art Gallery is located in Pune (INDIA), a city that is known to be the city of knowledge and culture.

Our endeavor is to bring out the best possible works of art, to understand the growth of the contemporary art.

Eligibility

Any artist from any country can participate, provided:

Art works falling under the category of painting, graphic, drawing, collage etc. except photography, installation and sculpture.

Size not more than 30 X 30 cms inclusive of frame.

Note: Processing fees INR 100/- or $ 2.5 per application (up to three images)

Please submit your entries at
www.artexperiments.com online!

Deadline 15th June 2006.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: I-D ACTION:draft-alvestrand-ipod-01.txt


Note:

The IPOD draft says that these notes can be approved by multiple 
entities - I did not see any reason to insist that the mechanism impose 
a further burden on the IESG for *every* document that needs to be 
issued in the course of IETF operations.


So the reason for the "IETF" in "IETF Operational Notes" is "related to 
the IETF", not "approved by the IETF".


Much like the way "Internet Engineering Task Force" is related to the 
Internet, not approved by the Internet..


  Harald


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

Re: [Techspec] RFC Author Count and IPR


Lucy E. Lynch wrote:
Let me try re-stating my question. Is there a one-to-one relationship 
between the listed authors on an IETF document and ownership of the
given document's Intellectual Property? 

I can answer that one...

No.


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

Re: [Techspec] RFC Author Count and IPR


Bob Braden wrote:
  *> 
  *> I am concerned that the current RFC Editor practice that limits the 
  *> number of authors is in conflict with the IETF IPR policies.  The RFC 
  *> Editor currently limits the author count to five people.  Recent IPR 
  *> WG discussions make it clear to me that authors retain significant copyright.



Note that the number 5 is not magic here.  When the phenomenon of
balooning lists of authors (say, one or more from every telecom vendor
you ever heard of) was first noticed, there was a discussion on the
IETF list.  The community consensus was that author list inflation was
"un-IETF".  I don't recall the details (there may have been a last call
from the IESG, but I am not sure), but it was left to the RFC Editor to
formulate the precise guideline.
The Last Call on draft-rfc-editor-author-lists was issued on May 20, 
2002, and the IESG approved that document on August 27, 2002, according 
to the tracker:


https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=8778&rfc_flag=0

On Jan 3, 2005, it was marked "dead" based on the fact that the text had 
been incorporated into the 2223bis draft.
So it's been almost 4 years since IETF consensus was declared for this 
policy.


  Harald


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

Tracking IPR (Re: RFC Author Count and IPR)


Just one note on this long thread:

At present, the IETF secretariat does *not* attempt to track who has 
copyright rights on what parts of the text.
Neither, as far as I know, does anyone else (WG chair or editors), apart 
from following the RFC 2026 rule that "significant contributions should 
be acknowledged" - this is commonly done by Authors, Contributors and 
Acknowledgement sections, which rarely point to specific pieces of text.


Claiming that we track copyrights on pieces of text, and then not doing 
it, would, in my opinion, be extremely stupid for multiple reasons.


So I want to make it perfectly clear that the IETF is NOT doing this.

  Harald


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

RE: The Emperor Has No Clothes: Is PANA actually useful?