Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Olaf Kolkman]

On Sep 8, 2009, at 6:09 PM, Sam Hartman wrote:


Tim, I definitely agree with you that it should be the IETF community
that is last called.
Normally, the IESG judges IETF consensus.
However, if it makes the IAB more comfortable for the IAB chair to  
do the

consensus call, that's fine with me.  If we do that we'd need to make
it clear how this interacts with the IETF appeals process.




Sam,

the underlying point of my question is that the streams are  
independent and that the IETF (stream) has no say about the other  
streams. IETF consensus or not. I am not even sure the IAB has a roll  
in calling the consensus.


But there is a nugget in the introduction of a last call: I think that  
the ISE has a very hard time explaining to the RSE that a note that  
has backing of IESG consensus will not be published. (I am assuming  
the use of the appeal procedure as described in RFC5620, which I think  
is appropriate for a difference of opinion between RFC entities such  
as the ISE and the IESG). If in such conflict the RSE would choose  
sides of the ISE then I am pretty sure something is severely broken  
and the appearance of a note is the least of our problems.


So in other words what I am saying is don't invent process but follow  
existing pieces:


- put a note in front of the ISE
o if the ISE pushes back
- last call the note in the IETF, to make sure the IESG actually  
represents IETF consensus --whereby the consensus is called by the  
IESG following normal process and appeal--, and go back to the ISE  
telling that the note has IETF backing.

o if the ISE pushes back
- consider this a disagreement between stream entities and follow RFC  
5620 appeal process.
o if the RSE chooses sides with the ISE the note gets published but  
the IAB, the IESG, and the RSE have some serious talking to do because  
something is severely broken elsewhere than just the note. The RFC  
will most probably be published without the note but the IESG has the  
possibility to publish a "This RFC sucks for this reason RFC" while  
the real problems are being addressed


Obviously publication of the document should be delayed on request  
from the IESG while the above is sorted out in a timely manner.


-- Olaf 








Olaf M. KolkmanNLnet Labs
   Science Park 140,
http://www.nlnetlabs.nl/   1098 XG Amsterdam



PGP.sig
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Hiroshima room rates (was Re: Non-smoking rooms at the Hiroshima venue?)

[Dean Willis]

On Sep 4, 2009, at 7:47 AM, Andrew Sullivan wrote:


On Fri, Sep 04, 2009 at 07:43:15AM -0400, Lou Berger wrote:

Yes.  I checked Sept 14-18.  Try it yourself, I expect you'll get the
same results...


I don't understand why the rate during another period is relevant to
the rate we might get.  Remember that hotels, like everyone else,
charge more when demand is higher.



It's a fair guide as to whether or not the hotel (perhaps with the  
collusion of the meeting organizers) is putting the thumbscrews to us.


For example, if the IETF attendee room rate is higher than the average  
rate for the hotel, we might be getting taking advantage of. If it's  
higher than the recorded maximum general-availability rate, then we  
almost definitely have a problem. If the IETF attendee rate is higher  
than the general-availability rate for the same time period, then  
we're absolutely positively being abused.


I don't know about you, but when I book a thousand rooms from a hotel  
(giving them a million dollars revenue), plus spend a half-million  
dollars  or more on meeting rooms over a week, I expect the hotel to  
be fairly generous about guest rooms. And when I've paid $700 or so  
for a meeting fee, I don't expect the organizer to pad their budget by  
having the hotel overcharge me on those rooms.


--
Dean

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

Re: Last Call: draft-ietf-l3vpn-2547bis-mcast (Multicast in MPLS/BGP IP VPNs) to Proposed Standard

[Pekka Savola]

On Tue, 25 Aug 2009, The IESG wrote:

The IESG has received a request from the Layer 3 Virtual Private Networks
WG (l3vpn) to consider the following document:

- 'Multicast in MPLS/BGP IP VPNs '
   as a Proposed Standard


This is an assigned ops-dir review.  I'm familiar with multicast, PIM and
routing, but not intimate with L3VPNs, so bear with me.  I only did a
superficial review, not looking very deep into the details of the spec.

As a high-level comment I'd say that this is more of a framework 
document than an actual specification.  The reason is that for almost 
every feature, the spec has 2-4 different mechanisms for achieving it. 
Most of these are usually non-interoperable.  This is less useful than 
a homogenous spec, but I believe the horse has already left the barn 
and now it's up to the vendors to implement everything and the 
operators to decide what they need to use in order to get the results 
needed.


