Weekly posting summary for ietf@ietf.org

[Thomas Narten]

Total of 292 messages in the last 7 days.
 
script run at: Fri Dec  9 00:53:02 EST 2011
 
Messages   |  Bytes| Who
+--++--+
  5.48% |   16 |  5.12% |   114028 | d...@dcrocker.net
  4.45% |   13 |  4.59% |   102200 | ma...@isc.org
  4.79% |   14 |  3.31% |73805 | j...@mercury.lcs.mit.edu
  3.77% |   11 |  3.72% |82844 | mansa...@besserwisser.org
  3.77% |   11 |  3.61% |80314 | do...@dougbarton.us
  3.42% |   10 |  3.61% |80379 | john-i...@jck.com
  3.08% |9 |  3.42% |76253 | victor.kuarsi...@gmail.com
  3.08% |9 |  2.67% |59384 | d...@virtualized.org
  2.74% |8 |  2.88% |64217 | daedu...@btconnect.com
  2.74% |8 |  2.68% |59593 | m...@cloudmark.com
  2.40% |7 |  2.62% |58304 | wesley.geo...@twcable.com
  2.40% |7 |  2.55% |56719 | c.don...@cablelabs.com
  2.40% |7 |  2.54% |56468 | hkap...@acmepacket.com
  2.40% |7 |  2.31% |51522 | joe...@bogus.com
  2.40% |7 |  2.24% |49977 | gda...@au.logicalis.com
  2.40% |7 |  2.07% |46043 | brian.e.carpen...@gmail.com
  1.71% |5 |  2.54% |56636 | cb.li...@gmail.com
  2.05% |6 |  1.89% |42034 | m...@sap.com
  2.05% |6 |  1.87% |41724 | m...@sandelman.ca
  1.37% |4 |  2.17% |48305 | ted.i...@gmail.com
  1.71% |5 |  1.77% |39426 | bob.hin...@gmail.com
  1.71% |5 |  1.58% |35116 | bschl...@cisco.com
  1.37% |4 |  1.64% |36573 | presn...@qualcomm.com
  1.71% |5 |  1.24% |27636 | jo...@iecc.com
  1.03% |3 |  1.77% |39438 | hous...@vigilsec.com
  1.37% |4 |  1.17% |26126 | paul.hoff...@vpnc.org
  1.03% |3 |  1.49% |33141 | yaacov.weingar...@nsn.com
  1.37% |4 |  1.05% |23462 | mo...@necom830.hpcl.titech.ac.jp
  1.37% |4 |  1.04% |23061 | hmdmhdfmhdjmzdtjmzdtzktdkzt...@gmail.com
  1.03% |3 |  1.12% |24847 | ch...@ietf.org
  1.03% |3 |  1.11% |24689 | nurit.sprec...@nsn.com
  1.03% |3 |  1.03% |22914 | stbry...@cisco.com
  1.03% |3 |  0.99% |22030 | war...@kumari.net
  1.03% |3 |  0.97% |21533 | o...@cisco.com
  1.03% |3 |  0.89% |19916 | d...@xpasc.com
  0.68% |2 |  0.98% |21839 | daryl.tan...@blueyonder.co.uk
  0.68% |2 |  0.88% |19492 | j...@apple.com
  0.68% |2 |  0.85% |18990 | nar...@us.ibm.com
  0.68% |2 |  0.82% |18205 | g...@gtwassociates.com
  0.68% |2 |  0.74% |16494 | h...@cs.columbia.edu
  0.68% |2 |  0.69% |15343 | he...@pobox.com
  0.68% |2 |  0.67% |14994 | bernard_ab...@hotmail.com
  0.68% |2 |  0.67% |14873 | f...@cisco.com
  0.68% |2 |  0.62% |13713 | k...@munnari.oz.au
  0.68% |2 |  0.61% |13665 | barryle...@computer.org
  0.68% |2 |  0.59% |13122 | marshall.euba...@gmail.com
  0.68% |2 |  0.58% |12875 | melinda.sh...@gmail.com
  0.68% |2 |  0.52% |11688 | ra...@psg.com
  0.34% |1 |  0.86% |19143 | ho...@cisco.com
  0.68% |2 |  0.51% |11309 | m...@mnot.net
  0.68% |2 |  0.48% |10774 | a...@anvilwalrusden.com
  0.34% |1 |  0.77% |17219 | jdr...@juniper.net
  0.34% |1 |  0.74% |16447 | adr...@olddog.co.uk
  0.34% |1 |  0.60% |13297 | i.g...@comcast.net
  0.34% |1 |  0.48% |10699 | r.e.sonnev...@sonnection.nl
  0.34% |1 |  0.42% | 9310 | sant9...@gmail.com
  0.34% |1 |  0.39% | 8732 | m...@sabahattin-gucukoglu.com
  0.34% |1 |  0.37% | 8243 | rog...@gmail.com
  0.34% |1 |  0.37% | 8142 | huit...@microsoft.com
  0.34% |1 |  0.36% | 8083 | asay...@cisco.com
  0.34% |1 |  0.34% | 7599 | cgrundem...@gmail.com
  0.34% |1 |  0.33% | 7449 | l...@pi.nu
  0.34% |1 |  0.32% | 7224 | eck...@cisco.com
  0.34% |1 |  0.32% | 7070 | ray.bel...@nominet.org.uk
  0.34% |1 |  0.32% | 7051 | ferna...@gont.com.ar
  0.34% |1 |  0.31% | 6935 | rcal...@juniper.net
  0.34% |1 |  0.31% | 6927 | petit...@acm.org
  0.34% |1 |  0.31% | 6906 | rbon...@juniper.net
  0.34% |1 |  0.31% | 6890 | kpflem...@digium.com
  0.34% |1 |  0.31% | 6881 | s...@resistor.net
  0.34% |1 |  0.31% | 6866 | l...@cisco.com
  0.34% |1 |  0.30% | 6632 | pat...@frobbit.se
  0.34% |1 |  0.29% | 6519 | m...@lilacglade.org
  0.34% |1 |  0.29% | 6424 | l...@asgard.org
  0.34% |1 |  0.29% | 6400 | evniki...@gmail.com
  0.34% |1 |  0.28% | 6223 | dwor...@avaya.com
  0.34% |1 |  0.27% | 6002 | n...@inex.ie
  0.34% |1 |  0.26% | 5819 | m...@elandem.org
  0.34% |1 |  0.25% | 5667 | hartmans-i...@mit.edu
  0.34% |1 |  0.25% | 5551 | simon.perrea...@viagenie.ca
  0.34% |1 |  0.25% | 5533 | j...@jlc.net
  0.34% |1 |  0.24% | 5355 | stpe...@stpeter.im
  0.34% |1 |  0.24% | 5306 | ka...@trash.net
  0.34% |1 |  0.24% | 5301 | tnad...

Re: Errata against RFC 5226 rejected

[Barry Leiba]

> In a small registry like this, it is useful to have something in the
> box in the table that makes it less likely that the value will be squatted
> on.
>
> In the above example it is clearer in the 0..7 case that there are only
> two free values and I will need a real good use case.
>
> In the 0..5 case, someone might be more tempted to say, they are only
> using up to 5 I will take 6 and hope no one notices.

Fair point, and all the more reason to reject the errata report.

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

Re: Errata against RFC 5226 rejected

[Stewart Bryant]

On 08/12/2011 19:18, Barry Leiba wrote:

Errata 2684 was entered against RFC 5226, "Guidelines for Writing an IANA
Considerations Section in RFCs".  After discussion with one of the RFC authors
and IANA staff, I rejected the errata.

The errata author is saying that in many registries, there are no "unreserved"
values.  For registries where there are a finite number of entries possible, the
"unreserved" has a clear meaning.  For registries with an unbounded number
of potential entries (such as media-types), the errata author is claiming that 
the
"unreserved" label does not make sense.

First, Thomas, in his response, is addressing the wrong errata report.
  2715 is a report submitted by Mykyta that makes reference to Julian's
report (2684).  The latter is the one that Russ has rejected.  The
former is still in "reported" status.  I agree with Thomas that the
"SHALL" changes in 2715 are unnecessary, but that's not what Russ is
asking about.

Russ, you talk about "unreserved", but never mention the word that
Julian is asking to have removed, "unassigned", which is not the same
thing.  Do registries explicitly need to *list* the entries that are
*unassigned*?  As he says, this makes no sense for registries with
unlimited (or even very many) possible entries.  Even for those with a
small number, the value is questionable.  For example, suppose we had
a registry of three-bit unsigned integer values, and we said the
initial registry looked like this:

0 - reserved
1 - blue
2 - red
3 - purple
4 - private use
5 - reserved
6 - unassigned
7 - unassigned

That would indicate that 6 and 7 are available for future assignment.
But so would this:


0 - reserved
1 - blue
2 - red
3 - purple
4 - private use
5 - reserved

In the case of this hypothetical registry, with eight possible values,
there might be some use in explicitly saying that 6 and 7 are
currently unassigned.  But even extending this a little, if it were a
four-bit integer field we'd now be listing ten values as "unassigned".
  Make it six bits, and it's just plain silly.  Julian's right about
that.

That said, the best I can see for this report is "held for document
update."  It's one of those things that's not worth spending time on,
and, as Thomas says, the "should" language makes it fine as it is.

Barry


In a small registry like this, it is useful to have something in the
box in the table that makes it less likely that the value will be 
squatted on.


In the above example it is clearer in the 0..7 case that there are only
two free values and I will need a real good use case.

In the 0..5 case, someone might be more tempted to say, they are only
using up to 5 I will take 6 and hope no one notices.

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

Re: Consensus Call (Update): draft-weil-shared-transition-space-request

[John Leslie]

Noel Chiappa  wrote:
> 
> Maybe we should allocate a chunk of space explicity for tunnel termination,
> instead of using 1918 for that?

   Interesting... I've learned to avoid 1918 for tunnel endpoints at
almost-any cost: you lose all diagnostic packets.

   As it is now, I assign fully-routable IPs, and try to static-route
so the endpoint actually receives traffic to that IP. (It doesn't always
work.)

> I would think it could be re-used across enterprises (but I'm probably
> not familiar enough with tunnels to see some issue there),

   Presumably we wouldn't receive traffic to these IPs, but at least
the outgoing ICMP errors wouldn't be blocked.

> especially considering people are (re-)using 1918 space for that now.
> Anyway, if that did work, it should kill a bunch of these problems.

   It certainly seems like an improvement...

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

Re: Consensus Call (Update): draft-weil-shared-transition-space-request

[Noel Chiappa]

> From: =?utf-8?B?TcOlbnM=?= Nilsson 

> I have 1918 space at home, that is used at work. My VPN works.