From the operational perspective, there are a lot of options, policy 
and configuration.  This can be good and flexible, but it has the 
drawback that configuration is complex, and the service will often be 
misconfigured, with few if any means to detect misconfigurations. 
Many mechanisms also require the service provider to know the traffic 
patterns of their customers (i.e., which groups should use which 
traffic pattern/multicast routing optimizations).  This is a challenge 
and a lot of work.  In some places of the spec it is also not clear 
whether it's the operator or implementor which must do X (e.g., ensure 
that all the required BGP attributes are included in signalling in 
various scenarios and cases).  Some of the configurables are listed 
below as an example:


 - various signalling mechanisms (BGP, PIM, RSVP-TE, mLDP, ...)
 - various PMSI interfaces used and provided (which groups, MVPNs use which
   technologies), e.g. the policy scenarios described in S 7.
 - correct configuration of various BGP attributes
 - configuration of aggregation tree (sharing P-multicast trees across
   MVPNs) [e.g. S 6.3.2: "This will allow a SP to
   deploy aggregation depending on the MVPN membership and traffic
   profiles in its network."]
 - RP addresses of each C-multicast trees, unless automatically learned with
   BSR or auto-rp (note that BCP in this field is to use manual config)
 - whether explicit tracking is enabled (on per-flow basis)
 - PHP configuration for PMSI LSPs must be disabled (S 12.1.3)

Some of bigger issues noted are below:

1) IPv6 support.  The spec apparently aims to support both IPv4 and IPv6
   because it refers to both in a couple of places.  Yet, there is at
   least one explicit place in the spec (S 7.4.2.2) that's not compatible.
   I suspect many of the BGP attributes used, possibly also the MCAST-VPN
   BGP SAFI and others are not IPv6 compatible.  At the minimum, the status
   (intent) of the spec should be clarified. Even better would be to
   improve and include the support here.

2) RP configuration in SP network.  It's not clear if SP network needs to
   know how customer sites have configured their RPs (when the customer
   provides the RP).  At least traditional PIM signalling would require SP
   to know this.  But if auto-rp or BSR is not used by the customer, how is
   this information learned and maintained?  Would it require manual
   configuration?

3) S 3.4.1.2 and 3.4.1.3 describe "Lightweight PIM Peering Across a MI-PMSI"
   and "Unicasting of PIM C-Join/Prune Messages".  These are inadequately
   specified and in conflict with PIM-SM specification.  Given that these
   are already practically out of scope of the specification, these sections
   and text that relates to this should be removed.

4) Explicit tracking in S 5.4.2.  Philosophical. Using BGP such that
   upon the receipt of type-specific new information X it is required to
   perform some, timing-sensitive other action Y seems wrong to me.
   Has this application of BGP been adequately reviewed in IDR WG?

5) Active source BGP messages.  This is a duplication of a similar mechanism
   in MSDP (RFC3618) which has caused much gried in Internet.  Does this
   meant that when a host does 'nmap -sU 224.0.0.0/4' at a VPN site, this
   will result in about 268 million BGP active source updates being sent
   (2^28) in the SP backbone?  This problem is not described in security
   considerations.

6) PIM-BIDIR usage.  May the SP use PIM-BIDIR internally even if the customer
   interface would use PIM-SM?  The assumption when BIDIR is applicable is not
   clear.  Given that using BIDIR-PIM is an all-or-nothing solution, the
   only operationally feasible model would appear to be that that the
   {SM,BIDIR} operational modes used by the customer and SP must be
   independent from each other.  Is this framework compatible with that?

7) Type 0 Route Distinguisher.  The spec mandates using type 0 RD which
   embeds 16-bit AS-number.  Another type exists for 32-bit ASN, but it is
   not clear if i

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Sam Hartman]

> "Olaf" == Olaf Kolkman  writes:

Olaf> On Sep 8, 2009, at 6:09 PM, Sam Hartman wrote:

> Tim, I definitely agree with you that it should be the IETF community
>> that is last called.  Normally, the IESG judges IETF consensus.
>> However, if it makes the IAB more comfortable for the IAB chair
>> to do the consensus call, that's fine with me.  If we do that
>> we'd need to make it clear how this interacts with the IETF
>> appeals process.



Olaf> Sam,

Olaf> the underlying point of my question is that the streams are
Olaf> independent and that the IETF (stream) has no say about the
Olaf> other streams. IETF consensus or not. 

Right; I think I made it fairly clear in my reply to John Klensin that
I disagreed fairly strongly with that and argued why I believed that
the IETF needs a special role to attach a note to something.  No
discussion prior or since has changed my mind.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Robert Elz]

Date:Wed, 09 Sep 2009 07:17:50 -0400
From:Sam Hartman 
Message-ID:  

  | Right; I think I made it fairly clear in my reply to John Klensin that
  | I disagreed fairly strongly with that and argued why I believed that
  | the IETF needs a special role to attach a note to something.  No
  | discussion prior or since has changed my mind.

Ask yourself if you'd have the same opinion if the IETF was publishing
its output in IEEE Transactions on Networking (or any similar publication),
or even something like the NY Times.

Would you still expect the IESG to be able to tell the editor of that
publication what they are required to do?

Then note that this is exactly the same ralationship that the RFC
editor should have with the IETF.

In any case, if the editor is failing to perform adequately, the correct
response is to replace the editor - there is no rational consittuency here
in which to seek consensus (no matter who does the seeking) and no-one
rational to handle appeals, so I'm not in favour of John K's compromise
proposal.

Simply allow the editor the discretion to make his/her own decisions
(in this case, it will become the ISE with co-ordination from the RFC editor)
and then if they're failing (which mostly means, not getting things published, 
but might also mean sub-standad publications), then replace them with
someone who can do better.

Nothing more than that is needed.

kre

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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Sam Hartman]

> "Robert" == Robert Elz  writes:

Robert> Then note that this is exactly the same ralationship that
Robert> the RFC editor should have with the IETF.

I disagree for reasons I have previously stated.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: New validation of RFC 2543

[Dave CROCKER]

Competing carriers of different media types isn't quite demonstrating 
interoperability.  Or were two pidgeons used for duplex operations?


d/

Richard Shockey wrote:

Time to move to Draft Standard.

http://idle.slashdot.org/story/09/09/08/1414248/SAs-Largest-Telecomms-Provid
er-vs-a-Pigeon


--

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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Donald Eastlake]

Sam,

The burden of proof rests on those like you who wish to change the
independent stream from a respected independent publishing channel to
something subservient to the Area Directors, a change which seems
entirely gratuitous without any historically demonstrated need.

Donald

On Wed, Sep 9, 2009 at 9:22 AM, Sam Hartman wrote:
>> "Robert" == Robert Elz  writes:
>
>    Robert> Then note that this is exactly the same ralationship that
>    Robert> the RFC editor should have with the IETF.
>
> I disagree for reasons I have previously stated.
> ___
> 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

Nomcom 2009-10: Important Reminder: Call for Nominations, Local Office hours, Nominee Questionnaires available

[Mary Barnes]

Hi all,

This is a 2nd reminder of the Call for Nominations that is underway.  We
*really* need more nominations in order to properly execute the task of
selecting candidates for the open positions. At this time, the number of
nominations for all the positions is about 1/2 of what is necessary for
the Nomcom to do a conscientious job of evaluating the nominees and we are
over 2/3 of the way through the nominations period. Nomcom cannot do their
job without this important input from the community. 

So, please consider making nominations for the open positions - it takes
just a few minutes of your time - the details are below.  Right now, we
just need the names/email addresses for the nominees - we'll be soliciting
feedback later. Also, consider that over 1/2 the nominees are not able to
accept the nominations for a variety of reasons - e.g., lack of funding,
lack of sponsor support, etc. Thus, please consider nominating more than
one individual for each of the positions.  

As well as the reminder for the call for nominations, this email also
serves as a reminder for:
2) Local Office Hours
3) Questionnaires available for nominees 

Best Regards, 
Mary Barnes
nomcom-ch...@ietf.org
mary.h.bar...@gmail.com
mary.bar...@nortel.com


=

1) Call for Nominations

The nomination period ends in less than 2 weeks on Sept. 18th, 2009. We
appreciate the folks that have taken the time to make nominations thus
far. But, we do need more nominations. Please use the online tool to
nominate - it's fast, easy and secure:
https://wiki.tools.ietf.org/group/nomcom/09/nominate

Details on the open positions, as well as other details and options for
making nominations are available on the Nomcom homepage:
https://wiki.tools.ietf.org/group/nomcom/09/

Please consider that the sooner you make the nominations, the more time
your nominee(s) will have to complete the necessary questionnaire (item 3
below).  As well, please consider nominating more than one person for a
particular position. You will have the opportunity to provide additional
feedback later and it's important to consider that not all nominees will
be able to accept the nomination. 


2) Local office hours
---

In order facilitate additional feedback, the Nomcom has decided to make
themselves available for office areas at various geographic locations for
3 weeks in September, starting on the 8th. 

Below please find the list of locations where Nomcom members will be
available for these f2f meetings . Unless dates are identified below, the
Nomcom member is generally available for part of the day during the weeks
of Sept 8-11, Sept 14-18 and Sept 21-25. Also, languages other than
English in which the Nomcom member is fluent are identfied.  

Please contact a Nomcom member in a specific geographic location to
arrange a convenient meeting time and place. Most Nomcom members are
flexible as to meeting locations - i.e., we can travel to your office,
meet at our offices or somewhere in between.  

As a reminder folks can always contact any Nomcom member to provide
feedback at anytime - i.e., you don't need to participate in these f2f
sessions to provide feedback. 


Belgium: 
 Dimitri Papadimitriou - dimitri.papadimitr...@alcatel-lucent.be (Sept
21-25) (Languages: French) 

Boston, Mass, USA:  
 Stephen Kent - k...@bbn.com  (Sept 16-18) 

Boulder, CO, USA: 
 Wassim Haddad - wmhad...@gmail.com (Sept 14-18)

Dallas/Ft. Worth, TX, USA:  
 Mary Barnes  - mary.h.bar...@gmail.com 
 Lucy Yong - lucyy...@huawei.com  (Languages: Chinese) 

Helsinki, Finland: 
  Simo Veikkolainen - simo.veikkolai...@nokia.com (Languages: Finnish)
 

Ithaca, NY, USA: 
  Scott Brim - scott.b...@gmail.com

Montevideo, Uruguay: 
  Roque Gagliano - ro...@lacnic.net (Sept 14-18, 21-25) (Languages:
Spanish, Portuguese) 

Montreal, Quebec, Canada 
 Wassim Haddad - wmhad...@gmail.com (Sept 8-11)
 -- Can also be available in Ottawa if folks are interested 

Paris, France: 
  Dimitri Papadimitriou - dimitri.papadimitr...@alcatel-lucent.be
(Sept 15-18)  (Languages: French)