Maybe we should allocate a chunk of space explicity for tunnel termination,
instead of using 1918 for that? I would think it could be re-used across
enterprises (but I'm probably not familiar enough with tunnels to see some
issue there), especially considering people are (re-)using 1918 space for that
now. Anyway, if that did work, it should kill a bunch of these problems.

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

Re: Errata against RFC 5226 rejected

[John C Klensin]

--On Thursday, December 08, 2011 14:02 -0500 Thomas Narten
 wrote:

> As background, the actual errata is at
> http://www.rfc-editor.org/errata_search.php?rfc=5226&eid=2715
>...
> I don't see the need for this. "should" seems good enough for
> me. Also, the wording "any ranges that are ... etc."  implies
> to me that the list provided are examples and if a category
> doesn't apply, you don't include it.
> 
> In other words, I don't see a problem with the existing text
> that warrants bothering with an errata.
> 
> But maybe I'm missing what the problem is.

Agreed, and let me go a half-step further.  This sort of
suggested change would be relevant iff 5226 were a rigid,
normative, spec from which people needed to select an enumerated
option and use it without variation.   While people sometimes
confuse it with such a spec, it isn't, has never been, and we
would be, IMO, doing ourselves a serious disservice by turning
it into one.   As long as that is the case, the level of
precision tuning implied by the proposed erratum isn't so much
wrong as it is irrelevant.

   john


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

Re: IPv6 not operational (was Re: Consensus Call: draft-weil-shared-transition-space-request)

[Toerless Eckert]

Not sure why rfc1981 PMTUD was never fixed. I've repeatedly tried to
suggest to just forget about PMTUD for IP multicast, and i have never
come across a good use case to justify MTU > 1280 for IP multicast
across the Internet.

We did manage to get section 11.1 into rfc 3542 though. It's a little
bit long due to committee design, but i was hoping it was sufficient to avoid
the problem by default. It recommends sender side MIN_MTU fragmentation
by default for IP multicast sent into IPv6 sockets.

If folks see IPv6 multicast > 1280 as a
real problem in deployments, pleae let me know. It would either indicate
socket stacks not observing rfc3542 or intentionally badly written
applications.

Cheers
Toerless

> Daryl Tanner wrote:
> 
> > The IPv6 "chickens and eggs" discussion could (and probably will) go on
> > forever:
> >
> > service provider ->  no content
> 
> > IPv6 is the right answer,
> 
> Wrong.
> 
> IPv6 is not operational, which is partly why most service
> providers refuse it.
> 
> For example, to purposelessly enable multicast PMTUD, RFC2463
> (ICMPv6) mandates routers generate ICMPv6 packet too big
> against multicast packets, which causes ICMPv6 packet
> implosions, which is not operational.
> 
> For further details, see my presentation at the last APNIC:
> 
>   How Path MTU Discovery Doesn't work
>   http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf
> 
>   Masataka Ohta
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Consensus Call (Update): draft-weil-shared-transition-space-request

[Michael Richardson]

> "Chris" == Chris Donley  writes:
Chris> We're requesting a /10, not a /12 or /15 (devices attached to
Chris> one CGN might use the whole /15).  Such an allocation would
Chris> be too small for a regional CGN deployment at a larger ISP,
Chris> and would likely result in double-CGN.  Shared CGN Space
Chris> really needs to be a /10.

Chris> Second, many ISPs do not control customer home network
Chris> addressing decisions.  It is not feasible to tell a customer
Chris> to renumber, especially when the customer is legitimately
Chris> using RFC1918 space in accordance with the RFC.

So, this is being forced on existing customers, or is being used for new
customers only?   

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 


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

Re: Consensus Call (Update): draft-weil-shared-transition-space-request

[Michael Richardson]

> "Mark" == Mark Andrews  writes:
Mark> This is not a ISP/CUSTOMER problem.  This is a
Mark> ISP/CUSTOMER/WORK problem.

Mark> You have the ISP using 172.16/12 You have the customer using
Mark> 192.168/16 or 10/8 You have WORK using 172.16/12

Mark> Enterpises have choosen to use 172.16/12 for EXACTLY the same
Mark> reasons you want ISP to use 172.16/12.  CPE equipment doesn't
Mark> default to that range.  Both the enterprise and the ISP don't
Mark> want to clash with the employee/customer.

It's not in general a problem unless the tunnel to work is terminated on
the CPE device itself.For the normal case, the *DEKSTOP/LAPTOP*
terminates the VPN, and so it sees CUSTOMER and WORK prefixes, while
CPE device sees CUSTOMER and ISP prefixes. WORK sees WORK and Public-IP
prefixes.

In the case where the VPN is terminated on the CPE device, I claim three
things: 
  a) customer/WORK is sophisticated and can communicate about problem.
  b) the CPE device already has a public IP on the outside, the ISP
 should not renumber it.
  c) the CPE device can be given a host route for it's default gateway,
 and it has no reason to talk to any other host in the ISPs CGN
 network anyway.

(Openswan installs a host route via the old default route for ESP
traffic, and a pair of 0.0.0.0/1 and 128.0.0.0/1 routes through the
tunnel if you are extruding.  This avoids removing the default route...)

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 


pgpm2uQUalo0C.pgp
Description: PGP signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Errata against RFC 5226 rejected

[Fred Baker]

On Dec 8, 2011, at 11:51 AM, Russ Housley wrote:

> Errata 2684 was entered against RFC 5226, "Guidelines for Writing an IANA 
> Considerations Section in RFCs".  After discussion with one of the RFC 
> authors and IANA staff, I rejected the errata.
> 
> The errata author is saying that in many registries, there are no 
> "unreserved" values.  For registries where there are a finite number of 
> entries possible, the "unreserved" has a clear meaning.  For registries with 
> an unbounded number of potential entries (such as media-types), the errata 
> author is claiming that the "unreserved" label does not make sense.
> 
> I'd like to know what others think about this errata.

To my mind, a potential value in a registry has three possible states:
  - it might already be defined (TCP is IP Protocol 6)
  - it might be available for future definition 
(http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml says 
that the numbers 143-252 are unassigned)
  - it might be set aside to never be defined (ibid says that 255 is 
"reserved").

RFC 6014 uses the term "unreserved" to refer to the fact that a potential value 
has not been assigned and has not been "reserved":
   IANA has marked values 123 through 251 as "Reserved".  The registry
   notes that this reservation is made in RFC 6014 (this RFC) so that
   when most of the unreserved values are taken, future users and IANA
   will have a pointer to where the reservation originated and its
   purpose.

In the actual registry, at IANA, these values are listed as "unassigned".

To my small mind, "unreserved" is an alternate spelling of "unassigned". I 
don't see a problem with a registry having values that might be defined after 
the registry has been created. One could argue that the term is unfortunate in 
that we normally use a different one, but the term has meaning. The creators of 
the registry didn't assign a meaning to the value and didn't preclude use of an 
otherwise valid value. It is available for future definition.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Errata against RFC 5226 rejected

[John Levine]

>In other words, I don't see a problem with the existing text that
>warrants bothering with an errata.

If IANA isn't able to figure out what they need to do under the
current wording, we have problems that no amount of word twiddling can
fix.

R's,
John

PS: The last time I checked, it wasn't a problem.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IAOC Member Selection

[IETF Chair]

The announcement sent on 13 November 2011 says that the IAB will confirm the 
IESG's selection.  Review of RFC 4071 reveals that there is not a requirement 
for confirmation.  Sorry for the confusion.

On behalf of the IESG,
  Russ Housley
  IESG Chair


On Nov 13, 2011, at 1:04 AM, IETF Chair wrote:

> Ole Jacobsen is the IAOC member that was appointed by the IESG, and
> his two-year term is up in March.  The IESG is starting the process
> to fill this seat in March 2012, with the term ending in March 2014.
> The two-week nominations period opens today, and closes on
> 27 November 2011.
> 
> 
> Nominations and eligibility
> 
> The IESG is making a public call for nominations.  Self-nominations
> are permitted.  All IETF participants, including working group chairs,
> IETF NomCom members, IAB members, and IESG members are
> eligible for nomination.  Of course, IAB and IESG members who accept
> nomination will recuse themselves from selection and confirmation
> discussions.  Please send nominations to i...@ietf.org.  Please include
> the following with each nomination:
> 
> - Name
> 
> - Contact information
> 
> - Candidate background and qualifications
> 
> 
> Desirable Qualifications and Selection Criteria
> 
> Candidates for the IAOC position should have a demonstrable involvement
> in the IETF, knowledge of contracts and financial procedures, awareness
> of the administrative support needs of the IAB, the IESG, and the IETF
> standards process.  The candidate is also expected to understand the
> respective roles and responsibilities of the IETF and ISOC in IASA, and
> be able to articulate these roles within the IETF community.
> 
> The candidate must be able to exercise all the duties of an IAOC Board
> member, including fiduciary responsibilities, setting of policies,
> oversight of the administrative operations of the IETF, representing
> the interests of the IETF, and participating in IAOC meetings and
> activities. The candidate must be able to serve as a Trustee for the IETF
> Trust. Although the IESG selects this member of the IAOC, the selected
> member does not directly represent the IESG.  The IESG-selected
> member is accountable directly to the IETF community.
> 
> BCP 101 says:
> 
> The IAOC shall consist of eight voting members who shall be selected
> as follows:
> 
> o Two members appointed by the IETF Nominations Committee (NomCom);
> 
> o One member appointed by the IESG;
> 
> o One member appointed by the IAB;
> 
> o One member appointed by the ISOC Board of Trustees;
> 
> o The IETF Chair (ex officio);
> 
> o The IAB Chair (ex officio);
> 
> o The ISOC President/CEO (ex officio).
> 
> 
> Selection
> 
> The IESG will publish the list of nominated persons prior to making a
> decision, allowing time for the community to provide any relevant
> comments to the IESG. The IESG will review the nomination material,
> any comments provided by the community, and make a selection.
> 
> 
> Confirmation
> 
> The IAB will act as the confirming body for the selection.  In the
> event that the IAB determines not to confirm the nominated candidate,
> the IAB will provide the IESG with the basis for this determination and
> the IESG will nominate another candidate.
> 
> 
> Care of Personal Information
> 
> The following procedures will be used in managing candidates' personal
> information:
> 
> - The list of candidate names will be published at the close of the
> nominations period.  A candidate that refuses the nomination will
> not be included on the list.
> 
> - Excerpts of the information provided to the IESG by the nominated
> candidate will be passed to the IAB as part of the confirmation
> process. The IAB will be requested to maintain confidentiality of
> candidate information.
> 
> - Except as noted above, all information provided to the IESG during
> this process will be kept as confidential to the IESG.
> 
> 
> Timeframe
> 
> The two-week nominations period opens today, and closes on
> 27 November 2011.
> 
> The list of willing candidates will be posted shortly after the nominations
> close, and the community will have two weeks to provide comments on the
> candidates to the IESG.
> 
> The IESG will make a selection on an IESG telechat following the
> comment period and send the name of the selected candidate to the IAB
> for confirmation.
> 
> 
> On behalf of the IESG,
> Russ Housley
> IESG Chair

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