San Diego, CA, USA: 
  Randall Gellens - rg+i...@qualcomm.com   
  Dave Crocker - dcroc...@bbiw.net  (Sept 16-18)

Silicon Valley/SF Bay,  CA, USA: 
  Dave Crocker - dcroc...@bbiw.net  (Sept 8-11, Sept 14-15, Sept
21-25)   
  Dorothy Gellert - dorothy.gell...@gmail.com

3) Questionnaires available for nominees: 

For folks that have been notified that they have been nominated for any
of the positions, the questionnaires are now available on the Nomcom09
tools website:
https://wiki.tools.ietf.org/group/nomcom/09/iab-questionnaire
https://wiki.tools.ietf.org/group/nomcom/09/iaoc-questionnaire
https://wiki.tools.ietf.org/group/nomcom/09/iesg-questionnaire

If you have any questions, please let me know. I will be contacting
everyone individually, as well as sending reminders. 

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Robert Elz]

Date:Wed, 9 Sep 2009 09:53:42 -0400
From:"Polk, William T." 
Message-ID:  

  | IMHO, the RFC series (as comprised by the four document streams) is not
  | similar to IEEE Transactions on Networking or the NY Times.  I am not sure
  | that there is really a close analog out there.

It is an independent publisher publishing material submitted to it - the
NY Times analogy isn't close, as they create much of their own material,
which neither IEEE Transactions, nor the RFC editor do (or not much of,
indexes and stuff like that excepted), but aside from that, there shouldn't
be a lot of difference.

  | The better question is, if IEEE was distributing the output of the IETF in
  | its series of standards publications

You're operating under the mistaken impression that the RFC series is
IETF standards - it isn't - some of he RFCs are IETF standards, others
are other IETF publications, and others have nothing to do with the IETF
at all.   It is just a document series that the IETF happens to use as
a place to publish its output.

If there was a document series and publisher that was exclusively for
IETF standards, then we wouldn't be publishing anything else there at all,
and the question of notes would be irrelevant - that would be closer to the
way IEEE and ISO standards are published - but that is not what the RFC
series is now, or ever has been.

  | And are we really helping anyone by not clarifying the relationship between
  | the document and other RFCs?  Shouldn't we provide this information as a
  | service to the reader?

Many times that is reasonable, probably, and no-one is suggesting that
the RFC editor always refuse to publish IESG notes (though some of us
don't believe the IESG should very often, if at all, request one) - the
question isn't what happens when an IESG note is appropriate, the question
is what happens when it isn't - and who gets to decide.

kre

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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Dave CROCKER]

Robert Elz wrote:

  | The better question is, if IEEE was distributing the output of the IETF in
  | its series of standards publications

You're operating under the mistaken impression that the RFC series is
IETF standards - it isn't - some of he RFCs are IETF standards, others
are other IETF publications, and others have nothing to do with the IETF
at all.   It is just a document series that the IETF happens to use as
a place to publish its output.



This is the core point.  Some folk want to re-cast the RFC series as structly 
subservient to the IETF.  But that's not how it has operated for 40 years.  Yes, 
folks, 4 decades.


There is a fundamental difference between "having a strong relationship" versus 
"being subservient".


In order to make such a basic change, there needs to be a compelling statement 
of need for which there is strong community consensus.  None has yet been 
offered, except the same one that gets repeated every few years, for at least 20 
 years, namely that some folk don't understand the RFC series.  Sigh.  Yes, 
folks, this thread is the same as has been repeated many, many times, including 
the consistent lack of demonstrated damage from the current arrangement.


d/
--

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

RE: Last Call: draft-reschke-rfc2731bis (RFC 2731 is Obsolete) toInformational RFC

[David Harrington]

Hi,

I find the title irritating. I had to go open the draft to know what
it was obsoleting. 

Reading the abstract, I find that the draft proposes declaring RFC2731
Historic (not Obsolete)
So the title is actually misleading. 

But wait. According to the heading, if approved, this draft will
obsolete RFC2731. Which are we doing Historic, or Obsolete? (can you
do both simultaneously?)

In actuality, what this draft is doing is transferring responsibility
for further development of the "Encoding Dublin Core Metadata in HTML"
to Dublin Core Metadata Initiative. 

Neither RFC2731 nor this draft make it clear whether RFC2731 was a
snapshot of work that was done by the Dublin Core Metadata Initiative
and simply published as an Informational draft to inform the IETF, or
whether RFC2731 was contributed to the IETF with the intent of
developing an IETF standard (and subsequently failed). There is almost
no discussion of why RFC2731 is being declared obsolete/Historic and
why further development has moved to the Dublin Core Metadata
Initiative.

I had occasion to coordinate the transfer of responsibility from the
IETF to IEEE for some work, and had to spend significant effort
working through the copyright issues and the migration issues
(RFC4663). The work being transferred in RFC4663 is an IETF standard,
whereas RFC2731 is only Informational, so that could make a lot of
difference, but there is simply no discussion at all of copyright
issues and migration issues. And the reasons why RFC2731 is not still
considered valid (just an earlier version), or why this step to
declare the RFC Historic is being done are extremely light. Is it to
prevent it being used because this old version and the updated work
cannot coexist? or do we just not like this one any more? 