Re: Errata against RFC 5226 rejected

[Peter Saint-Andre]

On 12/8/11 12:18 PM, Barry Leiba wrote:

> That said, the best I can see for this report is "held for document
> update."  It's one of those things that's not worth spending time on,
> and, as Thomas says, the "should" language makes it fine as it is.

+1. There's work happening in the background on 5226bis. Let those
authors sort it out. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


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

Re: Errata against RFC 5226 rejected

[Barry Leiba]

> Errata 2684 was entered against RFC 5226, "Guidelines for Writing an IANA
> Considerations Section in RFCs".  After discussion with one of the RFC authors
> and IANA staff, I rejected the errata.
>
> The errata author is saying that in many registries, there are no "unreserved"
> values.  For registries where there are a finite number of entries possible, 
> the
> "unreserved" has a clear meaning.  For registries with an unbounded number
> of potential entries (such as media-types), the errata author is claiming 
> that the
> "unreserved" label does not make sense.

First, Thomas, in his response, is addressing the wrong errata report.
 2715 is a report submitted by Mykyta that makes reference to Julian's
report (2684).  The latter is the one that Russ has rejected.  The
former is still in "reported" status.  I agree with Thomas that the
"SHALL" changes in 2715 are unnecessary, but that's not what Russ is
asking about.

Russ, you talk about "unreserved", but never mention the word that
Julian is asking to have removed, "unassigned", which is not the same
thing.  Do registries explicitly need to *list* the entries that are
*unassigned*?  As he says, this makes no sense for registries with
unlimited (or even very many) possible entries.  Even for those with a
small number, the value is questionable.  For example, suppose we had
a registry of three-bit unsigned integer values, and we said the
initial registry looked like this:

0 - reserved
1 - blue
2 - red
3 - purple
4 - private use
5 - reserved
6 - unassigned
7 - unassigned

That would indicate that 6 and 7 are available for future assignment.
But so would this:


0 - reserved
1 - blue
2 - red
3 - purple
4 - private use
5 - reserved

In the case of this hypothetical registry, with eight possible values,
there might be some use in explicitly saying that 6 and 7 are
currently unassigned.  But even extending this a little, if it were a
four-bit integer field we'd now be listing ten values as "unassigned".
 Make it six bits, and it's just plain silly.  Julian's right about
that.

That said, the best I can see for this report is "held for document
update."  It's one of those things that's not worth spending time on,
and, as Thomas says, the "should" language makes it fine as it is.

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

Re: Errata against RFC 5226 rejected

[Benson Schliesser]

I agree, and I think the original text is a better description of the 
requirement.

Cheers,
-Benson


On Dec 8, 2011, at 1:02 PM, Thomas Narten wrote:

> As background, the actual errata is at
> http://www.rfc-editor.org/errata_search.php?rfc=5226&eid=2715
> 
> In it Julian suggests (wdiff shows the proposed text changes):
> 
> 5) Initial assignments and reservations.  Clear instructions
>[-should-] {+SHALL+} be provided to identify any initial
>assignments or registrations.  In addition, any ranges that
>are {+"Unassigned" (only for those registries that have a
>bounded size),+} to be [-reserved-] {+"Reserved", used+} for
>"Private Use", [-"Reserved", "Unassigned",-]
>{+"Experimentation",+} etc. [-should-] {+SHALL+} be clearly
>indicated.
> 
> I don't see the need for this. "should" seems good enough for
> me. Also, the wording "any ranges that are ... etc."  implies to me
> that the list provided are examples and if a category doesn't apply,
> you don't include it.
> 
> In other words, I don't see a problem with the existing text that
> warrants bothering with an errata.
> 
> But maybe I'm missing what the problem is.
> 
> Russ Housley  writes:
> 
>> Errata 2684 was entered against RFC 5226, "Guidelines for Writing an
>> IANA Considerations Section in RFCs".  After discussion with one of
>> the RFC authors and IANA staff, I rejected the errata.
> 
>> The errata author is saying that in many registries, there are no
>> "unreserved" values.  For registries where there are a finite number
>> of entries possible, the "unreserved" has a clear meaning.  For
>> registries with an unbounded number of potential entries (such as
>> media-types), the errata author is claiming that the "unreserved"
>> label does not make sense.
> 
>> I'd like to know what others think about this errata.
> 
>> Russ
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

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

RE: Last Call: (DKIM Authorized Third-Party Signers) to Experimental RFC

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of 
> Douglas Otis
> Sent: Thursday, December 08, 2011 10:12 AM
> To: ietf@ietf.org
> Subject: Re: Last Call:  (DKIM Authorized 
> Third-Party Signers) to Experimental RFC
> 
> I support adoption of dkim-atps as an experimental RFC.  It would have
> been clearer to use the term Author-Domain rather than Author.
> Clearly, it is not the Author offering Authorization.

This has already been fixed in the working copy, which I'll post after the IETF 
LC closes.

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

RE: Errata against RFC 5226 rejected

[Murray S. Kucherawy]

> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of 
> Thomas Narten
> Sent: Thursday, December 08, 2011 11:02 AM
> To: Russ Housley
> Cc: IETF; i...@iesg.org
> Subject: Re: Errata against RFC 5226 rejected
> 
> I don't see the need for this. "should" seems good enough for me. Also,
> the wording "any ranges that are ... etc."  implies to me that the list
> provided are examples and if a category doesn't apply, you don't
> include it.
> 
> In other words, I don't see a problem with the existing text that
> warrants bothering with an errata.
> 
> But maybe I'm missing what the problem is.

+1.

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

Re: Errata against RFC 5226 rejected

[Thomas Narten]

As background, the actual errata is at
http://www.rfc-editor.org/errata_search.php?rfc=5226&eid=2715

In it Julian suggests (wdiff shows the proposed text changes):

 5) Initial assignments and reservations.  Clear instructions
[-should-] {+SHALL+} be provided to identify any initial
assignments or registrations.  In addition, any ranges that
are {+"Unassigned" (only for those registries that have a
bounded size),+} to be [-reserved-] {+"Reserved", used+} for
"Private Use", [-"Reserved", "Unassigned",-]
{+"Experimentation",+} etc. [-should-] {+SHALL+} be clearly
indicated.

I don't see the need for this. "should" seems good enough for
me. Also, the wording "any ranges that are ... etc."  implies to me
that the list provided are examples and if a category doesn't apply,
you don't include it.

In other words, I don't see a problem with the existing text that
warrants bothering with an errata.

But maybe I'm missing what the problem is.

Russ Housley  writes:

> Errata 2684 was entered against RFC 5226, "Guidelines for Writing an
> IANA Considerations Section in RFCs".  After discussion with one of
> the RFC authors and IANA staff, I rejected the errata.

> The errata author is saying that in many registries, there are no
> "unreserved" values.  For registries where there are a finite number
> of entries possible, the "unreserved" has a clear meaning.  For
> registries with an unbounded number of potential entries (such as
> media-types), the errata author is claiming that the "unreserved"
> label does not make sense.

> I'd like to know what others think about this errata.

> Russ
> ___
> 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

Errata against RFC 5226 rejected

[Russ Housley]

Errata 2684 was entered against RFC 5226, "Guidelines for Writing an IANA 
Considerations Section in RFCs".  After discussion with one of the RFC authors 
and IANA staff, I rejected the errata.

The errata author is saying that in many registries, there are no "unreserved" 
values.  For registries where there are a finite number of entries possible, 
the "unreserved" has a clear meaning.  For registries with an unbounded number 
of potential entries (such as media-types), the errata author is claiming that 
the "unreserved" label does not make sense.

I'd like to know what others think about this errata.

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

Re: Last Call: (DKIM Authorized Third-Party Signers) to Experimental RFC

[Douglas Otis]

I support adoption of dkim-atps as an experimental RFC.  It would have 
been clearer to use the term Author-Domain rather than Author.  Clearly, 
it is not the Author offering Authorization.


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

Re: [IETF] Travel/Attendees list FAQ

[Dave CROCKER]

On 12/8/2011 8:00 AM, Paul Hoffman wrote:
> A "collaborative page" can easily go sideways with contributors who don't
> understand the parameters of what is meant to be there

In the IETF?  Folks can misunderstand or getting carried away or both?

tsk, tsk.

But seriously, my general impression is that the comments and suggestion people 
post on the venue mailing list are typically pretty good.  So serious 
misinformation or misbehavior seem less likely than for a controversial working 
group, IMO.


We can rely on group review and reaction, for catching the problem you cite.



On 12/8/2011 8:36 AM, Paul Hoffman wrote:

What is the greater additional value of having to have someone who watches
the wiki and reverts changes over that same person being listed on the static
page as "if you have questions or suggestions about this page, please send
mail to"?


Huge.

They are fundamentally different models in terms of effort and responsiveness.

A reactive model -- watch and fix -- is much less effort, for a well-functioning
wiki than is a proactive model with highly constrained access.  The monitor is 
not in the critical path; they are not a gatekeeper who slows things down.


The reactive model distributes work among those motivated to perform it, rather
than concentrating everything onto the one or few people in charge.

If the reactive model fails, it is usually due to a dysfunctional group, in
which case the model isn't the problem.

d/



--

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

Re: Consensus Call (Update): draft-weil-shared-transition-space-request

[Chris Donley]

I don't want to go too far down this road, as it touches sensitive network
architecture issues, but I think you're thinking of this in terms of a
box.  Please think, instead, of a regional network with failover
capabilities and widely distributed customers.The aggregate need is
(at least) a /10 for a large number of providers.


Chris




On 12/8/11 12:35 AM, "Måns Nilsson"  wrote:

>The space is going to be reused several times anyway, and NAT (be it
>carrier, enterprise or SOHO) breaks pretty badly when session space
>is exhausted. It does not make sense to have much more than a, say,
>/16 behind each. (CGN is just NAT in a NEBS certified enclosure with an
>expensive support contract; the basic b0rkenedness remains.)

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

Re: [IETF] Travel/Attendees list FAQ

[David Morris]

On Thu, 8 Dec 2011, Paul Hoffman wrote:

> On Dec 8, 2011, at 8:31 AM, David Morris wrote:
> 
> > 
> > 
> > On Thu, 8 Dec 2011, Paul Hoffman wrote:
> > 
> >> On Dec 7, 2011, at 6:49 PM, Dave CROCKER wrote:
> >> 
> >>> Actually, I meant wiki according to its classic, collaborative meaning:
> >>> 
> >>>  
> >>> 
> >>> What you folks are describing is a web page, not really a wiki.
> >> 
> >> Exactly, and that is appropriate for something whose primary target is 
> >> organizations that are giving large amounts of money and time to the 
> >> IETF. A "collaborative page" can easily go sideways with contributors 
> >> who don't understand the parameters of what is meant to be there. In 
> >> many cases such as WGs, such sideways motion is fine; for a page whose 
> >> audience are often people who don't know about the IETF but are tasked 
> >> with deciding whether or not to give us significant financial support.
> > 
> > Perhaps, but in a wiki context repair is easy as any reasonable wiki
> > software will provide a history.  
> 
> What is the greater additional value of having to have someone who 
> watches the wiki and reverts changes over that same person being listed 
> on the static page as "if you have questions or suggestions about this 
> page, please send mail to "?

Difference is whether the community is better served by a fail open or
fail closed approach. I don't believe active watching is required. I think
the value of informed contributions without waiting for the real human
to review and provide the update. Even active review is less henious in
terms of work load in a context where we expect updates, even errors,
to be contributed with best intentions.

A Hybrid is another possiblity ... a 'fact' page with limited edit
could be the parent of the community edited content. Certainly not
an expensive experiment?

> 
> > In addition, at least one proposal
> > was that editing be limited to some form of registered users which
> > should also mean that abuse can be mitigated.
> 
> 
> Please note that I wasn't talking about abuse, I was talking about 
> misunderstanding. The latter seems very likely in our crowd, given our 
> propensity to mistake implementations for requirements, for example.



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

Re: [IETF] Re: [IETF] Travel/Attendees list FAQ

[Warren Kumari]

On Dec 8, 2011, at 11:00 AM, Paul Hoffman wrote:

> On Dec 7, 2011, at 6:49 PM, Dave CROCKER wrote:
> 
>> Actually, I meant wiki according to its classic, collaborative meaning:
>> 
>>  
>> 
>> What you folks are describing is a web page, not really a wiki.
> 
> Exactly, and that is appropriate for something whose primary target is 
> organizations that are giving large amounts of money and time to the IETF. A 
> "collaborative page" can easily go sideways with contributors who don't 
> understand the parameters of what is meant to be there.

Yes, and who have very little incentive to add stuff -- for example, look at 
the WG Chairs wiki ( http://wiki.tools.ietf.org/group/wgchairs/ )-- the 
subtitle is: "Everything a WG Chair Needs to Know but Was Afraid to Ask" . This 
site is far from useful[0], and hasn't been kept up to date (mnot made some 
changes ~ 6months ago, 22months ago Marc changed some email addresses, 2 years 
ago Tony changed a URL or two, most of the content is 5 years old). It is *far* 
from "everything a WG Chair needs to Know" -- something like this aimed at the 
event folk / organizers at a sponsor is not going to reflect well on the IETF 
and is not going to help lead to a successful meeting.

If we ended up with the opposite problem (everyone editing), things would be 
much much worse -- anyone reading this would assume that we are a bunch of 
childish, blithering idiots -- go read some previous Attendees lists and sample 
random threads (the "Hilton clock" thread: 
http://www.ietf.org/mail-archive/web/80attendees/current/msg00271.html , the 
"CD is a chocolate?" thread, the infamous Maastricht train threads) -- these 
are the sorts of things that folk might add the the Wiki -- it this really the 
image we want to be projecting?

Wiki's are a great idea, *for some things*, but (IMO) this is not one of them.

W


[0]: Yes, I *know* it's a wiki and I can / should go edit it myself, but, 
well

> In many cases such as WGs, such sideways motion is fine; for a page whose 
> audience are often people who don't know about the IETF but are tasked with 
> deciding whether or not to give us significant financial support.
> 
> --Paul Hoffman
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 

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

Re: [IETF] Travel/Attendees list FAQ

[Paul Hoffman]

On Dec 8, 2011, at 8:31 AM, David Morris wrote:

> 
> 
> On Thu, 8 Dec 2011, Paul Hoffman wrote:
> 
>> On Dec 7, 2011, at 6:49 PM, Dave CROCKER wrote:
>> 
>>> Actually, I meant wiki according to its classic, collaborative meaning:
>>> 
>>>  
>>> 
>>> What you folks are describing is a web page, not really a wiki.
>> 
>> Exactly, and that is appropriate for something whose primary target is 
>> organizations that are giving large amounts of money and time to the 
>> IETF. A "collaborative page" can easily go sideways with contributors 
>> who don't understand the parameters of what is meant to be there. In 
>> many cases such as WGs, such sideways motion is fine; for a page whose 
>> audience are often people who don't know about the IETF but are tasked 
>> with deciding whether or not to give us significant financial support.
> 
> Perhaps, but in a wiki context repair is easy as any reasonable wiki
> software will provide a history.  

What is the greater additional value of having to have someone who watches the 
wiki and reverts changes over that same person being listed on the static page 
as "if you have questions or suggestions about this page, please send mail to 
"?

> In addition, at least one proposal
> was that editing be limited to some form of registered users which
> should also mean that abuse can be mitigated.


Please note that I wasn't talking about abuse, I was talking about 
misunderstanding. The latter seems very likely in our crowd, given our 
propensity to mistake implementations for requirements, for example.