Is it because the effort to standardize failed? (Did the Initiative
want to keep editorial control, and when they found out they couldn't
if it was standard, they took their ball and went home? Is this draft
to provide a pointer to the Initiative because providing this pointer
in an RFC sort of implies that IETF endorses the Initiative as the SDO
for setting a standard(?) for this metadata? (I notice there are
Editorial notes to remove some text; are all mentions of the
Initiative being removed? I couldn't tell the scope of the Editorial
note. It might be better to see an updated version that has been
cleaned up, so there are no misunderstandings about what should be in
the published RFC.)

RFC2731 contains perl code. They are published with this text that
appears to be a license: "They may be
   taken and freely adapted for local organizational needs, research
   proposals, venture capital bids, etc."
If RFC2731 is obsoleted, does this in any way affect the license and
the legal rights of implementers of RFC2731? This is not discussed.

I find this draft not very satisfying because it simply ignores so
much.

In security considerations sections, it is acceptable to say "hey, we
considered this and reached the conclusion that authentication and
authorization and other security features are not needed." It is not
considered acceptable to simply omit any discussion of the security
considerations.

I don't want new boilerplates, but there are a bunch of issues related
to this document that are simply not discussed. I think this document
should include (very small) sections that reflect that copyright
issues have been considered; that authors rights in RFC2731 have been
considered; that migration issues for implementers of RFC2731 have
been considered; that licensing issues for the contained code have
been considered. None of this has been documented, so a reader cannot
know whether these have been considered and not documented, or simply
overlooked.

I do not think this document is ready for publication as an RFC.

David Harrington
dbharring...@comcast.net
ietf...@comcast.net
dharring...@huawei.com


> -Original Message-
> From: ietf-announce-boun...@ietf.org 
> [mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG
> Sent: Wednesday, September 09, 2009 9:31 AM
> To: IETF-Announce
> Subject: Last Call: draft-reschke-rfc2731bis (RFC 2731 is 
> Obsolete) toInformational RFC
> 
> The IESG has received a request from an individual submitter 
> to consider 
> the following document:
> 
> - 'RFC 2731 is Obsolete '
> as an Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and
solicits
> final comments on this action.  Please send substantive 
> comments to the
> ietf@ietf.org mailing lists by 2009-10-07. Exceptionally, 
> comments may be sent to i...@ietf.org instead. In either case,
please 
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-reschke-rfc2731bis-02.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
w_id&dTag=18624&rfc_flag=0
> 
> 

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Noel Chiappa]

> From: Donald Eastlake 

> The burden of proof rests on those ... who wish to change the
> independent stream from a respected independent publishing channel to
> something subservient to the Area Directors, a change which seems
> entirely gratuitous without any historically demonstrated need.

A most concise and incisive summary of the situation.

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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Stephan Wenger]

Hi,

As it has been pointed out here often, the RFC series is more than just the
document numbering scheme for IETF standards.  However, if you attend a
marketing gathering, a random CS conference, a non-IETF standardization
meeting, or even the IETF plenary, a majority of people (probably a large
majority) would answer the question "what are RFCs" with "standards set by
the IETF", or something thereabouts.

This *perception* is important.  And changing it means changing the
*perception* of a large number of people, for very little value except
honoring a 40 year old institution.  That's not a value proposition I can
easily support.

If the IETF is *perceived* as the owner and/or sole contributor to the IETF
series, it should have influence up to veto power regarding the content of
that series, through its chosen management structure---that is, AFAIK and in
this case, the IESG.  Otherwise, it cannot stop the publication of documents
against its interest.

It's pretty clear now that the IESG is not going to get the tools I consider
required to influence the RFC editor, due to historical facts and the
independence of the RFC editor and its support functions.

Is it time that the IETF considers publishing its material elsewhere?

Regards,
Stephan
 


On 9/9/09 8:32 AM, "Dave CROCKER"  wrote:

> 
> 
> Robert Elz wrote:
>>   | The better question is, if IEEE was distributing the output of the IETF
>> in
>>   | its series of standards publications
>> 
>> You're operating under the mistaken impression that the RFC series is
>> IETF standards - it isn't - some of he RFCs are IETF standards, others
>> are other IETF publications, and others have nothing to do with the IETF
>> at all.   It is just a document series that the IETF happens to use as
>> a place to publish its output.
> 
> 
> This is the core point.  Some folk want to re-cast the RFC series as structly
> subservient to the IETF.  But that's not how it has operated for 40 years.
> Yes, 
> folks, 4 decades.
> 
> There is a fundamental difference between "having a strong relationship"
> versus 
> "being subservient".
> 
> In order to make such a basic change, there needs to be a compelling statement
> of need for which there is strong community consensus.  None has yet been
> offered, except the same one that gets repeated every few years, for at least
> 20 
>   years, namely that some folk don't understand the RFC series.  Sigh.  Yes,
> folks, this thread is the same as has been repeated many, many times,
> including 
> the consistent lack of demonstrated damage from the current arrangement.
> 
> d/


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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Dave CROCKER]

Stephan Wenger wrote:

This *perception* is important.  And changing it means changing the
*perception* of a large number of people, for very little value except
honoring a 40 year old institution.  That's not a value proposition I can
easily support.

If the IETF is *perceived* as the owner and/or sole contributor to the IETF
series, 



Stephen,

First, you lack empirical data to substantiate your assessment of the 
perception.

Second, you lack empirical data that it is causing a pragmatic problem.

That is what ought to be the lesson of having repeated this thread every few 
years for 20 years ought to be.


Make a change when you have a demonstrable, real and damaging problem, not just 
something you don't like.


d/
--

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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Andrew Sullivan]

On Wed, Sep 09, 2009 at 09:19:05AM -0700, Dave CROCKER wrote:
> First, you lack empirical data to substantiate your assessment of the 
> perception.

Well, Wikipedia (which IMO is primarily useful as a repository for
finding out what "everyone knows") has this first sentence in its
description of the RFC series:

> In computer network engineering, a Request for Comments (RFC) is a
> memorandum published by the Internet Engineering Task Force (IETF)
> describing methods, behaviors, research, or innovations applicable to
> the working of the Internet and Internet-connected systems.

The fourth link from Google in response to, "What is an RFC?" says

> RFC is an acronym for Request for Comments and official documents from
> the Internet Engineering Task Force (IETF) with an unlimited
> distribution.  RFC's are numbered in a series and are referred to by
> numbers.

So even if those pages go on to refine their statements, I don't think
it preposterous to suggest that people think "the RFC series" is "from
the IETF".

I am totally unwilling to have an opinion on whether anyone ought to
try to do anything about this, but I don't think we should pretend
that the world is otherwise than it is.

A

-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Stephan Wenger]

Hi Dave,

I agree with your second observation.  It may well be that the current RFC
editor model has not *yet* caused a pragmatic problem.

I stand to my first assessment, as originally formulated.

The main issue is: should the IETF be pro-active on these matters, or not.
For the IETF as an organization, I see no value beyond traditions in staying
with the RFC publication model.  (The marketing value of using the RFC
series is IMHO contradicted by the lack of control of the IETF over the RFC
series).  If there were indeed no value beyond traditions, why run any risk,
no matter how small?  Certainly there must be some risk in giving the RFC
editor, rather than the duly appointed IETF officials, the last say in
publishing documents that are perceived as IETF documents.

I could follow an argument that changing the publication mechanism is large
enough a pain to best avoid it, for the small pragmatic gains we may get.

Regards,
Stephan




On 9/9/09 9:19 AM, "Dave CROCKER"  wrote:

> 
> 
> Stephan Wenger wrote:
>> This *perception* is important.  And changing it means changing the
>> *perception* of a large number of people, for very little value except
>> honoring a 40 year old institution.  That's not a value proposition I can
>> easily support.
>> 
>> If the IETF is *perceived* as the owner and/or sole contributor to the IETF
>> series, 
> 
> 
> Stephen,
> 
> First, you lack empirical data to substantiate your assessment of the
> perception.
> 
> Second, you lack empirical data that it is causing a pragmatic problem.
> 
> That is what ought to be the lesson of having repeated this thread every few
> years for 20 years ought to be.
> 
> Make a change when you have a demonstrable, real and damaging problem, not
> just 
> something you don't like.
> 
> d/


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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Noel Chiappa]

> From: Stephan Wenger 

> For the IETF as an organization, I see no value beyond traditions in
> staying with the RFC publication model. (The marketing value of using
> the RFC series is IMHO contradicted by the lack of control of the IETF
> over the RFC series).

If I understand you correctly, you're suggesting creating a new document
series for use by the IETF, for its standards documents?  If so, I don't
recall this possibility being discussed before, although I can't believe it
hasn't been suggested at some point.

Such a change would be acceptable to me - although it might take a while to
build up the distribution system that already exists for RFCs.

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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Dave CROCKER]

Andrew Sullivan wrote:

On Wed, Sep 09, 2009 at 09:19:05AM -0700, Dave CROCKER wrote:

First, you lack empirical data to substantiate your assessment of the 
perception.


Well, Wikipedia 

...

The fourth link from Google in response to, "What is an RFC?" says

...

So even if those pages go on to refine their statements, I don't think
it preposterous to suggest that people think "the RFC series" is "from
the IETF".



Andrew (and Stephen),

Thank you for exploring the question of empirical data, as well as demonstrating 
how methodologically challenged discussion in the IETF tends to be, particularly 
with respect to anything involving or implying statistics...


The original comment was about universality of perception.  Particular examples 
were cited at the beginning of Stephen's note, but they morphed into a statement 
of universality by the end of it.


Your own note cited the first and fourth google listings but left out, for 
example, the second and third.  Based on that latter set, I could claim that 
"THE" perception is that the RFC series is "the working notes of the Internet 
research and development community" and "a formal mechanism used to describe 
communications standards for the Internet and systems (like USENET) that are 
closely tied to it."


That's quite a different characterization of the RFC series and besides being 
more accurate, it has the same empirical basis being put forth as "the" 
perception" of the series as what you are citing.


But, of course, this is all about the first of two challenges I offered and 
empirical data for the latter is what justifies considering a change.