--Paul Hoffman

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

Re: [IETF] Travel/Attendees list FAQ

[David Morris]

On Thu, 8 Dec 2011, Paul Hoffman wrote:

> On Dec 7, 2011, at 6:49 PM, Dave CROCKER wrote:
> 
> > Actually, I meant wiki according to its classic, collaborative meaning:
> > 
> >   
> > 
> > What you folks are describing is a web page, not really a wiki.
> 
> Exactly, and that is appropriate for something whose primary target is 
> organizations that are giving large amounts of money and time to the 
> IETF. A "collaborative page" can easily go sideways with contributors 
> who don't understand the parameters of what is meant to be there. In 
> many cases such as WGs, such sideways motion is fine; for a page whose 
> audience are often people who don't know about the IETF but are tasked 
> with deciding whether or not to give us significant financial support.

Perhaps, but in a wiki context repair is easy as any reasonable wiki
software will provide a history.  In addition, at least one proposal
was that editing be limited to some form of registered users which
should also mean that abuse can be mitigated.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [IETF] Travel/Attendees list FAQ

[Paul Hoffman]

On Dec 7, 2011, at 6:49 PM, Dave CROCKER wrote:

> Actually, I meant wiki according to its classic, collaborative meaning:
> 
>   
> 
> What you folks are describing is a web page, not really a wiki.

Exactly, and that is appropriate for something whose primary target is 
organizations that are giving large amounts of money and time to the IETF. A 
"collaborative page" can easily go sideways with contributors who don't 
understand the parameters of what is meant to be there. In many cases such as 
WGs, such sideways motion is fine; for a page whose audience are often people 
who don't know about the IETF but are tasked with deciding whether or not to 
give us significant financial support.

--Paul Hoffman

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

Re: Consensus Call (Update): draft-weil-shared-transition-space-request

[Ray Bellis]

On 5 Dec 2011, at 18:08, Noel Chiappa wrote:

> I hear you. However, after thinking about it for a while, I still think we
> ought to include a chunk of 240/ space _as well as_ some 'general use' space
> (be it a /10 of that, or whatever).

+1

Ray

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

Re: Consensus Call (Update): draft-weil-shared-transition-space-request

[Daryl Tanner]

Hi Ron

On 3 December 2011 22:06, Ronald Bonica  wrote:

> Folks,
>
> On Thursday, December 1, the IESG deferred its decision regarding
> draft-weil-shared-transition-space-request to the December 15 telechat. The
> decision was deferred because:
>
> - it is difficult. (We are choosing between the lesser of two evils.)
> - a lively discussion on this mailing list has not yet converged
>
> Several topic have become intertwined in the mailing list discussion,
> making it difficult to gauge community consensus. Further discussion of the
> following topics would help the IESG to gauge consensus:
>
> - Is the reserved /10 required for the deployment of CGN?
>

The shared /10 is required for the deployment of NAT444. This ensures a
standardised, consistent way to identify CGN internal addressing,
irrespective of service provider. This also provides the lowest risk of
address collision with existing networks.

CGN is a generic term, and in some cases 1918 space can be used - for
example, where the CPE is an end-device (single host) that is not providing
any additional LAN connectivity, eg mobile devices.



>
> - What is the effect of burning 4 million IPv4 addresses on the exhaustion
> of IPv4?
>

The impact of using a single /10 for CGN/NAT444 is far less than each ISP
assigning their own dedicated block. Large ISPs would consume a /10 each
for this purpose.



>
> - Can alternative /10s be used?
>

The alternatives (discussed) are:
1. RFC1918 space - I do not see that the inside addressing in NAT444 is
legitimate use for this space. It is defined as "Address allocation for
Private Internets", which ISP customer connectivity is not.

2. 240/4 - I agree that this block should be released for unicast use,
however for CGN/NAT444 it is not 'fit for purpose' for use with ALL
existing CPE and network hardware.

Perhaps a separate I-D is required to release the 240/4 address block for
future use, however this should not be confused with the immediate
requirement.

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

Re: Gen-ART Combined Last Call and Telechat Review of draft-ietf-tcpm-rfc1948bis-01

[Fernando Gont]

Hi, Ben,

Thanks so much for your review! (and my appologies for the delay in my
response). PLease find my comments inline...


On 11/01/2011 04:55 PM, Ben Campbell wrote:

> Minor issues:
> 
> -- section 3, paragraph after ISN formula: "It is vital that F not be
> computable…"
> 
> If it's vital for security reasons, it seems like this would be
> worthy of normative language.

Agreed. (good grief!)



> -- Appendix B, Removal of "A Common TCP Bug" section:
> 
> Can you comment on why the section was removed?

Yes: it was argued that this information was historical data, and that
if anybody wanted/needed to take a look, they could look at the original
RFC1948.

FWIW, I would have left this section in... but the wg had a different
opinion...



> Nits/editorial comments:
> 
> -- abstract
> 
> The abstract should explicitly mention the update to RFC793

Done.



> -- section 1, 2nd paragraph:
> 
> Please expand ISN on first mention

Done.



> -- informative references:
> 
> Is there any way to avoid orphaning the last reference fragment? It's
> confusing to find half a reference at the top of the next page.

I'm sure the RFC-Editor will take care of this.

P.S.: (All my "done", "fixed", etc., are subject to the documents
shepard's agreement ;-) )

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



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