Stephen just posted the view that we should be "proactive", but does not seem to 
understand that we missed that opportunity 20 years ago.  Whatever "problem" we 
need to anticipate has failed to materialize for two decades.


But the real crux of this debate is represented by the difference between my 
second challenge and Stephen's alternative challenge: "If there were indeed no 
value beyond traditions, why run any risk, no matter how small?"


First, it means that we need to be clearer about the intended benefit behind 
having the Independent stream.  (For any activity, it's always a good idea to 
have an explicit and visible value proposition...)


Second, it misses the practical implication of making changes due to imagined 
risks, particularly since there is always an infinite set of them to choose from.


Third, it ignores the operations rule that all change is, itself, risk, and that 
therefore no change is justified unless there is a solid basis for expecting 
very, very substantial benefits.  (For any activity, it's always a good idea to 
have an explicit and visible value proposition...)


d/
--

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

Re: Last Call: draft-reschke-rfc2731bis (RFC 2731 is Obsolete) toInformational RFC

[Julian Reschke]

Hi David,

thanks for your review. Before I comment on individual parts let me 
explain how we got here:


- RFC 2731 is an Informational RFC describing how to put Dublin Core 
metadata into HTML, and was published almost 10 years ago.


- It hasn't been touched since then.

- The Dublic Core Metadata Initiative took over further development a 
few months later 
(), and has 
maintained this specification since. Note that this isn't a different 
format but just mainly maintenance work, keeping it up-to-date with 
current W3C specs.


The current situation causes people to potentially implement RFC 2731, 
and not being aware of the newer work. This has happened to me, and thus 
I decided that something needs to be done.


I asked the DCMI people whether they were interested in *updating* RFC 
2731, and it turned out they aren't (and it would make little sense to 
publish this in two places).


I also asked the IESG for feedback on how to update the status of an 
existing RFC in the RFC Index, and the answer I got was that the easiest 
approach is to replace it with a newer RFC saying what needs to be said.


BTW: It's good to have this discussion right now, as we may have to do 
something similar with a much more important RFC (2854) soonish.


More comments in-line:

David Harrington wrote:

Hi,

I find the title irritating. I had to go open the draft to know what
it was obsoleting. 


I thought the title says what it's obsoleting.


Reading the abstract, I find that the draft proposes declaring RFC2731
Historic (not Obsolete)
So the title is actually misleading. 


It is, and sorry for that.

As far as I recall, I borrowed structure and text from RFC 4794 ("RFC 
1264 Is Obsolete", moving RFC 1264 to *historic*). (Steal with Pride).


That RFC was written by Bill Fenner (a former AD), so I assumed he knows 
what to do.


That being said, I really do not care about this detail, as long as the 
outcome is that the RFC Index points consumers of RFC 2731 to the place 
where the specification really is maintained today.



But wait. According to the heading, if approved, this draft will
obsolete RFC2731. Which are we doing Historic, or Obsolete? (can you
do both simultaneously?)


Sort of. RFC 2731 would be classified as "Historic", and be obsoleted by 
this spec. At least this is what happened in the example above.



In actuality, what this draft is doing is transferring responsibility
for further development of the "Encoding Dublin Core Metadata in HTML"
to Dublin Core Metadata Initiative. 


No, it does not. The responsibility has been transferred long ago; it 
just documents that fact.



Neither RFC2731 nor this draft make it clear whether RFC2731 was a
snapshot of work that was done by the Dublin Core Metadata Initiative
and simply published as an Informational draft to inform the IETF, or
whether RFC2731 was contributed to the IETF with the intent of
developing an IETF standard (and subsequently failed). There is almost
no discussion of why RFC2731 is being declared obsolete/Historic and
why further development has moved to the Dublin Core Metadata
Initiative.


I don't have that information. I would support adding it, but I don't 
think the reasons are really important.



I had occasion to coordinate the transfer of responsibility from the
IETF to IEEE for some work, and had to spend significant effort
working through the copyright issues and the migration issues
(RFC4663). The work being transferred in RFC4663 is an IETF standard,
whereas RFC2731 is only Informational, so that could make a lot of
difference, but there is simply no discussion at all of copyright
issues and migration issues. And the reasons why RFC2731 is not still
considered valid (just an earlier version), or why this step to
declare the RFC Historic is being done are extremely light. Is it to
prevent it being used because this old version and the updated work
cannot coexist? or do we just not like this one any more? 


Well, it's not up-to-date anymore. Don't use it. Look elsewhere.

If this means that moving it to "Historic" is the wrong thing, I'll be 
happy to remove that part.



Is it because the effort to standardize failed? (Did the Initiative
want to keep editorial control, and when they found out they couldn't
if it was standard, they took their ball and went home? Is this draft
to provide a pointer to the Initiative because providing this pointer


It's about telling readers where they find the current specification. 
The politics why it's not an IETF spec anymore are certainly 
interesting, but IMHO not essential for documenting what is clearly the 
situation today.



in an RFC sort of implies that IETF endorses the Initiative as the SDO
for setting a standard(?) for this metadata? (I notice there are
Editorial notes to remove some text; are all mentions of the
Initiative being removed? I couldn't tell the scope of the Editorial
note. It might be better to see an upda

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Andrew Sullivan]

On Wed, Sep 09, 2009 at 10:34:02AM -0700, Dave CROCKER wrote:

> for example, the second and third.  Based on that latter set, I could 
> claim that "THE" perception is that the RFC series is 

I am at the best of times uneasy with universal quantifiers, and
certainly when talking about THE belief of THE Internet, I feel pretty
uneasy.  Also, I haven't followed this discussion much, partly because
I fully agree with the observation that most of it has been hashed so
much, and warmed over so many times, that it's now turned into a form
of American breakfast potato.

But it doesn't seem to me to be doing favours to anyone to deny the
obvious point that there's at least a substantial community of people
who regard the label "RFC" as bespeaking "an IETF document" and also
"Internet standard".  Claiming that it's not true by pointing to
examples of careful and clueful definitions (one of which is
practically a sockpuppet for the IETF pages themselves) does not
clarify this matter.  Even organizations involved in the
administration of the Internet apparently rely on something "being an
RFC" as somehow implying an _imprimatur_ or at least _nihil obstat_
(if anyone wants evidence of that matter, I think the archives of
agreements found at ICANN will be instructive). 

Again, I wish to emphasise that this is completely distinct from the
question of whether anyone ought to do anything about the state of
affairs.  I refuse to take a position on that, or even consider it as
a topic for a conversation in which I'll be involved.  There are
enough windmills around without us throwing up new ones at which we
can tilt.

A

-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Lawrence Rosen]

Andrew Sullivan wrote:
> Again, I wish to emphasise that this is completely distinct from the
> question of whether anyone ought to do anything about the state of
> affairs.  I refuse to take a position on that, or even consider it as
> a topic for a conversation in which I'll be involved.  There are
> enough windmills around without us throwing up new ones at which we
> can tilt.

That's a shame. The standards world is looking for someone who can tilt at
the windmills that are the entrenched habits of our day. Who wants to be the
hero of that novel?

I'm being serious. I agree with you that there is much unhelpful confusion
about "RFCs".

/Larry


Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com) 
3001 King Ranch Road, Ukiah, CA 95482
Cell: 707-478-8932


-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Andrew Sullivan
Sent: Wednesday, September 09, 2009 11:20 AM
To: ietf@ietf.org
Subject: Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature
of IESG notes

On Wed, Sep 09, 2009 at 10:34:02AM -0700, Dave CROCKER wrote:

> for example, the second and third.  Based on that latter set, I could 
> claim that "THE" perception is that the RFC series is 

I am at the best of times uneasy with universal quantifiers, and
certainly when talking about THE belief of THE Internet, I feel pretty
uneasy.  Also, I haven't followed this discussion much, partly because
I fully agree with the observation that most of it has been hashed so
much, and warmed over so many times, that it's now turned into a form
of American breakfast potato.

But it doesn't seem to me to be doing favours to anyone to deny the
obvious point that there's at least a substantial community of people
who regard the label "RFC" as bespeaking "an IETF document" and also
"Internet standard".  Claiming that it's not true by pointing to
examples of careful and clueful definitions (one of which is
practically a sockpuppet for the IETF pages themselves) does not
clarify this matter.  Even organizations involved in the
administration of the Internet apparently rely on something "being an
RFC" as somehow implying an _imprimatur_ or at least _nihil obstat_
(if anyone wants evidence of that matter, I think the archives of
agreements found at ICANN will be instructive). 

Again, I wish to emphasise that this is completely distinct from the
question of whether anyone ought to do anything about the state of
affairs.  I refuse to take a position on that, or even consider it as
a topic for a conversation in which I'll be involved.  There are
enough windmills around without us throwing up new ones at which we
can tilt.

A

-- 
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
___
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

IESG Statement on Copyright

[IESG Secretary]

This IESG Statement obsoletes all earlier IESG Statements regarding
Copyright statements in MIB and PIB Modules.

The IESG is providing this guidance to align current practice with
RFC 5377, RFC 5378, and the resulting IETF Trust Legal Provisions (TLP)
(http://trustee.ietf.org/license-info).

IETF Contributions and IETF Documents often include code components
that are intended to be directly processed by a computer. Examples of
such code components include ABNF definitions, XML Schemas, XML DTDs,
XML RelaxNG definitions, tables of values, MIBs, PIBs, ASN.1, and
classical programming source code. The IETF Trust maintains a list of
code component types. A link to this list can be found on this web
page: http://trustee.ietf.org/license-info.

In addition to the code component types listed, any text found between
the markers  and  shall be considered
a code component. Authors may wish to use these markers as clear
delimiters of code components.

Authors are encouraged to collect code into a separate section or
appendix.

The TLP requires copyright notice in IETF Documents, but not necessarily
in each code component within an IETF Document. Authors may choose to
include a copyright notice as a comment when a significant amount of
code is collected together. For example, authors may include a
copyright notice in a comment as part of an ASN.1 module or a
representation of a classical programming language file. If IETF
Document authors choose to include a code component copyright notice
comment, they must follow the guidance in Section 6.d of the TLP.
Implementors that extract any code component from the IETF Document must
include the BSD license text as described in Section 4.e of the TLP.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf