from:"Brian E Carpenter"

I support this too.

Regards
   Brian Carpenter

On 10/08/2012 23:55, Bob Hinden wrote:
 I support the IETF and IAB chairs signing document.
 
 Bob
 
 On Aug 10, 2012, at 8:19 AM, IETF Chair wrote:
 
 The IETF Chair and the IAB Chair intend to sign the Affirmation
 of the Modern Global Standards Paradigm, which can be found
 here:

 http://www.ietf.org/proceedings/84/slides/slides-84-iesg-opsplenary-15.pdf

 An earlier version was discussed in plenary, and the IAB Chair called
 for comments on the IETF mail list.  This version includes changes
 that address those comments.

 Th IETF 84 Administrative plenary minutes have been posted, so that
 discussion can be reviewed if desired.  The minutes are here:

 http://www.ietf.org/proceedings/84/minutes/minutes-84-iesg-opsplenary

 On 8 August 2012, the IEEE Standards Association Board of Governors
 approved this version of the document.  The approval process is
 underway at the W3C as well.

 The IETF Chair and the IAB Chair intend to sign the Affirmation in the
 next few weeks. Please send strong objections to the i...@iab.org
 and the ietf@ietf.org mailing lists by 2012-08-24.

 Thank you,
  Russ Housley
  IETF Chair
 
 .

Re: management granularity (Re: Meeting lounges at IETF meetings)

On 11/08/2012 14:07, JOHNSON, ALASTAIR (ALASTAIR) wrote:
 There were 10 participants from Australia and 4 participants from New
 Zealand at the last IETF meeting.  There was interest to have the IETF in
 New Zealand.  I guess that it was considered as difficult to convince the
 cookie-eating mob that it was a good location. 
 
 I understand that New Zealand was felt to be too expensive[1] and the travel 
 was too far for many[2]. NZ also suffers from a lack of conference facilities 
 that are functional *and* have suitable accommodation near them to fit the 
 IETF size. 

The venue that was actually proposed was big enough (I did the maths)
and surrounded by hotels. Travel cost and duration was an issue, for
sure.

   Brian

 As much as I'd like to have NZ as a venue, since I could visit my family...
 
 aj
 A New Zealander, but not living in NZ. Vaguely affiliated with people who 
 looked into hosting IETF in NZ.
 [1] NZ is surprisingly expensive for hotel accommodation in the major cities, 
 and transport can be expensive or difficult. Flights can also be difficult 
 since there isn't mass competition into the country unless you're trying to 
 jump the Tasman.
 [2] 3 hours to East Cost AU, 10+ hours to Asia[3], 13+ hours to US, 24+ hours 
 to Europe. Travel times would really hurt here.
 [3] For the bits of Asia that are directly connected (JP, SG, HK, CN, KR). If 
 you need to connect (e.g. India) you could be looking at 20+ hours too.

Re: Last Call: Modern Global Standards Paradigm

On 11/08/2012 10:39, Alessandro Vesely wrote:
 I wish to thank Phillip and Eric for their illuminating comments.
 
 However, I'm still not clear on the role that great powers may play in
 the standards development and deployment, compared to that of vested
 interests.  

Traditionally, and still in some countries, the telecommunications
monopolist *is* the government, so defending the monopoly is directly
in the government's financial interest. In other countries, where
there's still a de facto monopoly, that monopolist is very good at
political lobbying. So in both those types of country, the vested
interest drives the government position. Add that to the governments
that want central control and/or monitoring of information, and you
get a strong bloc of political support for standards and regulations
that support monopoly, control, and eavesdropping.

Brian

Re: VS: Re: [IAB] Last Call: Modern Global Standards Paradigm

On 11/08/2012 15:41, Dave Crocker wrote:
 
 Aihe: Re: [IAB] Last Call: Modern Global Standards Paradigm
 Lähettäjä: Eggert, Lars l...@netapp.com
 ...
 (I'd even co-sign for the IRTF, but I think that isn't really
 appropriate in this case.)
 
 
 The for the IRTF underscores a possible concern in the current situation.
 
 The perception will certainly be that the IAB and IETF chairs' signature
 do represent the support of the IETF.
 
 But we are a consensus-oriented group and we have not had anything that
 even hints at a consensus-oriented process to authorize that
 representation.

Dave,

I wasn't in Vancouver, nor even listening to the audio stream, so I can't
comment on what happened there. However, the discussion here (e.g. on
the ITU-T Dubai Meeting thread) and the previous opportunity to comment
on the proposed statement, which has resulted in changes, strikes me as
an open discussion of the kind we expect in the IETF. When the goal
is agreed wording between several organisations, and it seems clear
that the two chairs are representing the ethos of the IETF in the
discussion, I don't see how we can reasonably ask for more in the
time available.

Brian

Re: ITU-T Dubai Meeting

2012-08-08 Thread Brian E Carpenter

On 08/08/2012 06:30, Doug Barton wrote:
 On 08/07/2012 10:19 PM, Martin Rex wrote:
 Mark Andrews wrote:
 In message 5021742a.70...@dougbarton.us, Doug Barton writes:
 On 08/07/2012 00:46, Martin Rex wrote:
 IPv6 PA prefixes result in that awkward renumbering.
 Avoiding the renumbering implies provider independent
 network prefix.
 ULA on the inside + https://tools.ietf.org/html/rfc6296
 If you are changing your external connection you may as well just use
 ULA + PA.  The DNS needs to be updated in either case, the firewall needs
 to be updated in either case.
 And what about running apps and network connections in the connected state?
 
 If they are connected external to your network then obviously they would
 have to be restarted ... but then you know that already. :)

And any mission-critical application that can't survive a disconnect and
reconnect is badly broken anyway. I've never understood why session survival
was so highly rated; this has vastly complicated every discussion of
multihoming for many years.

Brian

 
 If PI everywhere were a feasible strategy at this time, I'd be first
 in line. But it isn't, so I think it's worthwhile discussing how we can
 do what we _can_ do, best.

Re: ITU-T Dubai Meeting

2012-08-07 Thread Brian E Carpenter

On 06/08/2012 23:02, Martin Rex wrote:
 Steven Bellovin wrote:
 Randy Bush wrote:
 whatever the number of address bits, if it is fixed, we always run out.
 memory addressing has been a cliff many times.  ip addressing.  ...
 Yup.  To quote Fred Brooks on memory address space: Every successful
 computer architecture eventually runs out of address space -- and I heard
 him say that in 1973.
 
 I'm wondering what resource shortage would have happened if IPv6
 had been massively adopted 10 years earlier, and whether we would have
 seen the internet backbone routers suffer severely from the size
 of the routing tables, if every single home customer (DSL subscriber)
 would have required a provider-independent IPv6 network prefix rather
 than a single, provider-dependent IPv4 IP Address.

That was never a likely scenario (and still isn't). PA prefixes are still
the norm for mass-market IP, regardless of version number.

 Brian

Re: ITU-T Dubai Meeting

2012-08-07 Thread Brian E Carpenter

Martin,

As far as the mass market goes, multiple prefixes and renumbering are a fact of 
life.
See the MIF and HOMENET WGs for more.

As far as enterprise networks go, renumbering is rather undesirable but 
sometimes
inevitable, see 6RENUM.

Regards
   Brian

On 07/08/2012 08:46, Martin Rex wrote:
 Brian E Carpenter wrote:
 [ Charset UTF-8 unsupported, converting... ]
 On 06/08/2012 23:02, Martin Rex wrote:
 Steven Bellovin wrote:
 Randy Bush wrote:
 whatever the number of address bits, if it is fixed, we always run out.
 memory addressing has been a cliff many times.  ip addressing.  ...
 Yup.  To quote Fred Brooks on memory address space: Every successful
 computer architecture eventually runs out of address space -- and I heard
 him say that in 1973.
 I'm wondering what resource shortage would have happened if IPv6
 had been massively adopted 10 years earlier, and whether we would have
 seen the internet backbone routers suffer severely from the size
 of the routing tables, if every single home customer (DSL subscriber)
 would have required a provider-independent IPv6 network prefix rather
 than a single, provider-dependent IPv4 IP Address.
 That was never a likely scenario (and still isn't). PA prefixes are still
 the norm for mass-market IP, regardless of version number.
 
 
 IPv6 PA prefixes result in that awkward renumbering.
 Avoiding the renumbering implies provider independent
 network prefix.
 
 With IPv4, you would have typically keept your IPv4 network address
 (the old class A, B  C from early 199x) even when changing network
 providers.
 
 
 To me, IPv6 PA prefixes look like a pretty useless feature
 (from the customer perspective).  Either you want an provider-independent
 prefix to avoid the renumbering when changing providers,
 or you want some level of privacy protection and therefore
 a fully dynamic temporary DHCP-assigned IPv6 address
 (same network prefix for 1+ customers of the ISP)
 and for use with NAT (again to avoid the renumbering).
 
 IPv6 renumbering creates huge complexity without value (for the customer).
 
 -Martin

Re: Basic ietf process question ...

2012-08-03 Thread Brian E Carpenter

On 02/08/2012 19:17, Robert Raszuk wrote:
 Hi Brian,
 
 Perhaps we understand a different thing by xml schema As example what
 I had in mind when asking this question was the example from Appendix
 A of http://tools.ietf.org/html/draft-marques-l3vpn-schema-00 where
 while perhaps not yet complete it does provide decent representation of
 one of the popular service today.

There are certainly cases where systematic metadata are useful; I can't judge
whether VPN configuration is one of them, but I can easily believe it. In such
a case, I suppose XML is as good a tool as ASN.1, ABNF or whatever else
you might choose.

 That's what I had mind asking why such appendix isn't a mandatory part
 of each new protocol extension.

That's an enormous leap that I just don't understand. Most protocols don't
need that sort of configuration complexity.

 It has very little to do with Web Services you may be referring to.

Yes it does. It's exactly because of a doctrinaire approach that whatever
it is, it should be represented by an XML schema, that WS-splat became
such a horribly complex matter.

Again: no problem with creating XML schemata where they are useful. But
making them mandatory would be just as bad as making MIB modules mandatory,
IMHO.

Brian

 
 Many thx,
 R.
 
 I think anyone with intimate experience of the Web Services standards
 experiment (trying to use XML as if it was a Turing machine) would have
 extreme doubts about any proposal to impose such a requirement.

 It was not for no reason that many people came to refer to the Web
 Services family of standards as WS-splat. The words small and
 xml schema don't really belong together,

 Regards
 Brian Carpenter

 On 02/08/2012 18:12, Robert Raszuk wrote:
 Hi Dan,

 We should be talking
 nowadays about a toolset rather than one tool that fits all.

 Just to clarify what I asked about .. I am not looking for a single tool
 or single protocol to be used to configure everything.

 I am asking for small building block like xml schema (or something
 similar) to be part of each new IETF proposal or protocol change. IMHO
 only that can allow any further more fancy abstractions and tools to be
 build and used in practice.

 Best regards,
 R.



 Hi,

 The OPSAWG/OPSAREA open meeting this afternoon has an item on the
 agenda
 concerning the revision of RFC1052 and discussing a new architecture
 for
 management protocols.


 My personal take is that no one protocol, or one data modeling language
 can match the operational requirements to configure and manage the wide
 and wider range of hosts, routers and other network devices that are
 used to implement IP networks and protocols. We should be talking
 nowadays about a toolset rather than one tool that fits all. However,
 this is a discussion that just starts.

 Regards,

 Dan




 -Original Message-
 From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf
 Of
 Robert Raszuk
 Sent: Thursday, August 02, 2012 7:25 PM
 Cc: ietf@ietf.org
 Subject: Basic ietf process question ...

 All,

 IETF documents have number of mandatory sections .. IANA Actions,
 Security Considerations, Refs, etc ...

 Does anyone have a good reason why any new protocol definition or
 enhancement does not have a build in mandatory XML schema section
 which would allow to actually use such standards based enhancement in
 vendor agnostic way ?

 There is a lot of talk about reinventing APIs, building network wide
 OS
 platform, delivering SDNs (whatever it means at any point of time for
 one) ... but how about we start with something very basic yet IMHO
 necessary to slowly begin thinking of network as one plane.

 I understand that historically we had/still have SNMP however I have
 never seen this being mandatory section of any standards track
 document.
 Usually SNMP comes 5 years behind (if at all) making it obsolete by
 design.

 NETCONF is great and very flexible communication channel for
 provisioning. However it is sufficient to just look at number of ops
 lists to see that those who tried to use it quickly abandoned their
 efforts due to complete lack of XML schema from each vendor they
 happen
 to use or complete mismatch of vendor to vendor XML interpretation.

 And while perhaps this is obvious I do not think that any new single
 effort will address this. This has to be an atomic and integral part
 of
 each WG's document.

 Looking forward for insightful comments ...

 Best,
 R.

Re: ITU-T Dubai Meeting

2012-08-03 Thread Brian E Carpenter


On 02/08/2012 21:30, Steven Bellovin wrote:
 On Aug 2, 2012, at 1:24 PM, David Conrad wrote:
 
 On Aug 2, 2012, at 11:44 AM, j...@mercury.lcs.mit.edu (Noel Chiappa) wrote:
 we should instead focus on the ways that the technical architecture of
 the Internet creates control points that are vulnerable to capture and
 consider ways in which those control points can be made capture-proof.
 Agreed.
 The challenge of course is that one of the simple/efficient mechanisms to 
 implement desirable features (e.g., security, scalability, manageability) is 
 to create hierarchies, but those very hierarchies provide control points 
 that can (at least in theory) be captured.  The DNS root is one such, the 
 proposed RPKI root is another.  Perhaps a variation of the Software 
 Engineering Dilemma (fast, good, cheap: pick two) applies to Internet 
 architecture: secure, scalable, manageable: pick two?

 If the ITU-T wants to also be in the business of handing out IPv6
 address names then give then a /21 or a /16 and tell them to go
 party.
 I don't think this is what the ITU is after.  My impression is that the ITU 
 is arguing that member states should get the /whatever directly.

 I basically agree. It could have negative impacts on the routing, by 
 impacting
 route aggregatability, but it can hardly be worse that those bletcherous PI
 addresses, so if it makes them happy to be in charge of a large /N, why not?
 I believe the routing scalability risk lies not in the allocation body, but 
 rather the policies imposed around the allocations.  That is, imagine a 
 world of 200+ National Internet Registries instead of 5 Regional Internet 
 registries.  If the government behind an NIR then decides that to use the 
 Internet in their country, you must use addresses allocated by the NIR of 
 that country, you then run the risk of having 200+ prefixes for each entity 
 that operates globally.  This risk could be addressed if it didn't matter 
 where you get your addresses, however that isn't true with the existing 
 model and there are political pressures that would likely ensure that it 
 would not be true in the NIR model.
 
 
 It also implies entry into a country through a few official gateways/exchange 
 points -- that way, there are only ~200 entries plus your own country's that 
 you need in your RIB...  (Telecom used to be that way -- PTTs and other 
 monopolies (e.g., ATT) loved it.)

Exactly. It is intended to defeat the Internet's historical growth model
of independence from national administrations and monopolies, by imposing
a geographical addressing scheme. Since the Internet actually works with
a topological addressing scheme, the effect is to force the topology
to be congruent with the geography. If you want central control, that's
a desirable result.

It isn't a harmless concession. We've been playing whack-a-mole against
this for a number of years now.

   Brian Carpenter

Re: Affirmation of the Modern Global Standards Paradigm

2012-08-02 Thread Brian E Carpenter

Hi,

In general this seem like a Good Thing. However, I have a slight confusion
caused by these two extracts:

 Openness. Standards processes are open to all interested and informed
 parties.

...

 4. Availability. Standards are made accessible to all for implementation and
 deployment under fair terms. Given market diversity, fair terms may vary from
 royalty-free (especially where open source is commonplace) to fair, 
 reasonable,
 and non-discriminatory terms (FRAND).

Open in standards parlance is used in (at least) two ways - open process,
as in the first extract, and open publication.

I'd like to see the Availability clause changed to Open Availability.
But then I'm confused - the text seems to mix up dependency on patents
with the question of access to the text of the standard. I think these two
aspects need to be separated. Then we'd get something like:

4. Open Availablity. The text of standards is made accessible to all,
free of charge or at low cost.

5. Implementability. Standards may be implemented and deployed under fair terms.
Given market diversity, fair terms may vary from royalty-free (especially where
open source is commonplace) to fair, reasonable, and non-discriminatory terms 
(FRAND).

Regards
   Brian Carpenter

On 02/08/2012 03:19, IAB Chair wrote:
 The IAB, IESG, IEEE-SA and W3C have been developing an
 http://www.ietf.org/proceedings/84/slides/slides-84-iesg-opsplenary-4.pdf
 Affirmation of the Modern Global Standards Paradigm.  Comments may be sent
 to i...@iab.org.

Re: Basic ietf process question ...

2012-08-02 Thread Brian E Carpenter

I think anyone with intimate experience of the Web Services standards
experiment (trying to use XML as if it was a Turing machine) would have
extreme doubts about any proposal to impose such a requirement.

It was not for no reason that many people came to refer to the Web
Services family of standards as WS-splat. The words small and
xml schema don't really belong together,

Regards
   Brian Carpenter

On 02/08/2012 18:12, Robert Raszuk wrote:
 Hi Dan,
 
 We should be talking
 nowadays about a toolset rather than one tool that fits all.
 
 Just to clarify what I asked about .. I am not looking for a single tool
 or single protocol to be used to configure everything.
 
 I am asking for small building block like xml schema (or something
 similar) to be part of each new IETF proposal or protocol change. IMHO
 only that can allow any further more fancy abstractions and tools to be
 build and used in practice.
 
 Best regards,
 R.
 
 
 
 Hi,

 The OPSAWG/OPSAREA open meeting this afternoon has an item on the agenda
 concerning the revision of RFC1052 and discussing a new architecture for
 management protocols.


 My personal take is that no one protocol, or one data modeling language
 can match the operational requirements to configure and manage the wide
 and wider range of hosts, routers and other network devices that are
 used to implement IP networks and protocols. We should be talking
 nowadays about a toolset rather than one tool that fits all. However,
 this is a discussion that just starts.

 Regards,

 Dan




 -Original Message-
 From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf
 Of
 Robert Raszuk
 Sent: Thursday, August 02, 2012 7:25 PM
 Cc: ietf@ietf.org
 Subject: Basic ietf process question ...

 All,

 IETF documents have number of mandatory sections .. IANA Actions,
 Security Considerations, Refs, etc ...

 Does anyone have a good reason why any new protocol definition or
 enhancement does not have a build in mandatory XML schema section
 which would allow to actually use such standards based enhancement in
 vendor agnostic way ?

 There is a lot of talk about reinventing APIs, building network wide
 OS
 platform, delivering SDNs (whatever it means at any point of time for
 one) ... but how about we start with something very basic yet IMHO
 necessary to slowly begin thinking of network as one plane.

 I understand that historically we had/still have SNMP however I have
 never seen this being mandatory section of any standards track
 document.
 Usually SNMP comes 5 years behind (if at all) making it obsolete by
 design.

 NETCONF is great and very flexible communication channel for
 provisioning. However it is sufficient to just look at number of ops
 lists to see that those who tried to use it quickly abandoned their
 efforts due to complete lack of XML schema from each vendor they
 happen
 to use or complete mismatch of vendor to vendor XML interpretation.

 And while perhaps this is obvious I do not think that any new single
 effort will address this. This has to be an atomic and integral part
 of
 each WG's document.

 Looking forward for insightful comments ...

 Best,
 R.

Re: I-D Action: draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt

2012-07-31 Thread Brian E Carpenter

Loa,

I can't speak for Scott, but I think the problem arises if any
IANA assignments are needed, regardless of RFC status. That's
because RFC 2804 speaks of the process for creating and maintaining
IETF standards. IANA assignments are part of standards maintenance
(IMHO, of course).

Don't forget that 2804 *also* says

  - On the other hand, the IETF believes that mechanisms designed to
 facilitate or enable wiretapping, or methods of using other
 facilities for such purposes, should be openly described, so as to
 ensure the maximum review of the mechanisms and ensure that they
 adhere as closely as possible to their design constraints. The IETF
 believes that the publication of such mechanisms, and the
 publication of known weaknesses in such mechanisms, is a Good
 Thing.

So it's a delicate balance.

Brian

On 31/07/2012 11:40, Loa Andersson wrote:
 Scott,
 
 would you say that drafts aimed for experimental status are standards
 work.
 
 /Loa
 
 On 2012-07-30 18:33, Scott O Bradner wrote:
 2804 does not say not to talk about such things - or that such
 documents should
 not be published as RFCs  - 2804 says that the IETF will not do
 standards work
 in this area

 Scott

 On Jul 30, 2012, at 5:04 AM, Brian E Carpenter wrote:

 Under the long-standing IETF policy defined in RFC 2804, I trust
 we will not be discussing this draft, or
 draft-balaji-l2vpn-lawful-intercept-thru-label-dis, in the IETF.

 Regards
Brian Carpenter

 On 30/07/2012 09:26, internet-dra...@ietf.org wrote:
 A New Internet-Draft is available from the on-line Internet-Drafts
 directories.


 Title   : Label-based Provider-Provisioned Lawful
 Intercept for L3 VPNs
 Author(s)   : Shankar Raman
   Balaji Venkat Venkataswami
   Gaurav Raina
   Vasan Srini
   Bhargav Bhikkaji
 Filename:
 draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt
 Pages   : 12
 Date: 2012-07-30

 Abstract:
In models of Single-AS and inter-provider Multi- Protocol Label
Switching (MPLS) based Virtual Private Networks (VPNs) Lawful
Intercept is a key requirement. For example, MPLS-based Layer 3 VPN
models like VPLS and the like do not have any provider provisioned
methods of lawful intercept that are comprehensive, quick and
 easy to
provision from one single point. More particularly the auto-
provisioning of lawful intercept for all sets of streams travelling
between VPN sites and consequent re-direction of these streams to
 the
appropriate government network has not been covered without multiple
instances of having to configure the intercept at various points in
the network both in the Single-AS case and the Inter-Provider VPN
case.

this paper, we propose a technique which uses a set of pre-defined
labels called Lawful Intercept labels and a method for provisioning
lawful intercept amongst the various PE devices using these labels
both in the Single-AS and the inter-provider VPN cases. A single
point of configuration is the key to this idea. The intercepted
traffic is mirrored on a PE or a whole set of PEs or on all the PEs
participating in the VPN. A technique called the Domino-effect
provisioning of these Label-based Provider Provisioned Lawful
Intercept mechanism is also outlined.


 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-balaji-mpls-lawful-intercept-thru-label-dis


 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-balaji-mpls-lawful-intercept-thru-label-dis-00



 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/

 ___
 I-D-Announce mailing list
 i-d-annou...@ietf.org
 https://www.ietf.org/mailman/listinfo/i-d-announce
 Internet-Draft directories: http://www.ietf.org/shadow.html
 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Re: I-D Action: draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt

2012-07-30 Thread Brian E Carpenter

Under the long-standing IETF policy defined in RFC 2804, I trust
we will not be discussing this draft, or
draft-balaji-l2vpn-lawful-intercept-thru-label-dis, in the IETF.

Regards
   Brian Carpenter

On 30/07/2012 09:26, internet-dra...@ietf.org wrote:
 A New Internet-Draft is available from the on-line Internet-Drafts 
 directories.
 
 
   Title   : Label-based Provider-Provisioned Lawful Intercept for 
 L3 VPNs
   Author(s)   : Shankar Raman
   Balaji Venkat Venkataswami
   Gaurav Raina
   Vasan Srini
   Bhargav Bhikkaji
   Filename: 
 draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt
   Pages   : 12
   Date: 2012-07-30
 
 Abstract:
In models of Single-AS and inter-provider Multi- Protocol Label
Switching (MPLS) based Virtual Private Networks (VPNs) Lawful
Intercept is a key requirement. For example, MPLS-based Layer 3 VPN
models like VPLS and the like do not have any provider provisioned
methods of lawful intercept that are comprehensive, quick and easy to
provision from one single point. More particularly the auto-
provisioning of lawful intercept for all sets of streams travelling
between VPN sites and consequent re-direction of these streams to the
appropriate government network has not been covered without multiple
instances of having to configure the intercept at various points in
the network both in the Single-AS case and the Inter-Provider VPN
case.
 
this paper, we propose a technique which uses a set of pre-defined
labels called Lawful Intercept labels and a method for provisioning
lawful intercept amongst the various PE devices using these labels
both in the Single-AS and the inter-provider VPN cases. A single
point of configuration is the key to this idea. The intercepted
traffic is mirrored on a PE or a whole set of PEs or on all the PEs
participating in the VPN. A technique called the Domino-effect
provisioning of these Label-based Provider Provisioned Lawful
Intercept mechanism is also outlined.
 
 
 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-balaji-mpls-lawful-intercept-thru-label-dis
 
 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-balaji-mpls-lawful-intercept-thru-label-dis-00
 
 
 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/
 
 ___
 I-D-Announce mailing list
 i-d-annou...@ietf.org
 https://www.ietf.org/mailman/listinfo/i-d-announce
 Internet-Draft directories: http://www.ietf.org/shadow.html
 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Re: I-D Action: draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt

2012-07-30 Thread Brian E Carpenter

Yes, Scott, that is correct, sorry for my poor phrasing.

   Brian

On 30/07/2012 17:33, Scott O Bradner wrote:
 2804 does not say not to talk about such things - or that such documents 
 should
 not be published as RFCs  - 2804 says that the IETF will not do standards work
 in this area
 
 Scott
 
 On Jul 30, 2012, at 5:04 AM, Brian E Carpenter wrote:
 
 Under the long-standing IETF policy defined in RFC 2804, I trust
 we will not be discussing this draft, or
 draft-balaji-l2vpn-lawful-intercept-thru-label-dis, in the IETF.

 Regards
   Brian Carpenter

 On 30/07/2012 09:26, internet-dra...@ietf.org wrote:
 A New Internet-Draft is available from the on-line Internet-Drafts 
 directories.


 Title   : Label-based Provider-Provisioned Lawful Intercept for 
 L3 VPNs
 Author(s)   : Shankar Raman
  Balaji Venkat Venkataswami
  Gaurav Raina
  Vasan Srini
  Bhargav Bhikkaji
 Filename: 
 draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt
 Pages   : 12
 Date: 2012-07-30

 Abstract:
   In models of Single-AS and inter-provider Multi- Protocol Label
   Switching (MPLS) based Virtual Private Networks (VPNs) Lawful
   Intercept is a key requirement. For example, MPLS-based Layer 3 VPN
   models like VPLS and the like do not have any provider provisioned
   methods of lawful intercept that are comprehensive, quick and easy to
   provision from one single point. More particularly the auto-
   provisioning of lawful intercept for all sets of streams travelling
   between VPN sites and consequent re-direction of these streams to the
   appropriate government network has not been covered without multiple
   instances of having to configure the intercept at various points in
   the network both in the Single-AS case and the Inter-Provider VPN
   case.

   this paper, we propose a technique which uses a set of pre-defined
   labels called Lawful Intercept labels and a method for provisioning
   lawful intercept amongst the various PE devices using these labels
   both in the Single-AS and the inter-provider VPN cases. A single
   point of configuration is the key to this idea. The intercepted
   traffic is mirrored on a PE or a whole set of PEs or on all the PEs
   participating in the VPN. A technique called the Domino-effect
   provisioning of these Label-based Provider Provisioned Lawful
   Intercept mechanism is also outlined.


 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-balaji-mpls-lawful-intercept-thru-label-dis

 There's also a htmlized version available at:
 http://tools.ietf.org/html/draft-balaji-mpls-lawful-intercept-thru-label-dis-00


 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/

 ___
 I-D-Announce mailing list
 i-d-annou...@ietf.org
 https://www.ietf.org/mailman/listinfo/i-d-announce
 Internet-Draft directories: http://www.ietf.org/shadow.html
 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Re: Proposed IETF 95 Date Change

2012-07-21 Thread Brian E Carpenter

On 21/07/2012 02:30, Fred Baker (fred) wrote:
 On Jul 20, 2012, at 6:08 PM, Paul Hoffman wrote:
 
 As for the Ramadan issue: we've had IETF meetings during Jewish holidays a 
 few times, and folks dealt with it as best they can. If there are some 
 accommodations that can be made at any IETF meeting for different holidays 
 of major religions, I would bet that IETF Secretariat would be glad to hear 
 them.
 
 
 It comes down to adding them to the clash list...

(which is at http://www.ietf.org/meeting/clash-list.html)

And we know that if we did that, on top of all the other technical meetings
that we have to avoid, the result would be overconstrained and scheduling
would become impossible. IMNSHO we need to treat all religious constraints
alike, and in practice that means ignoring them. For practical reasons, we
can't ignore major holidays - not because some of them are religious, but
because they block up hotels and airlines.

Finding the least bad solution is always going to be a compromise, and
I thank the IAOC for continuing to plan several years ahead.

   Brian

Re: Feedback Requested on Draft Fees Policy

2012-07-20 Thread Brian E Carpenter

On 20/07/2012 14:07, IETF Administrative Director wrote:
 The IAOC is seeking community feedback on a proposed policy by the IAOC to 
 impose 
 fees to produce information and authenticate documents in response to 
 subpoenas and 
 other legal requests.

Do it. This will dissuade trivial requests and will be a drop in the ocean
of costs for serious lawsuits.

Don't forget to appropriately update http://iaoc.ietf.org/subpoena.html.

 Brian

Change in I-D announcement format

2012-06-13 Thread Brian E Carpenter

Did I miss an announcement of the change in format of
I-D announcement messages?

There's no longer a URL for the standard .txt format. That's
mildly annoying for me (extra time and extra mouse clicks)
and must be a nuisance for anyone who processes these messages
automatically.

At least, I would have expected a warning message about the change.

-- 
Regards
   Brian Carpenter

Re: registries and designated experts

2012-06-13 Thread Brian E Carpenter

John,

On 2012-06-12 19:38, John C Klensin wrote:
 
 --On Tuesday, June 12, 2012 19:13 +0100 Brian E Carpenter
 brian.e.carpen...@gmail.com wrote:
 
 The above is at odds with standardization.  The last reason
 does not apply for Expert review.
 I don't understand that statement. RFC 5226 says, in Section 2
 about Why Management of a Namespace May Be Necessary:

   A third, and perhaps most important, consideration concerns
 potentialimpact on the interoperability of unreviewed
 extensions.

 One of the specific considerations for designated experts in
 section 3.3 is

   - the extension would cause problems with existing
 deployed systems.

 It seems clear that interoperability is a primary concern for
 any expert review.
 
 Brian, Subramanian,
 
 I've with Barry on this.  The details of the expectations of an
 expert reviewer, including the thresholds for approval, should
 be specified in whatever document sets up the particular
 registry.  One size does not fit all; Expert Review is a
 designation of a mechanism and not a set of criteria.

I completely agree. My point was only that the baseline set by
RFC 5226 is clear that interoperability is a criterion. The
details vary case by case and should be written down.

I also agree with what I think Randy meant - the designated
expert shouldn't be afraid to say no (or yes) in dubious
cases; that's why we designate an expert...

Brian
 
 We should, IMO, do two things in this area:
 
 (1) When a document specifies Expert Review for a registry, it
 should be required to spell out the criteria the Expert is
 supposed to use, at least to the degree that isn't obvious.  If
 it doesn't, that should be grounds for DISCUSS until fixed.
 
 (2) If it turns out that an Expert for a particular registry is
 not behaving as people expect, part of the process for getting
 that fixed (or even complaining about it), should be to see if
 the registry-creating documents are clear about procedures and
 criteria.  If they are not, an effort to update those criteria
 would be a useful way to discuss the issues and not the
 individual expert.   Of course, Experts who knowingly violate
 clear criteria should be summarily fired -- but I think we can
 trust that to the IESG and note that it has almost never been
 necessary.
 
  john
 
 
 .

Re: registries and designated experts

2012-06-12 Thread Brian E Carpenter

On 2012-06-12 17:31, SM wrote:
 Hi Peter,
 At 07:19 12-06-2012, Peter Saint-Andre wrote:
 By my reading, the happiana discussions [1] over the 12+ months have
 led most participants to the conclusion that registration does not imply
 standardization, and that it's not the role of the designated expert to
 act as a gatekeeper with respect to the technical merits of the
 technologies that trigger registration requests. It might be good to
 have a wider discussion about the purpose of registries and the role of
 designated experts, but IMHO it's not correct to conclude that a
 technology is acceptable just because the designated expert didn't
 object to the registrations related to that technology.
 
 I'll +1 the above.
 
 In a recent review the path followed by the draft is Standards Action
 whereas the assignment policy is Expert Review.  Explaining to the
 authors that they should not use the assigned value isn't a worthwhile
 effort given that they have already been through the gate to get the
 value.  The Designated Expert did his job; that is to see that the
 requirements were met instead of acting as gatekeeper.  If you reject
 assignment requests people will find it simpler not to register the
 values.  If you accept the request people might consider that the
 specification is fine.
 
 The reasons provided for managing a namespace are:
 
   - prevent the hoarding of or unnecessary wasting of values
 
   - provide a sanity check that the request actually makes sense
 
   - interoperability issues
 
 The above is at odds with standardization.  The last reason does not
 apply for Expert review.

I don't understand that statement. RFC 5226 says, in Section 2 about
Why Management of a Namespace May Be Necessary:

  A third, and perhaps most important, consideration concerns potential
   impact on the interoperability of unreviewed extensions.

One of the specific considerations for designated experts in section 3.3
is

  - the extension would cause problems with existing deployed
systems.

It seems clear that interoperability is a primary concern for any
expert review.

Brian

Re: I-D Action: draft-hoffman-tao-as-web-page-00.txt

2012-06-11 Thread Brian E Carpenter

On 2012-06-10 17:23, Paul Hoffman wrote:
 On Jun 10, 2012, at 9:00 AM, Brian E Carpenter wrote:
 
 Oh, one thing I now realise is that the draft doesn't state that
 the editor (in deciding what changes to adopt) and the IESG
 (in approving an update) will of course do so by a normal IETF
 consensus process (presumably ad hoc last calls) and subject
 to appeal like anything else. This is so obvious in the IETF
 context that I didn't even notice that it wasn't stated.
 
 It is not what was intended.
 
 - There was no mention to me of ad hoc last calls, so I did not include 
 them in the draft. 

Well, that was presumably an oversight. The IETF always works by
a consensus process, afaik.

 
 - Is there an appeals process for the content of the various web pages 
 created by the IESG?

Yes. For many years there has been a presumption that the appeals
process in section 6.5 of RFC 2026 can be applied to *any* IESG action.
That being so, I suppose it isn't vital to write it down in every
document, but it makes things clearer.

Look, I'm not suggesting that either the editor or the IESG will
unilaterally put nonsense in the Tao. But the Tao can't be an exception
to the general principles of IETF process; that would be ironic, indeed.

  Brian

Re: I-D Action: draft-hoffman-tao-as-web-page-00.txt

2012-06-10 Thread Brian E Carpenter

This draft should formally obsolete RFC 4677. Otherwise, I think it's fine.

This doesn't need to be in the document, but having a fixed location for
the pending version might be good, e.g. http://www.ietf.org/draft-tao.html .

Regards
   Brian Carpenter

Re: I-D Action: draft-hoffman-tao-as-web-page-00.txt

2012-06-10 Thread Brian E Carpenter

Oh, one thing I now realise is that the draft doesn't state that
the editor (in deciding what changes to adopt) and the IESG
(in approving an update) will of course do so by a normal IETF
consensus process (presumably ad hoc last calls) and subject
to appeal like anything else. This is so obvious in the IETF
context that I didn't even notice that it wasn't stated.

The sentence that should state it belongs about here:
  The Tao
   has traditionally been an IETF consensus document, which means that
   the IESG has had the final say about what the Tao contained before it
   was sent to the RFC Editor.  Thus, the IESG should have final say for
   what the Tao says when it is a web page.

The IESG's final say is of course always in the context of determining
IETF consensus.

Regards
   Brian Carpenter

On 2012-06-10 11:54, Brian E Carpenter wrote:
 This draft should formally obsolete RFC 4677. Otherwise, I think it's fine.
 
 This doesn't need to be in the document, but having a fixed location for
 the pending version might be good, e.g. http://www.ietf.org/draft-tao.html .
 
 Regards
Brian Carpenter

Mission statement [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]

On 2012-05-31 07:22, Eliot Lear wrote:

...
   * I've been told by some that the Mission of the IETF is in some way
 out of date.  I don't know whether this is true, 

That sound like somebody's personal opinion, but it is still a BCP
and therefore still represents IETF consensus.

 but if it is, the
 reference should be removed.

I don't think so.

   Brian

Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]

On 2012-05-31 02:49, Peter Saint-Andre wrote:
 Overall I continue to think that this is a helpful document, as were its
 predecessors.
 
 That said, I would assume that many potential readers of this document
 are not native English speakers. Thus I suggest that the more colloquial
 words and phrases might best be changed to more standard English.

Have we any evidence that this is a problem for the community? The informal
style is one of the virtues of the Tao. I'd be sorry to lose it.

Maybe we can ask some of the people concerned, such as recent presenters
of the Newcomers tutorial in languages other than English.

Brian

ICANN relationship [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]

 3.2.4.  IANA (Internet Assigned Numbers Authority)
 
The core registrar for the IETF's activities is the IANA (see
http://www.iana.org).  Many Internet protocols require that someone
keep track of protocol items that were added after the protocol came
out.  Typical examples of the kinds of registries needed are for TCP
port numbers and MIME types.  The IAB has designated the IANA
organization to perform these tasks, and the IANA's activities are
financially supported by ICANN, the Internet Corporation for Assigned
Names and Numbers.  The IAB selected ICANN, and the IANA activities
are provided for free as specified in [RFC2860].

The phrase The IAB selected ICANN is, as the saying goes, economical with
the truth. The fact is that we had no choice at the time. Suggestion
for the last sentence:

  The IAB and the IETF established a Memorandum of Understanding with
  ICANN [RFC2860], under which the IANA services are provided for free
  to the IETF.

Nit:

 Editor is a separate job. Today, these jobs are preformed by

s/preformed/performed/



Regards
   Brian Carpenter

Re: Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]

On 2012-05-31 07:59, Dave Crocker wrote:
 
 On 5/31/2012 8:36 AM, Brian E Carpenter wrote:
 Have we any evidence that this is a problem for the community? The
 informal
 style is one of the virtues of the Tao. I'd be sorry to lose it.
 
 
 Let's separate use of colloquial language from overall writing style. It
 is possible to write in an informal style without using colloquialisms. 
 I could, for example, insert some side comment here that would be
 informal and lack colloquialisms.  By some measures, the preceding
 sentence is an example of exactly that...
 
 Colloquialisms are well known to impede understanding by non-native
 English speakers.
 
 So, do you have any evidence that this is /not/ a problem for that part
 of our community?

I actually have no evidence either way; that's why I suggested asking
some of them ;-)

   Brian

Re: Mission statement [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]

John,

On 2012-05-31 15:53, John C Klensin wrote:
 
 --On Thursday, May 31, 2012 07:31 +0100 Brian E Carpenter
 brian.e.carpen...@gmail.com wrote:
 
 On 2012-05-31 07:22, Eliot Lear wrote:

 ...
   * I've been told by some that the Mission of the IETF is in
   some way out of date.  I don't know whether this is true, 
 That sound like somebody's personal opinion, but it is still a
 BCP and therefore still represents IETF consensus.
 
 Brian,
 
 Regardless of how I feel about this particular case, I don't
 understand how to put your comment in context.  In particular,
 would you 
 
 * Assert that the IETF is so diligent about its process BCPs
 that any that have become out of date, overtaken by events, or
 otherwise irrelevant have been immediately and formally declared
 obsolete or historic?  I have better ways to spend my time at
 the moment, but I imagine that many members of the community
 could come up with lists of counterexamples rather quickly
 (perhaps starting from how long it took us to get automatic
 review out of RFC 2026).

True, but adding to what Scott Brim said, where is the evidence that the
mission statement is OBE? The comment I was responding to seemed
quite gratuitous.

 
 * When a document is revised (updated or obsoleted) omitting
 a reference that appeared in the earlier version requires a
 special consensus call rather than treating consensus on the new
 document, once achieved, as atomic?   Granted, the relatively
 new provisions requiring identification and explanation of what
 was obsoleted or updated are a step toward making sure that
 those participating in the consensus process are aware of what
 happened but (i) those provisions have, no far, not been
 extended to require a discussion of every changed reference and
 (ii) are not themselves in a BCP or other document that has been
 documented as achieving community consensus on the details.
 Independent of that BCP problem, would you advocate making each
 new document list all of the references to BCP or Standards
 Track documents that were not carried forward and identifying
 the reasons?

Certainly not, although there might be cases where it was
useful. (Since carrier pigeons have gone extinct, the mapping
to Avian Carriers has been removed from this specification.)

   Brian

Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC

John,

On 2012-05-31 16:19, John C Klensin wrote:
...
 Assuming Paul isn't planning to get this published as an RFC and
 then immediately retire from the IETF and that we don't have a
 delusion that this document will not need to be maintained and
 updated as things change, I propose the following:
 
 (1) Establish the Tao as a modified Wiki, complete with live
 HTML links to relevant documents and other relevant
 discussions.. Provide some mechanism for comments to the editor
 or even discussion that works better than the RFC Errata
 process.  Turn maintenance of that page over to a volunteer or
 two (ideally someone young enough to learn a lot from the
 process) or the Secretariat.   Before someone says cost,
 please calculate the costs to the community of an extended Last
 Call in which people debate details of wording.

+- some trivia such as avoiding the fuzziness of a wiki, isn't that
what http://www.ietf.org/tao.html already achieves?

I tend to agree with your suggestions below.

Brian

 
 (2) Appoint Paul as chair of an editorial committee with zero or
 more additional members to be appointed at his discretion
 subject to advice and consent of the IESG.  That committee gets
 to consider whether to make changes.  If they get it wrong, they
 are subject to the community's normal forms of abuse and, in
 principle, appeals.  That could add a bit of work for the IESG
 but I suggest only a bit and less than running a Last Call.
 
 (3) Replace/ obsolete RFC 4677 by a document modeled on RFC
 5000.  I.e., it should explain why we are maintaining the Tao as
 one or more web pages and should provide a durable pointer to
 how the web page can be found.
 
 just my opinion,
john

IANA [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]

On 2012-05-31 09:24, SM wrote:

...
 In Section 3.2.3:
 
   Approves the appointment of the IANA
 
 Isn't IANA more of a U.S. Government decision? 

The IAB decides who acts as the IETF's IANA. RFC 2860 again.

  Brian

Re: Long discussion about IETF on the Internet Governance Caucus mailing list

2012-05-28 Thread Brian E Carpenter

On 2012-05-28 16:51, Tim Bray wrote:
 Who are these people? -T

politicallyIncorrect
So far, fortunately, the Internet Governance Forum and its associated
talking shops add up to a no-op. The danger is always there that they
will persuade government reps in the ITU or other UN bodies to take
action that will damage the Internet.
/politicallyIncorrect

   Brian

 
 On Mon, May 28, 2012 at 8:34 AM, Stephane Bortzmeyer bortzme...@nic.fr 
 wrote:
 I believe it is relevant here since IETF is currently being discussed
 in depth on the Internet Governance Caucus mailing list (one of the
 biggest forums of the civil society about Internet governance).

 The thread is long and, for those who are not subscribed, can be found
 here on the Web:

 http://lists.igcaucus.org/arc/governance/2012-05/msg00380.html

 There are two things being discussed about the IETF:

 1) Does it do a good job of creating and promoting technical
 standards?

 2) If yes, can it be used as a model for Internet governance of
 other, more political, functions?

Re: Long discussion about IETF on the Internet Governance Caucus mailing list

2012-05-28 Thread Brian E Carpenter


On 2012-05-28 17:38, Stephane Bortzmeyer wrote:
 On Mon, May 28, 2012 at 05:20:10PM +0100,
  Brian E Carpenter brian.e.carpen...@gmail.com wrote 
  a message of 32 lines which said:
 
 So far, fortunately, the Internet Governance Forum 
 
 Hold on, the Internet Governance Caucus I was talking about (a civil
 society loosely connected group) is not the Internet Governance Forum
 (an intergovernmental body). 

I fully realise that, but when you look at the names of those active
in the caucus, it's clear that it exists to lobby the IGF.

As I understand it the IGF is a multi-stakeholder body, which is not
the same thing as an intergovernmental body, fortunately.

Brian
 
 The danger is always there that they will persuade government reps
 in the ITU or other UN bodies to take action that will damage the
 Internet.
 
 The main danger to the Internet comes from existing governments (and
 not only the repressive regimes), not from the UN or the ITU or an
 hypothetical UN-inspired organization
 http://www.internetgovernance.org/2012/05/24/threat-analysis-of-itus-wcit-part-1-historical-context/.
 .

Re: RFC 2119 terms, ALL CAPS vs lower case

2012-05-20 Thread Brian E Carpenter

On 2012-05-19 20:39, Ofer Inbar wrote:
...

  But don't change the rules.  2119 works well as is IMO.

Just to be clear about the current rules, 2119 makes it clear that
upper case keywords are optional (These words are often capitalized).
Indeed, numerous standards track documents don't use them.

Brian

Re: RFC 2119 terms, ALL CAPS vs lower case

2012-05-20 Thread Brian E Carpenter

On 2012-05-20 17:29, John C Klensin wrote:
 
 --On Sunday, May 20, 2012 07:53 +0100 Brian E Carpenter
 brian.e.carpen...@gmail.com wrote:
 
 On 2012-05-19 20:39, Ofer Inbar wrote:
 ...

  But don't change the rules.  2119 works well as is IMO.
 Just to be clear about the current rules, 2119 makes it clear
 that upper case keywords are optional (These words are often
 capitalized). Indeed, numerous standards track documents
 don't use them.
 
 Brian,
 
 I've been trying really hard to avoid this discussion, but I
 think the above is misleading.

My personal preference is to use RFC 2119, but if the IESG made
that into a rule without community consensus, I think it would
be wrong.

 
 In recent years, various IESG members have insisted that any
 IETF Track document that contains anything approximating
 conformance language include the 2119 reference and whatever the
 strict interpretation of the week is about caps, etc.  As Randy
 suggests, there have been signs of more nuance in the last IESG
 or two, but...
 
 The same problem applies to the other issue with 2119, which is
 that we have history for at least two different interpretations
 of those words, the ones in 2119 that are interpreted as
 necessary for interoperability and the ones in, e.g.,
 1122/1123 (Section 1.3.2 in the latter) which are requirements
 of the specification without binding those requirements to a
 particular reason.  From my point of view, the other difficulty
 with treating 2119 like Received Wisdom and a set of absolute
 requirements is that the interoperability criterion often makes
 no sense for what are perfectly reasonable requirements.  As an
 example drawn from 1123, a specification might reasonably say
 this option MUST be configurable because it is necessary to
 make things work in a plausible way even if that statement
 cannot be explicitly linked to won't interoperate unless it
 does.   But again, in recent years, some IESG members (and
 others) have insisted that only the 2119 definitions are
 permitted.
 
 The combination of the two is known in some quarters as writing
 technically poor or deficient specs in the interest of clear
 conformance to procedures.  At least historically, that was a
 trap the IETF tried to avoid.

Yes, it would be sad if the IETF were no longer to allow itself to
apply common sense rather than rules.

   Brian

 
 john

Re: RFC 2119 terms, ALL CAPS vs lower case

2012-05-19 Thread Brian E Carpenter

On 2012-05-18 19:27, Randy Bush wrote:
 I recommend an errata to RFC 2119: These words MUST NOT appear in a
 document in lower case.
 
 first, that is not an erratum, it is a non-trivial semantic change.
 
 second, do we not already have enough problems being clear and concise
 without removing common words from our language?

May I say +1?

Very seriously - after all that has been said on this thread, I see
no reason to change anything. Authors and the RFC Editor can create
unambiguous language with a bit of thought. There is an erratum
in 2119 (NOT RECOMMENDED is not mentioned in the recommended
boilerplate) but we know how to deal with that.

A strong argument against updating RFC 2119 is the fact that it's
one of the most cited RFCs *outside* the RFC series. Several other
SDOs commonly cite RFC 2119 and use its terminology. If it was
a protocol, we'd be proud of its success, but that makes changing
it a source of unintended consequences.

   Brian

Re: RFC 2119 terms, ALL CAPS vs lower case

2012-05-16 Thread Brian E Carpenter

On 2012-05-16 18:53, Peter Saint-Andre wrote:
 On 5/16/12 9:58 AM, Sam Hartman wrote:

...
 I'll note that  in my normal reading mode I  do not distinguish case,
 but even so I find the ability to use may and should in RFC text without
 the 2119 implications valuable.

Agreed. But as a gen-art reviewer, I have several times had to ask
authors whether a particular lower case may was intended to be normative
or normal English. Authors must be fastidious about this.

 Your mileage may (or is that MAY?) vary, but to forestall confusion I've
 settled on the practice of using can and might instead of lowercase
 may, ought to and is suggested to instead of lowercase should,
 and needs to or has to instead of lowercase must (etc.). I'm not
 saying that anyone else SHOULD or MUST use that convention, but you
 might consider it in your own spec-writing.

It is indeed very important not to use may when it's ambiguous.
It may rain today is fine; you may leave now is not (I can think
of three different meanings). In RFC2119-talk, you MAY leave now
only has one meaning.

   Brian

Re: Last Call: draft-farrresnickel-ipr-sanctions-05.txt (Sanctions Available for Application to Violators of IETF IPR Policy) to Informational RFC

2012-05-10 Thread Brian E Carpenter

On 2012-05-10 03:18, Pete Resnick wrote:
 On 5/9/12 6:40 PM, Fred Baker wrote:
 
 I don't want participants to think that they can't bring up the issue
 of violation without some sort of burden of proof.
  
 Hmm.

 I'm concerned about people bringing baseless accusations, as yet
 another way to DOS a WG with IPR. If a person believes that there is a
 violation that is worthy of the name, they should probably see to it
 that it gets discussed, but I don't see how they make that
 determination without having at least some data or report that can be
 verified. If someone in my working group brings such an accusation to
 me, trust me, the first question I am going to ask is why do you
 believe that. If the answer is can't you see they have shifty eyes,
 it will end there. I'm looking for at minimum that a named party has
 evidence to support it.
 
 I completely agree. That's why I asked that we figure out some text that
 does both things: Indicate that it's OK to say that you believe someone
 crossed the line and explain your reasons for that belief, but not
 require that it be a proven fact before you can even broach the subject.
 I can see how the current text might be too lax, but I thought Brian's
 text was too stringent. Looking for a happy medium.

Fair enough. I can't agree with SM though - as for appeals under RFC 2026,
the person bringing up an issue really has to provide a factual summary,
exactly to avoid witch hunts. It can be very short:

   Hi, I noticed that US Patent 12345 was filed in March 2010, and
   draft-blo-foobar was posted that June, and Jo Blo was an author
   of both. It looks as if they describe the same method, so why
   wasn't there an IPR disclosure in 2010? Would the WG Chairs consider
   sanctions against Jo Blo appropriate?

Possible text:

   Any IETF participant can draw attention to an apparent violation
   of the IETF's IPR policy.  This can be done by sending email to
   the appropriate IETF mailing list, including a short summary of
   the known facts and, optionally, a call for sanctions to be
   applied.

   Brian

Re: Last Call: draft-farrresnickel-ipr-sanctions-05.txt (Sanctions Available for Application to Violators of IETF IPR Policy) to Informational RFC

2012-05-09 Thread Brian E Carpenter

I'd like to be reassured that this has been carefully reviewed
by the IETF counsel and the IETF Trust. In particular I would
be interested in its possible interaction with the IETF's
liability insurance.

Any IETF participant can call for sanctions to be applied to anyone
they believe has violated the IETF's IPR policy. This can be done by
sending email to the appropriate IETF mailing list.  

That seems reasonable, but publishing such a belief without having the
wording checked by a libel lawyer might be risky. I think the draft
should state that a call for sanctions should be based on factual
evidence and not on belief. How about

   Any IETF participant can call for sanctions to be applied to anyone
   shown to have violated the IETF's IPR policy.  This can be done by
   sending email to the appropriate IETF mailing list, including a
   a short summary of the relevant facts and events.

Regards
   Brian Carpenter

On 2012-05-07 22:56, The IESG wrote:
 The IESG has received a request from an individual submitter to consider
 the following document:
 - 'Sanctions Available for Application to Violators of IETF IPR Policy'
   draft-farrresnickel-ipr-sanctions-05.txt as 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 2012-06-04. 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.
 
 Abstract
 
 
The IETF has developed and documented policies that govern the
behavior of all IETF participants with respect to Intellectual
Property Rights (IPR) about which they might reasonably be aware.
 
The IETF takes conformance to these IPR policies very seriously.
However, there has been some ambiguity as to what the appropriate
sanctions are for the violation of these policies, and how and by
whom those sanctions are to be applied.
 
This document discusses these issues and provides a suite of
potential actions that may be taken within the IETF community.
 
 
 
 
 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-farrresnickel-ipr-sanctions/
 
 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-farrresnickel-ipr-sanctions/ballot/
 
 
 No IPR declarations have been submitted directly on this I-D.

Re: Last Call: draft-farrresnickel-ipr-sanctions-05.txt (Sanctions Available for Application to Violators of IETF IPR Policy) to Informational RFC

2012-05-09 Thread Brian E Carpenter

Yoav,

IANAL, but as far as I know libel suits are normally against individuals
(or media outlets such as newspapers). The defence against a libel
suit in the British courts, the most popular jurisdiction for
international libel suits, is factual accuracy. Therefore, I think
the draft should state the need for factual evidence.

And to be clear, there are plenty of precedents for libels originating
outside the UK leading to successful suits in the UK courts, if they
have been received in the UK via the Internet.

Regards
   Brian Carpenter




On 2012-05-09 08:07, Yoav Nir wrote:
 I think that regardless of how it's worded, the real question is whether 
 liability falls to the person who sent the email (to a public mailing list) 
 or the IETF. The difference between believe and shown seems minor in 
 comparison. 
 
 -Original Message-
 From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian 
 E Carpenter
 Sent: 09 May 2012 09:52
 To: ietf@ietf.org
 Subject: Re: Last Call: draft-farrresnickel-ipr-sanctions-05.txt (Sanctions 
 Available for Application to Violators of IETF IPR Policy) to Informational 
 RFC
 
 I'd like to be reassured that this has been carefully reviewed by the IETF 
 counsel and the IETF Trust. In particular I would be interested in its 
 possible interaction with the IETF's liability insurance.
 
Any IETF participant can call for sanctions to be applied to anyone
they believe has violated the IETF's IPR policy. This can be done by
sending email to the appropriate IETF mailing list.  
 
 That seems reasonable, but publishing such a belief without having the 
 wording checked by a libel lawyer might be risky. I think the draft should 
 state that a call for sanctions should be based on factual evidence and not 
 on belief. How about
 
Any IETF participant can call for sanctions to be applied to anyone
shown to have violated the IETF's IPR policy.  This can be done by
sending email to the appropriate IETF mailing list, including a
a short summary of the relevant facts and events.
 
 Regards
Brian Carpenter
 
 On 2012-05-07 22:56, The IESG wrote:
 The IESG has received a request from an individual submitter to 
 consider the following document:
 - 'Sanctions Available for Application to Violators of IETF IPR Policy'
   draft-farrresnickel-ipr-sanctions-05.txt as 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 2012-06-04. 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.

 Abstract


The IETF has developed and documented policies that govern the
behavior of all IETF participants with respect to Intellectual
Property Rights (IPR) about which they might reasonably be aware.

The IETF takes conformance to these IPR policies very seriously.
However, there has been some ambiguity as to what the appropriate
sanctions are for the violation of these policies, and how and by
whom those sanctions are to be applied.

This document discusses these issues and provides a suite of
potential actions that may be taken within the IETF community.




 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-farrresnickel-ipr-sanctions/

 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-farrresnickel-ipr-sanctions/ball
 ot/


 No IPR declarations have been submitted directly on this I-D.



 
 Scanned by Check Point Total Security Gateway.

Re: Last Call: draft-farrresnickel-ipr-sanctions-05.txt (Sanctions Available for Application to Violators of IETF IPR Policy) to Informational RFC

2012-05-09 Thread Brian E Carpenter

Hi Adrian,

On 2012-05-09 11:57, Adrian Farrel wrote:
 Hi,
 
 I don't even own a television on which to watch people pretending to be
 lawyers...
 
 Both Brian and Yoav are making a worthwhile point, but I don't see how this 
 I-D
 changes what happens on IETF mailing lists as normal business. It is perfectly
 possible for the IETF lists to be used to libel someone with or without this
 I-D.

Absolutely.

 Brian makes a good point that the text should make it clear what level of
 back-up we expect for such a claim. In writing the original text I had assumed
 that everyone behaves like a reasonable adult when participating in the IETF -
 gosh, am I naif?

Any reply I gave to that would most likely be libellous ;-)

 Will fold in text close to Brian's suggestion.

Thanks.

   Brian
 
 Thanks,
 Adrian
 
 I am not a lawyer either, but I think it depends on jurisdiction whether a
 mailing
 list will be considered as a media outlet or merely a conduit.

 What the IETF writes in its policy amounts to a plea to users to pretty 
 please
 send
 only factual information. I don't know that it makes a difference as to who 
 is
 liable
 if the information turns out to be non-factual.

 On May 9, 2012, at 10:19 AM, Brian E Carpenter wrote:

 Yoav,

 IANAL, but as far as I know libel suits are normally against individuals
 (or media outlets such as newspapers). The defence against a libel
 suit in the British courts, the most popular jurisdiction for
 international libel suits, is factual accuracy. Therefore, I think
 the draft should state the need for factual evidence.

 And to be clear, there are plenty of precedents for libels originating
 outside the UK leading to successful suits in the UK courts, if they
 have been received in the UK via the Internet.

 Regards
   Brian Carpenter




 On 2012-05-09 08:07, Yoav Nir wrote:
 I think that regardless of how it's worded, the real question is whether
 liability
 falls to the person who sent the email (to a public mailing list) or the 
 IETF.
 The
 difference between believe and shown seems minor in comparison.
 -Original Message-
 From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
 Brian E Carpenter
 Sent: 09 May 2012 09:52
 To: ietf@ietf.org
 Subject: Re: Last Call: draft-farrresnickel-ipr-sanctions-05.txt
 (Sanctions
 Available for Application to Violators of IETF IPR Policy) to Informational
 RFC
 I'd like to be reassured that this has been carefully reviewed by the IETF
 counsel and the IETF Trust. In particular I would be interested in its
 possible
 interaction with the IETF's liability insurance.
   Any IETF participant can call for sanctions to be applied to anyone
   they believe has violated the IETF's IPR policy. This can be done by
   sending email to the appropriate IETF mailing list.
 That seems reasonable, but publishing such a belief without having the
 wording checked by a libel lawyer might be risky. I think the draft should
 state
 that a call for sanctions should be based on factual evidence and not on
 belief.
 How about
   Any IETF participant can call for sanctions to be applied to anyone
   shown to have violated the IETF's IPR policy.  This can be done by
   sending email to the appropriate IETF mailing list, including a
   a short summary of the relevant facts and events.

 Regards
   Brian Carpenter

 On 2012-05-07 22:56, The IESG wrote:
 The IESG has received a request from an individual submitter to
 consider the following document:
 - 'Sanctions Available for Application to Violators of IETF IPR Policy'
  draft-farrresnickel-ipr-sanctions-05.txt as 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 2012-06-04. 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.

 Abstract


   The IETF has developed and documented policies that govern the
   behavior of all IETF participants with respect to Intellectual
   Property Rights (IPR) about which they might reasonably be aware.

   The IETF takes conformance to these IPR policies very seriously.
   However, there has been some ambiguity as to what the appropriate
   sanctions are for the violation of these policies, and how and by
   whom those sanctions are to be applied.

   This document discusses these issues and provides a suite of
   potential actions that may be taken within the IETF community.




 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-farrresnickel-ipr-sanctions/

 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-farrresnickel-ipr-sanctions/ball
 ot/


 No IPR declarations have been submitted directly on this I-D.



 Scanned by Check Point Total Security Gateway.

 Scanned by Check Point Total Security Gateway.

Re: Is the IETF aging?

2012-05-06 Thread Brian E Carpenter

On 2012-05-05 04:48, Yoav Nir wrote:
...
 an obvious idea would be to change the requirements for a new work item from 
 rough consensus to a bunch of people willing to do the work and at least 
 one willing to implement.  Some working groups already work like this, but 
 it's not universal.

There's nothing to stop a group of people developing a specification
as an I-D and prototyping it. They don't need a WG or a BOF or a
sponsoring AD.

The barrier for spending collective resources (WG time, AD time, RFC
Editor time, IANA time) on it should be real, IMHO.

On 2012-05-06 04:52, Hannes Tschofenig wrote:
...
 My point is that you will not find interest from young engineers to work on
 10 year old topics. You can try it yourself: give a talk at a university and
 see the reaction from the students. Pick a lower-layer topic and a topic
 from the application layer (some Web stuff).

It's true. But the fact is that as in any major technical system, neglect
of the infrastructure is a very bad idea. Just consider what happens to
a city if it ignores the sewers and water pipes. Sorry to say that the
IETF (and the operators who read RFCs) are in the same position as
municipal utilities. It's hard to get students interested in sanitary
engineering.

   Brian

'Geek' image scares women away from tech industry • The Register

2012-04-30 Thread Brian E Carpenter

Since the topic was raised here:

http://www.theregister.co.uk/2012/04/26/girls_in_ict_day/

Note the comment about the need for role models.

Regards
   Brian

IAOC and permissions [Re: Future Handling of Blue Sheets]

2012-04-25 Thread Brian E Carpenter

Dear IAOC,

I suggest that your standard dealings with local hosts should
include requiring them to perform a local check on whether the
standard Note Well takes account of all local legal requirements,
including for example consent to publication of images. If it doesn't,
the host should provide an augmented Note Well for use during
meeting registration.

From the recent discussion, this needs to be done for sure for
IETF 87.

Regards
   Brian Carpenter

On 2012-04-25 00:30, John C Klensin wrote:
 
 --On Tuesday, 24 April, 2012 18:19 -0500 James M. Polk
 jmp...@cisco.com wrote:
 
 IETF 87 is in Germany (15 months from now), so we'd better
 solve this issue soon, I should think.
 
 The IESG and IAOC are invited to take my comments on the
 situation as an appeal against the decision to hold that meeting
 unless either the situation can be clarified with counsel to the
 degree that we understand that Martin's concerns are not
 applicable, that appropriate permission language and permissions
 can be clarified with Counsel so that a binding between
 registration and permission is possible and used, or that a
 community consensus call demonstrates that the community
 believes that the just make lists plan is preferable to having
 the option to take pictures.
 
 And that is my last comment on the subject unless I have to
 formalize such an appeal.
 
john
 
 .

Re: IAOC and permissions [Re: Future Handling of Blue Sheets]

2012-04-25 Thread Brian E Carpenter


Christian,

On 2012-04-25 08:57, Christian Huitema wrote:
 Brian,
 
 I suggest that your standard dealings with local hosts should include 
 requiring them to perform a local check on
 whether the standard Note Well takes account of all local legal 
 requirements, including for example 
 consent to publication of images. If it doesn't, the host should provide an 
 augmented Note Well for use 
 during meeting registration.
 
 Rather than going this route, we might consider some better balance between 
 privacy and standard-settings. Taking and publishing a person's image is a 
 step above listing their names. Do we really need that for the purpose of 
 standard making, let alone Internet Engineering? How about answering the 
 classic privacy checklist:

These are excellent questions, and I support them being studied (perhaps
initially by a small group), but I think they are orthogonal to my
suggestion. Since privacy laws vary widely, I really think this issue
needs to be checked on a per-host-country basis, regardless of our general
policy.

Brian

 1) How much personal information do we collect, and for what purpose? The 
 rule here should be to collect the strict minimum necessary for the purpose. 
 Pictures don't appear to meet that bar.
 2) How do we process that information? Who in the IETF has access to it?
 3) Do we make that information available to third parties? Under which 
 guidelines? Again, there is a big difference between answering a subpoena and 
 publishing on a web page.
 4) How do we safeguard that information? Is it available to any hacker who 
 sneaks his way into our database?
 5) How long do we keep the information? Why?
 6) How do we dispose of the expired information?
 
 These look like the right questions to the IAOC.
 
 -- Christian Huitema

Re: Future Handling of Blue Sheets

2012-04-23 Thread Brian E Carpenter

On 2012-04-23 09:13, Kireeti Kompella wrote:
 On Apr 23, 2012, at 0:05, EXT - joe...@bogus.com joe...@bogus.com wrote:
 
 (quoting from RFC 2418)
 
 All working group sessions (including those held outside of the IETF
 meetings) shall be reported by making minutes available.  These
 minutes should include the agenda for the session, an account of the
 discussion including any decisions made, and a list of attendees.
 
 RFCs are not gospel. They can, and, in this instance, should, be changed: 
 either remove that last item, or stately explicitly that there is no 
 expectation of privacy at IETF meetings.  (I have a sinking feeling I know 
 which way that will go.)

I disagree. On the contrary, I think the practice of listing attendees
in the minutes should be enforced. I don't think it's in the IETF's
interests for our meetings to be anything other than completely
transparent to the world.

 Why shouldn't getting the list of a meeting's attendees require a subpoena?  
 The cost argument is bogus; equally, there are those who think going to a 
 judge for permission to wiretap is a waste of time and money.

Because if the attendee list is public, it becomes much easier for third
parties to detect cases where an IPR disclosure requirement has been
evaded. Also, it reduces the work of responding when a subpoena does
arrive: simply send the URL of the meeting minutes, instead of pulling
archive boxes out of off-site storage and searching them. In practice,
it would likely prevent the subpoena ever being generated.

 Put the money you save on NOT installing RFID kit into a fund for handling 
 subpoenas (only half joking). 
 
 Kireeti
 
 PS: Yoav, regarding your remarks on street surveillance, from the IETF Note 
 Well:
 
 A participant in any IETF activity acknowledges that written, audio and 
 video records of meetings may be made and may be available to the public.

Exactly. Your attendance at an IETF session is a matter of public record (as
is your contribution to any IETF mailing list). This is an *open* standards
process, I'm glad to say.

Brian

Re: IPv6 Zone Identifiers Considered Hateful

2012-03-22 Thread Brian E Carpenter

On 2012-03-23 05:48, Worley, Dale R (Dale) wrote:
...

 In regard to URIs:
 
 People have spoken about the annoyance of using % to introduce the
 zone identifier, and the fact that % is special in URIs and would
 need escaping, etc.  But (1) it's unlikely anyone will write URIs with
 zone identifiers, since they'd only be usable on a single host, and
 (2) the syntax of RFC 3986 (Uniform Resource Identifier (URI):
 Generic Syntax) does not provide for specifying zone identifers on
 IPv6 addresses.  Indeed, it says This syntax does not support IPv6
 scoped addressing zone identifiers.

This is a current topic in 6man so it may change.

   Brian

Re: IPv6 Zone Identifiers Considered Hateful

2012-03-21 Thread Brian E Carpenter

On 2012-03-22 09:43, Fred Baker wrote:
 On Mar 19, 2012, at 11:55 AM, Sabahattin Gucukoglu wrote:
 
 I've obviously not been doing all my homework, and RFC 4007 slipped my 
 attention.  Worse, for all the communication my IPv6 nodes are doing amongst 
 themselves using link-local addresses, it's never really been much more than 
 a hastily-justified curiosity why, when I ping one from the other using 
 link-local-scoped addresses, I have to put in this zone identifier (%ifname 
 on BSD and Linux).
 
 To be honest, I'm still not sure I understand the argument for a zone 
 identifier.

I've always viewed them as a fault diagnosis tool, mainly.
But the first paragraph of section 6 of RFC 4007 makes a stack
implementation argument:

 6.  Zone Indices
 
Because the same non-global address may be in use in more than one
zone of the same scope (e.g., the use of link-local address fe80::1
in two separate physical links) and a node may have interfaces
attached to different zones of the same scope (e.g., a router
normally has multiple interfaces attached to different links), a node
requires an internal means to identify to which zone a non-global
address belongs.  This is accomplished by assigning, within the node,
a distinct zone index to each zone of the same scope to which that
node is attached, and by allowing all internal uses of an address to
be qualified by a zone index.

In other words if the IETF doesn't define the zone index, every
implementor will have to do so anyway. Also, read the last clause
carefully: it says the stack MUST allow OPTIONAL use of the zone
index internally.

 From MIF's perspective, if the same prefix is placed on multiple interfaces, 

The prefix fe80::/10 is automatically on every interface. That's the
only case where I'm certain we need a zone index in practice, but the
definition isn't limited to that case.

   Brian

 the system might see peers using a given address on multiple interfaces, and 
 at least some devices might be expected to route between the interfaces. 
 Architecturally, this can be easy to solve or hard. We have any number of 
 cases (think about PPP for example) in which we bundle multiple interfaces 
 under a common super-interface and do something. In PPP Multilink, we might 
 segment messages into smaller frames, distribute them across a number of 
 interfaces to the same place, and reconstitute the original message on the 
 other side. In this case, it seems that we want IP to use two layers of 
 interfaces, a virtual one instantiated by multiple lower layer interfaces, 
 and place the prefix on the virtual interface. When we are wondering what MAC 
 address should be associated with a given IP address, we ask each of the 
 lower layer interfaces, and if we get a result on one of them we know where 
 we're going. The big issue will be routing among the physical interfaces - 
 something req
uired for it to be seamless and yet not as trivial as it might sound.

Re: IPv6 Zone Identifiers Considered Hateful

2012-03-21 Thread Brian E Carpenter

Fred,

On 2012-03-22 13:29, Fred Baker wrote:
 On Mar 21, 2012, at 10:51 PM, Brian E Carpenter wrote:
 In other words if the IETF doesn't define the zone index, every
 implementor will have to do so anyway. Also, read the last clause
 carefully: it says the stack MUST allow OPTIONAL use of the zone
 index internally.
 
 Implementors generally *do* have some internal form of a zone index, and it 
 doesn't look at all like what the RFC describes. It is a machine address or a 
 lookup index of some kind for a table that is associated with an interface. 
 Sometimes, part of it is a card identifier.

Yes, someone recently cited fe-0/0/1 as a real-world example of an
interface identifier (in practice equivalent to a zone identifier)
RFC 4007 says nothing about the syntax of the identifier. Clearly
the mapping to a 32 bit integer is a local matter in the node; look
at RFC 4007 and the socket API together.

 From MIF's perspective, if the same prefix is placed on multiple 
 interfaces, 
 The prefix fe80::/10 is automatically on every interface. That's the
 only case where I'm certain we need a zone index in practice, but the
 definition isn't limited to that case.
 
 The use of something to get me to the interface table in question isn't what 
 I am questioning. It's the use of that particular something...

IMHO it is very limited, mainly for diagnostic use. We need to get
it right but it has no mainstream value that I can see.

Brian

Re: URIs and zone IDs

2012-03-20 Thread Brian E Carpenter

On 2012-03-21 04:11, John C Klensin wrote:
 
 --On Tuesday, March 20, 2012 09:24 +0100 t.petch
 daedu...@btconnect.com wrote:
 
 There is currently a thread in 6man on

 Subject: Re: 6MAN WG Last Call:
 draft-ietf-6man-uri-zoneid-00.txt
 http://www.ietf.org/mail-archive/web/ipv6/current/msg15505.html

 on how to put this zoneid into a URI which, given that zone
 ids start with a % and that RFC3986 gives that character
 special, syntactical significance, would appear to verge on
 the impossible.  As and when IPv6 gets rolled out, I suspect
 that this topic will bite, or haunt, an ever growing number of
 people - which makes it worth some consideration now.

Just to clarify: the authors of draft-ietf-6man-uri-zoneid
are well aware of the fact that the draft has to be updated
because of that issue, and that discussion is ongoing in the
6man WG for now.

It is also very clear that this whole proposal is only of value
for low-level connectivity diagnosis and has no meaning outside
that context.

Brian

 
 Tom,
 
 FWIW, zoneids are nothing special in that regard.  While it has
 been used less in recent years than a decade or two ago, % has
 had a special meaning in some email addresses for a long time,
 requiring either special treatment in MAILTO or that users know
 how to escape the character and that applications follow the
 decoding rules exactly and in the correct order.  Tricky
 interpretation of + in HTML has also made it difficult to use
 that character in email addresses in many web-like contexts and,
 for it, incorrect interpretations of the decoding rules in
 applications has contributed to making escaping the character
 into %2B an insufficient workaround.
 
 While RFC 3986 makes the rules perfectly clear, we've seen
 applications get the coding and decoding wrong.  Expecting end
 users to understand the rules about when escaping is required
 and to apply them correctly is, at least IMO, pretty hopeless.
 
 Having IRIs as an overlay on URIs that can, unbeknown to the
 user, create even more %-encodings, increases the risks and
 complications.  We will almost certainly see applications that,
 in the hope of a better user experience (and regardless of what
 we tell them in standards) try to decode URIs that contain %
 characters into IRIs and getting that wrong.
 
 I think it is all a nightmare waiting to happen.  You may or may
 not agree.  Certainly those who are working on IRIs and URIs
 either don't see the risks or see them as acceptable.   
 
 Either way, there is nothing particularly special about IPv6
 zone identifiers in that regard.  If nothing, interactions
 between those zone identifiers and presentation of IPv6
 addresses to users (in URIs or otherwise) ought to reinforce a
 conclusion the IETF reached years ago but we seem to keep
 forgetting.  That conclusion was that protocols and methods that
 expose IP addresses (whether IPv4 or IPv6) to users are
 generally a bad idea.  If we believe it, we should be designing
 in ways that hide or abstract that information, whether into the
 DNS, into better location-identifier separation, or otherwise.
 That principle doesn't help with special syntax in email
 addresses or with the URI-IRI-user interactions, but might
 call for some careful thinking about zone identifiers and/or
 IPv6 addresses and URIs.
 
 The context in which many of us take the opportunity to pledge
 to the universal deployment of IPv6 is not intended to numb the
 pain of self-inflicted bullets to our feet.
 
  john

Re: Issues relating to managing a mailing list...

2012-03-14 Thread Brian E Carpenter

On 2012-03-15 13:33, ned+i...@mauve.mrochek.com wrote:
...
 I suppose I could live with this - but not actively support it - if the
 stripping was limited to abusively large attachments - say ones over 5Mb or
 thereabouts. 

+0.9; maybe set the limit a bit lower, for those who still have network
capacity issues. However, it would be extremely inconvenient to have small
attachments stripped.

 But otherwise it's a TERRIBLE idea, and will simply result in 
 everyone including the draft or whatever in the primary message text in order
 to avoid this nonsense, which results in a degradation of list quality for all
 concerned.

+1

Brian

Issues with prefer IPv6 [Re: Variable length internet addresses in TCP/IP: history]

2012-02-23 Thread Brian E Carpenter

Martin,

Yes, the issues with an unconditional prefer IPv6 approach
have been noted, and operating systems of the vintages you
mention certainly deserved criticism. In fact this has been a
major focus of IPv6 operational discussions, and lies behind
things like the DNS whitelisting method, the happy-eyeballs
work, and my own RFC 6343.

Old news; unfortunately it means you need new o/s versions.
Disabling 6to4 and Teredo unless they are known to be working
well is a good start, however.

Regards
   Brian Carpenter

On 2012-02-24 05:51, Martin Rex wrote:
 Bob Hinden wrote:
 Martin Rex wrote:
 With a fully backwards compatible transparent addressing scheme,
 a much larger fraction of the nodes would have switched to actively
 use IPv6 many years ago.
 Right, just like they could have deployed dual stack many years ago too.
 
 Just two days ago I had an extremeley disappointing experience with IPv6.
 Windows XP 64-bit (aka Win2003sp2) on a local network with a private
 DNS universe, IPv4 only network, Windows IPv6 protocol stack installed
 but IPv6 active only on the two virtual network interfaces of VMware.
 
 Somehow the DNS servers configured in the network settings had performed
 only a partial zone reload and were replying only to some queries,
 failing some DNS queries with server failure or timeout,
 and one DNS zone had become completely invisible.
 
 I noticed the problem suddenly during work because every new connection
 took ~16 seconds delay to complete.  Wondering what was wrong, I started
 wireshark.
 
 I saw Windows2003 send out 23 DNS lookups for  records for the
 requested hostname over the course of 16 seconds (some of which returned
 server failure, some of which failed with no such name),
 until Windows 2003 finally decided to also try a DNS A query--which got
 immediately successfully answered and the connection was established.
 The delay affected each and every connection attempt, even when contacting
 the same host repeatedly (although there is a DNScache service running...).
 
 Disabling IPv6 on all network adapters did not stop this Windows  frenzy,
 I had to actually uninstall the IPv6 protocol stack (an action which
 immediately kills *ALL* network connectivity of the machine and requires
 a reboot to recover...) for this  nonsense to end.
 
 During the past few years I had two similar encounters with sudden severe
 connectivity problems on a Windows XP and a Linux installation, and
 both times, the problem disappeared when I disabled IPv6.
 
 It is also significantly easier to configure the firewall for IPv4-only...
 
 -Martin
 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Issues with prefer IPv6 [Re: Variable length internet addresses in TCP/IP: history]

2012-02-23 Thread Brian E Carpenter

On 2012-02-24 12:32, ned+i...@mauve.mrochek.com wrote:
 In message 01occ10b11tc00z...@mauve.mrochek.com, 
 ned+i...@mauve.mrochek.com w
 rites:

...
 I contend that OS are IPv6 ready to exactly the same extent as they
 are IPv4 ready.  This isn't a IPv6 readiness issue.  It is a
 *application* multi-homing readiness issue.  The applications do
 not handle unreachable addresses, irrespective of their type, well.
 The address selection rules just made this blinding obvious when
 you are on a badly configured network.
 
 That's because the choice has recently been made that the place to deal with
 this problem is in applications themselves. I happen to think this is an
 exceptionally poor choice - the right way to do it is to provide a proper
 network API that hides network selection details, rather than demanding every
 application out there solve the problem separately.

I wish, I *really* wish, that it worked. Making it work, by one technique
or another, is not a new topic, even when only IPv4 connectivity
was at issue. Those things are often called 'connection managers'
and are largely based on trial and error or reachability probes.

Then there are efforts like SCTP and MPTCP to solve it in the transport
layer, and shim6 to solve it in the network layer (for IPv6 only, but the
issue is the same). These solutions are also essentially based on
trial and error, and need to be supported by both hosts.

 And yes, I'm familiar with the line of reasoning that says applications are 
 too
 varied in their needs, or their internal environments conflict with the
 necessary use of threads, or whatever. I don't buy any of it. Yes, such
 applications exist, but like most things there's a sweet spot that solves a
 significant fraction of the problem.

That's been part of Java for some years (since 1.5 iirc). But it
*doesn't* solve precisely the problem that Martin was describing,
where a stack falsely believes that it has IPv6 connectivity but
in fact it doesn't. In that sort of situation, short of manual
intervention, something like happy-eyeballs seems to be needed in
order for the application to fix things up when the network layer
is confused.

And no, I'm not happy with this, but it seems to be reality.

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

Re: Variable length internet addresses in TCP/IP: history

2012-02-17 Thread Brian E Carpenter

On 2012-02-18 08:10, Bob Hinden wrote:
 Noel,
 
 On Feb 17, 2012, at 10:32 AM, Noel Chiappa wrote:
 
 From: Bob Hinden bob.hin...@gmail.com
 the other reason why we went with 128-bit address with a 64/64 split
 as the common case and defining IIDs that indicate if they have
 global uniqueness. This creates a framework that an ID/locator split
 could be implemented. ... we have a framework that would allow it
 without having to roll out another version of IP. 
 Alas, the inclusion of _both halves_ of the IPv6 address in the TCP
 checksum means the framework you speak of is basically useless for an
 identity/location split.

 
 That's why I described it as a framework.  The TCP pseudo-checksum would have 
 to change and likely the addition of some sort of authentication at 
 connection establishment to associate an identifiers with a set of locators.  
 Not trivial, but doable.  

Authentication is not just doable, but done, in shim6. However,
shim6 ducks the checksum issue by being a shim. ILNP deals with
it up front, but is a bigger change from vanilla IPv6. The
flexibility is there, but it's academic until we get IPv6 widely
deployed.

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

Re: Last Call: draft-garcia-shim6-applicability-03.txt (Applicability Statement for the Level 3 Multihoming Shim Protocol (Shim6)) to Informational RFC

2012-02-15 Thread Brian E Carpenter

I'd like to support this draft, having reviewed it carefully. Shim6
is running code whose time will come, and this document is useful
background for implementation and deployment.

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

Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

2012-02-14 Thread Brian E Carpenter

On 2012-02-15 09:35, Randy Bush wrote:
 Do you, or do you not, object to the proposed change that changes the 
 text from saying, This space may be used just as 1918 space to This 
 space has limitations and cannot be used as 1918 space?
 
 what silliness.  it will be used as rfc 1918 space no matter what the document
 says.

Of course it will. My suggestion was to change the text to is not intended
to be used instead of can be used, hoping that would be viewed as a
fair warning.
http://www.ietf.org/mail-archive/web/ietf/current/msg71596.html

Brian

 
 nine years ago i was in bologna and did a traceroute out.  i was surprised 
 to find that the isp was using un-announced us military space as rfc 1918 
 space internal to their network.  this turns out to be common.
 
 any thought that this is not just adding to rfc 1918 is pure bs.
 
 randy
 
 
 ___
 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: Variable length internet addresses in TCP/IP: history

2012-02-14 Thread Brian E Carpenter

Martin,

 One the one hand, the IETF was frowning upon NATs when they were
 developed outside of the IETF.  But if you look at the IETFs
 (lack of) migration plan, the translation that you need in order
 to make old-IPv4 interoperate with new-IPv6, is actually worse than
 an IPv4 NAT.

I'm sorry, but *any* coexistence between RFC791-IPv4-only hosts and
hosts that are numbered out of an address space greater than 32 bits
requires some form of address sharing, address mapping, and translation.
It doesn't matter what choice we made back in 1994. Once you get to the
point where you've run out of 32 bit addresses and not every node can
support 32 bit addresses, you have the problem.

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

Re: Variable length internet addresses in TCP/IP: history

2012-02-14 Thread Brian E Carpenter

On 2012-02-15 11:45, Martin Rex wrote:
 Brian E Carpenter wrote:
 Martin,

 One the one hand, the IETF was frowning upon NATs when they were
 developed outside of the IETF.  But if you look at the IETFs
 (lack of) migration plan, the translation that you need in order
 to make old-IPv4 interoperate with new-IPv6, is actually worse than
 an IPv4 NAT.
 I'm sorry, but *any* coexistence between RFC791-IPv4-only hosts and
 hosts that are numbered out of an address space greater than 32 bits
 requires some form of address sharing, address mapping, and translation.
 It doesn't matter what choice we made back in 1994. Once you get to the
 point where you've run out of 32 bit addresses and not every node can
 support 32 bit addresses, you have the problem.
 
 But what is your point?
 
 With a fully backwards compatible transparent addressing scheme,
 a much larger fraction of the nodes would have switched to actively
 use IPv6 many years ago.

Why? They would have needed updated stacks. The routers would
have need updated stacks. The servers would have needed updated
stacks. The firewalls would have needed updated stacks. The load
balancers would have needed updated stacks. Many MIBs would have
needed to be updated. DHCP servers would have needed to be updated.
ARP would have needed to be updated, and every routing protocol.

Why would the economic incentives have been significantly different?

 You would not have two distinct routing tables for two independent
 Internets, but a single routing table for a single Internet.

True, but why is this a particular advantage? It wouldn't have
affected the need for an update to BGP4, for example.

 
 And the first network interfaces that would be using 32-bit
 IP-addresses exclusively would have been networking equipment of
 ISPs that does not need to be IPv4-addressable by everyone and his dog
 anyway (that is not so much different from the /10 shared address space
 that CGNs will be using).

Neither is it so much different from dual stack routing, which has been
working for, what, 15 years now? I don't see the comparison with CGN
though, which is a carefully engineered single bottleneck of failure,
in contrast to dynamic routing.

 The necessary changes to applications would be minimal,
 the happy eyeballs contortion completely unnecessary

As someone else said, this is to do with multihoming
and multi-interfacing; the fact that there are two address
lengths is a side-issue. We would still have needed to update
the socket interface to deal with 32 bit addresses, and ditto
the DNS.

 and the security assessment for an IPv6 enabled network
 *MUCH* simpler.

I agree that the fact that IPv6 has a different feature list
from IPv4 has provided entertainment for security analysts.

I will shut up on this topic and get back to IPv6 deployment.

Brian

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

Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

On 2012-02-14 05:51, Noel Chiappa wrote:
  From: Arturo Servin arturo.ser...@gmail.com
 
  Are you volunteering to buy everyone on earth a new CPE? If not, who
  do you suggest will?
 
  I suggest the ISPs, they are charging for the service, right?
 
 Lots of CPE is actually owned by the customers, not the ISPs. E.g. in our
 house, both our cable modem and the router attached to it are ours.

Sure, that's very common, but these devices are consumer electronics and
will get gradually replaced by IPv6-supporting boxes as time goes on.
(That is not hand-waving, the generation of boxes with IPv6 support is
starting to appear.) Nobody, I think, is denying that there will be a long
period of coexistence as a result.

That is a separate question from this draft, which gives ISPs space for
*growing* their IPv4 customer base. I think that is what upsets people.

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

Backwards compatibility myth [Re: Last Call: draft-weil-shared-transition-space-request-14.txt]

Martin Rex wrote:
...
 It was the IETFs very own decision to build IPv6 in a fashion that it is
 not transparently backwards compatible with IPv4.  If the is anyone to
 blame for the current situation, than it is the IETF, not the consumers
 or the ISPs (except for those folks at ISPs who participated in the
 development of IPv6).

People say this from time to time, but it's a complete myth.

IPv4 provides no mechanism whatever for addresses greater than 32 bits.
Therefore, mathematically, there is no possible design for an IP with
bigger addresses that is transparently backwards compatible. We've known
that since at least 1992.

The design error was made in the late 1970s, when Louis Pouzin's advice
that catenet addresses should be variable length, with a format prefix,
was not taken during the design of IPv4.

(There were advocates of variable length addresses for IPng, but the
128 bit choice won on the grounds that it is enough for anything, which
32 bits clearly wasn't.)

   Brian (donning flameproof clothing)
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Backwards compatibility myth [Re: Last Call: draft-weil-shared-transition-space-request-14.txt]

On 2012-02-14 13:32, Dave CROCKER wrote:
 
 
 On 2/13/2012 4:17 PM, Brian E Carpenter wrote:
 People say this from time to time, but it's a complete myth.
 
 well, not completely...
 
 
 IPv4 provides no mechanism whatever for addresses greater than 32 bits.
 Therefore, mathematically, there is no possible design for an IP with
 bigger addresses that is transparently backwards compatible. We've known
 that since at least 1992.
 
 
 The path that the IETF followed ensured the maximum amount of
 incompatibility. Really a completely independent stack.
 
 In contrast, the IETF could easily have chose a path toward minimizing
 incompatibility that would have allowed IPv6 to interwork with IPv4,
 within the limitations of the v4 address space.
 
 That is, the IETF could begun IPv6 by assigning to it IPv4 addresses,
 reserving the remainder for latter definition and allocation.  It could
 have targeted simple, basic reformatting at the IP level to permit early
 IPv6 adoption to require a minimal gateway for interworking with the
 IPv4 world.

There were very specific reasons why this was not done. And it doesn't
change the fact that an old-IP-only host cannot talk to a new-IP-only host
without a translator. It is that fact that causes our difficulties today.

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

Re: Backwards compatibility myth [Re: Last Call: draft-weil-shared-transition-space-request-14.txt]

On 2012-02-14 13:42, Dave CROCKER wrote:
 
 
 On 2/13/2012 4:38 PM, Brian E Carpenter wrote:
 There were very specific reasons why this was not done.
 
 Is there a useful citation that covers this strategic decision?

You may recall that at the time, we were very concerned about the
pre-CIDR growth rate in BGP and there was, iirc, a generalised
aversion to anything that would import the entire IPv4 BGP4 table
into IPv6. I don't recall without a lot of archive grepping whether
this was explicit in the IPng decision or whether it came a bit later.

 
 Given that that decision was an essential part of what caused a roughly
 15 year delay, it would be helpful to have it documented.
 
 
 And it doesn't
 change the fact that an old-IP-only host cannot talk to a new-IP-only
 host
 without a translator. It is that fact that causes our difficulties today.
 
 The translator needed today is a complete gateway between two entirely
 incompatible protocols.  The one that I'm describing would have been a
 trivial re-formatter.
 
 The development, deployment and interoperability differences between
 these is massive.

Honestly, having had an MSc student who benchmarked translation vs
application proxying vs native, I don't think so. The mechanics of
packet translation are trivial. The hard part is exactly the same as
with NAT44, caused by the shortage of IPv4 addresses and all the state
that goes with sharing the pool of transport ports for a single address.

On 2012-02-14 13:49, Randy Bush wrote:

 i guess you forget the discussion of variable length.  i hope we don't
 have to rehash it here.

I haven't forgotten. The worst row I ever had at an IETF meeting was
on that topic.

 decisions were made.  some were quite bad.  v6 had some real zingers.
 remember tla/nla?  no feature parity, such as dhcp (a war which has not
 finished)?  it is almost as if it was designed to fail.

DHCP for v4 was still wet behind the ears at that time, so this
wasn't as obvious then as it is now; there's a bit of 20/20 hindsight
here. But yes, we could of course have done better. Unfortunately my
time machine is broken.

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

Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

2012-02-10 Thread Brian E Carpenter

On 2012-02-11 11:09, Doug Barton wrote:
 On 02/10/2012 07:47, Chris Donley wrote:
 
 Please remember that this draft is in support of ARIN Draft Policy 2011-5.
 
 Partially, sure. But RFCs apply to the whole Internet.

Hear hear.

 
 IMO, an IETF RFC is not the correct place to tell ARIN or other RIRs how
 to allocate space;
 
 I'm not going to parse the nuances of what you wrote, but I think
 generally you're wrong.

The RIRs get their space from IANA@ICANN, so s/ARIN/ICANN/ and
read clause 4.3 of RFC 2860 carefully.  The IAB decided that
the current issue *is* the IETF's business under that clause.

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

Re: ITC copped out on UTC again

2012-02-08 Thread Brian E Carpenter

On 2012-02-09 10:41, Steven Bellovin wrote:
On Feb 7, 2012, at 2:12 59PM, John C Klensin wrote:

--On Tuesday, February 07, 2012 10:45 -0800 james woodyatt
j...@apple.com wrote:

...
TAI has a fairly stable foundation in non-relativistic
physics, which experience has shown to be somewhat resistant
to the power of political bodies to modify at will, so it
should be good enough for most running code on the Internet.
You obviously have not been in enough meetings in which
proposals were put forth, by political types with the best of
intentions, for regulations to improve the Internet...
regulations that would work really well if the speed of light
were adjusted upward by 10% or so and/or could be dialed up and
back by a bit to match regulatory convenience. :-(

What was that about a free lunch?

Yes. A line I heard recently (from someone else whom I think is
on this list) is that when you tell a politician that something
violates the laws of physics, that statement is taken as a negotiating
position.

I don't see the problem. An experiment in Italy has observed
super-luminal neutrinos, and a somewhat unlikely violation of
the 2nd law of thermodynamics would allow pigs to fly and all
NTP servers to update themselves simultaneously. Clearly these
are matters that any self-respecting politician could use in
negotiation.

I am much more worried about
http://internetsociety.org/events/internet-society-events/world-conference-international-telecommunications
than about UTC.

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

Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

2012-02-01 Thread Brian E Carpenter

Pete,

We seem to be agreeing violently.

Regards
   Brian Carpenter

On 2012-02-02 11:33, Pete Resnick wrote:
 On 1/31/12 1:38 PM, Brian E Carpenter wrote:
 IMHO the text should make it
 clear that this is the wrong way to use it and give the reasons
 why - basically the same information as in the new text, but stated
 exactly the other way round. For example

   Shared Address Space is IPv4 address space designated for Service
   Provider use with the purpose of facilitating CGN deployment.
   Shared Address Space is not intended to be used as additional
 [RFC1918]
   space, because either or both of the following issues might arise:

   o  Shared Address Space could also be used on the Service
 Provider side
  of the CPE, with overlapping subnet or host addresses.

   o  Some CPE routers behave incorrectly when using the same
 address block on
  both the internal and external interfaces.

 
 Ah. I think we're in pretty good agreement. The -14 text uses the words
 may be used as [RFC1918] private address space, and I agree with you
 that we don't want to use those words. We need to say that though it is
 similar to 1918 space, it has limitations. So I wouldn't object to the
 above text , but I think we do have to give some indication of the flip
 side. I want something that says that Shared Address Space can be used
 for other Service-Provider-type uses and are not limited to CGNs. They
 can be used on any network equipment willing to do address translation
 across interfaces which both use the Shared Address Space, just as CGNs
 do. That is, clarify throughout that this *isn't* just like 1918 space
 (it has limitations and can only be used in particular circumstances),
 but do describe what the conditions are under which it can be used.
 
 In your above, I would even strengthen is not intended to be used as
 additional [RFC1918] space to can not be use as [RFC1918] private
 address space, and then maybe add something about where it can be used.
 In the intro, I would change the second paragraph (and it's sub-bullets)
 to:
 
Shared Address Space is similar to [RFC1918] private address space in
that it is not global routeable address space and can be used by
multiple pieces of equipment. However, Shared Address Space has
limitations in its use that the current [RFC1918] private address
space does not have. In particular, Shared Address Space can only be
used on routing equipment that is able to do address translation
across router interfaces when the addresses are identical on two
different interfaces.
 
 Or something to that effect. Does that still capture that Shared Address
 Space is similar to 1918 space, it can be used for purposes other than
 CGN, but it can't be used everywhere 1918 addresses are used?
 
 pr
 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

2012-01-31 Thread Brian E Carpenter

Hi Pete,

On 2012-02-01 08:14, Pete Resnick wrote:
 On 1/31/12 11:59 AM, George, Wes wrote:
 From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu]

 Is that wise? I thought (IIRC, and maybe I'm spacing) the whole
 reason for
 allocating this space was that 1918 space _couldn't_ easily be used
 for CGN
 because there were too many conflicting usages.
  
 [WEG] yes, but the general sense I got from the ensuing discussion was
 that no one expects anyone to actually adhere to that advice (ie MUST
 NOT be used as substitute for 1918 space), and as soon as the space is
 released, it'll be cats and dogs living together, mass hysteria...
 because everyone and their cousin will start using it as 1918-bis
 anyway, no matter whether the IETF wags their fingers at them or not.

I have no doubt that this space will be (mis)used as additional
private ambiguous address space. But IMHO the text should make it
clear that this is the wrong way to use it and give the reasons
why - basically the same information as in the new text, but stated
exactly the other way round. For example

 Shared Address Space is IPv4 address space designated for Service
 Provider use with the purpose of facilitating CGN deployment.
 Shared Address Space is not intended to be used as additional [RFC1918]
 space, because either or both of the following issues might arise:

 o  Shared Address Space could also be used on the Service Provider side
of the CPE, with overlapping subnet or host addresses.

 o  Some CPE routers behave incorrectly when using the same address block on
both the internal and external interfaces.

 Speaking as one of the bozos^h^h^h^h^h ADs whose comments (and suggested
 text) ended the document up here, let me suggest the slightly less
 pessimistic view from Wes's, and the reason that I think this
 *shouldn't* specifically update 1918:
 
 This *is* a special use address block that is akin to 1918. It is
 non-routable address space, just like 1918. But unlike 1918, this block
 is defined as might be used by your ISP on your outside interface. So,
 people using it inside their networks (which, I agree with Wes, will
 happen, and like everything else on the net, will be done stupidly by
 some) have been told that this is *not* private use space and that they
 use it at their own risk and their CGN service might stop working if
 they use it in a way not described in this document. But I'd hate for us
 to allocate space to CGNs only when it's obvious that this can be used
 for a whole class of these sorts of things, and can be used by other
 people who build sane equipment that understands shared addresses can
 appear on two different interfaces. These aren't private addresses a
 la 1918, they're shared, so it's not an addition to that space. Let's
 properly document what it is we're doing, giving people fair warnings.

Exactly, hence my suggested text above.

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

Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

2012-01-30 Thread Brian E Carpenter

Hi,

  Shared Address Space is IPv4 address space designated for Service
  Provider use with the purpose of facilitating CGN deployment.  Also,
  Shared Address Space can be used as additional [RFC1918] space when
  at least one of the following conditions is true:
 
  o  Shared Address Space is not also used on the Service Provider side
 of the CPE.
 
  o  CPE routers behave correctly when using the same address block on
 both the internal and external interfaces.

I see that this change is in response to an IESG comment, but I think it's
a mistake. Encouraging sites to use yet more ambiguous address space based
on conditions that they may not even understand, or that may change when they
switch ISPs or replace CPEs, seems wrong.

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

Re: ITC copped out on UTC again

2012-01-20 Thread Brian E Carpenter

On 2012-01-21 03:20, Phillip Hallam-Baker wrote:
 If we are ever going to get a handle on Internet time we need to get rid of
 the arbitrary correction factors introduced by leap seconds.

Time is and always will be an arbitrary measurement scheme, and the only
thing that makes sense for the Internet is to use the same arbitrary scheme
as everybody else. We just have to suck up the resulting inconveniences,
as GPS has to. It would be unthinkable to go it alone.

Alternatively we could revert to the Julian (365.25 day) calendar, which
was considerably more convenient for programmers, or perhaps to one of the
old Iranian (360 day) calendars, which are convenient in some ways but do
require occasional leap months.

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

Re: Story: Next battle over Net ramps up worldwide

2012-01-19 Thread Brian E Carpenter

And don't assume that just because ISOC is on the case that this
situation is covered. It's a real threat and every ITU Secretary-General
since 1999* has been trying to grab these powers, supported by more
or less authoritarian governments.

*The last S-G who was not trying this was Pekke Tarjanne, who was largely
responsible for telecom liberalisation at the international level. He left
office in January 1999.

Regards
   Brian Carpenter

On 2012-01-20 06:01, Eliot Lear wrote:
 What this story refers to is the World Conference on International
 Telecommunications.
 
 DID YOU KNOW?
 
 ... that the Internet currently runs through a loophole in these
 international regulations that were last amended in the 1980s?
 
 ... that there are some countries who would like to exert more control
 over what protocols run on the Internet?
 
 If you didn't know, perhaps you might want to engage with ISOC to learn
 more about this.  Check out http://www.internetsociety.org/regulation.
 
 Eliot
 
 On 1/19/12 5:04 PM, Noel Chiappa wrote:
 For those who haven't seen it, here:

   Next battle over Net ramps up worldwide
   http://www.politico.com/news/stories/0112/71625.html

 is an interesting story, one which is also fairly accurate (often not true
 of major media stories about the Internet).

  Noel
 ___
 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: primary Paris hotel booking

2012-01-03 Thread Brian E Carpenter

On 2012-01-04 10:03, John C Klensin wrote:
 
 --On Tuesday, January 03, 2012 15:54 -0500 Eric Burger
 ebur...@standardstrack.com wrote:
 
 Actually (s), the IETF *does* get credit for rooms sold.
 We reconcile the attendee list with hotel guests. Go for it.
 
 In a way, that is really too bad.  If people find the
 cancellation or other) policies problematic enough to actually
 change their behavior (as distinct from whining), it would be
 good for the IAOC to get that message in a way that was clear
 and couldn't be avoided.  If you don't incur a penalty for
 failure to fill a block and/or can't really tell paid a higher
 rate to get a better policy from reserved after the block was
 full or past the deadline, then there are few, if any,
 incentives for telling a hotel that these sort of policies won't
 do.

There's a third case, paid a lower rate than the conference rate
(usually due to a smart corporate travel agent). I've never
understood why conferences don't get a corporate-equivalent rate.

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

Re: I wish ...

2011-12-20 Thread Brian E Carpenter

Also, in general, we have operated on the basis that if people aren't
interested enough in a work item or draft to actually work on it or
review it, then the work item isn't really important to the community.

This even applies to drafts that I write, if nobody is interested ;-).

When all work items in the IETF reach that state, we can all get on
with our lives.

Regards
   Brian

On 2011-12-21 05:38, Donald Eastlake wrote:
 The end of year Holiday season is not generally known as a time when
 lots of work gets done.
 
 Thanks,
 Donald
 =
  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
  155 Beaver Street, Milford, MA 01757 USA
  d3e...@gmail.com
 
 
 On Tue, Dec 20, 2011 at 10:21 AM, t.petch daedu...@btconnect.com wrote:
 .. I knew how to move things forward.   Earlier this year, the discussion was
 about how meetings might be reorganised to make more happen, and I commented
 that six meetings a year - no need to attend them - might produce six spurts 
 of
 activity in a 12 month period instead of three.

 Post-Taipei, most of the WG I track, with the notable exception of the 
 terrible
 twins of v6, seem to be moribund; WGLC go unanswered, calls for adoption lie
 fallow, those edits that would be made as soon as the window opened again 
 remain
 unmade, ...

 The IESG is evidently working hard, but at the lower strata, ...

 For Christmas, I wish ...

 Tom Petch

 ___
 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: Proposal to remove three datatracker pages (https://datatracker.ietf.org/iesg/ann/ind/, /new, and /prev

2011-12-15 Thread Brian E Carpenter

Hi,

On 2011-12-16 09:20, Robert Sparks wrote:
 There are three pages exposed at the datatracker that have become stale
 or are producing erroneous information.
 https://datatracker.ietf.org/iesg/ann/ind/

IESG Statements on Independent Submissions

This is in theory very useful information. I haven't needed it recently, but 
I've
certainly used it in the past. How else will people find it? Searching the mail
archive (or the IESG minutes) is really not very convenient.

Please check with the ISE before scrapping this. It would be fine if these
announcements were collated on the RFC Editor site, but I don't see them
at http://www.rfc-editor.org/indsubs.html

 https://datatracker.ietf.org/iesg/ann/new/
 https://datatracker.ietf.org/iesg/ann/prev/
 
 Has anyone been using those links?

Again, not recently, but it's still a lot more convenient than searching the 
mail
archive or the minutes.

I don't clearly remember, but I think these pages were created in response to
complaints about lack of IESG transparency and the inconvenience of searching
email archives. So I'd be a bit sorry to see them go.

OTOH they obviously need to work properly if they're kept, and they would be
much more useful if they included the full draft name as well as the title.

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

Re: The work of an IAOC/Trust member

2011-12-07 Thread Brian E Carpenter

On 2011-12-08 06:26, Noel Chiappa wrote:
  From: Dave CROCKER d...@dcrocker.net
 
  Subpoenas
 
 Subpoenas? Really? Wow!
 
 Well, that should scare a few people off... :-)

Subpoenas served on the IETF (Trust) about prior art or IPR disclosure,
not on individuals. It was never a problem when I was on the IAOC, just
a matter of being aware.

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

Re: The work of an IAOC/Trust member

2011-12-07 Thread Brian E Carpenter

On 2011-12-08 08:41, t.petch wrote:
 - Original Message - 
 From: Brian E Carpenter brian.e.carpen...@gmail.com
 To: Noel Chiappa j...@mercury.lcs.mit.edu
 Cc: ietf@ietf.org
 Sent: Wednesday, December 07, 2011 8:15 PM
 On 2011-12-08 06:26, Noel Chiappa wrote:
  From: Dave CROCKER d...@dcrocker.net

  Subpoenas

 Subpoenas? Really? Wow!

 Well, that should scare a few people off... :-)
 Subpoenas served on the IETF (Trust) about prior art or IPR disclosure,
 not on individuals. It was never a problem when I was on the IAOC, just
 a matter of being aware.

 What about 'anti-trust' actions?  Who cops it for those, were a particular
 RFC or I-D considered anti-competitive?

That's a different question entirely, where the plan of record is to
get up to date legal advice. IANAL.

   Brian

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

Re: Netfilter (Linux) Does IPv6 NAT

2011-12-06 Thread Brian E Carpenter

On 2011-12-06 18:14, Mark Andrews wrote:
...
 The so-called IPv6 privacy addresses are terminology fud.
 No, there is no fear, uncertainty or doubt involved. If you don't want
 to be traceable by your MAC address, use privacy addresses. That will
 even conceal from parents which child is downloading music.
 
 If parents want to know which child is doing what they can do that
 even with privacy addresses.  Privacy addresses don't change the
 mac, that just don't encode the mac in the IPv6 address.  If the
 kids start playing mac games use 802.1x.

Yes, of course it depends on the child's and the parents' technical
sophistication. I was limiting my comment to layer 3, since Martin was
arguing that layer 3 NAT helps privacy.

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

Re: Netfilter (Linux) Does IPv6 NAT

2011-12-06 Thread Brian E Carpenter

Martin,

 Renumbering the internal network would be completely silly.
 You certainly do not want any interruptions of the local network traffic
 just because you frequently change the address on the external interface for
 privacy reasons.

This is why ULAs are useful. People just need to get used to the fact
that IPv6 addresses derived from ISPs will change from time to time,
and that you will have several of them. This is not your grandfather's
TCP/IP.

This is also why we have the MIF, HOMENET and 6RENUM WGs.

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

Re: Netfilter (Linux) Does IPv6 NAT

2011-12-05 Thread Brian E Carpenter

On 2011-12-06 15:00, Martin Rex wrote:
 Sabahattin Gucukoglu wrote:
 In case you didn't see this:
 http://www.h-online.com/open/news/item/Netfilter-developers-working-on-NAT-for-ip6tables-1385877.html

 It's a complete IPv6 NAT implementation with the functionality of
 the IPv4 one in the same stack.  ALGs.  Port translation.  Connection
 tracking.  You don't need me to tell you why I don't like this.
 
 
 I fail to understand the issue that you have with this.
 
 Doing home gateways and *NOT* using dynamic temporary IPv6 addresses for
 outbound connections by default (i.e. *NO* static network prefix that
 can be linked to a single ISP customer) 


I think you're confused. Whatever IPv6 source address is in the outgoing
packet from the CPE is bound 1:1 to the subscriber. You can't conceal
the address of the subscriber, if you ever want to get any packets back.

If you want to protect the privacy of individuals within the home (etc.)
behind the CPE, you can use IPv6 privacy addresses. But the traffic will
still be traceable back to the CPE, of course.

I hope you aren't under the illusion that NAT44 in CPE provides any
privacy.

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

Re: Netfilter (Linux) Does IPv6 NAT

2011-12-05 Thread Brian E Carpenter

On 2011-12-06 15:40, Martin Rex wrote:
Brian E Carpenter wrote:
Martin Rex wrote:
Sabahattin Gucukoglu wrote:
In case you didn't see this:
http://www.h-online.com/open/news/item/Netfilter-developers-working-on-NAT-for-ip6tables-1385877.html

It's a complete IPv6 NAT implementation with the functionality of
the IPv4 one in the same stack. ALGs. Port translation. Connection
tracking. You don't need me to tell you why I don't like this.

I fail to understand the issue that you have with this.

Doing home gateways and *NOT* using dynamic temporary IPv6 addresses for
outbound connections by default (i.e. *NO* static network prefix that
can be linked to a single ISP customer)

I think you're confused. Whatever IPv6 source address is in the outgoing
packet from the CPE is bound 1:1 to the subscriber. You can't conceal
the address of the subscriber, if you ever want to get any packets back.

The outgoing packet is bound 1:1 to the ISP of the subscriber, any only
the ISP knows to which of his customers he is routing the datagrams
during any specific point in time. The DHCP lease should be 24h at most
and the ISP is bound by data protection laws to not make the mapping
publicly accessible except under very specific legal exceptions.

If you are paranoid about your IP address, that's fine. Personally, I prefer
a stable address. If your IPv6 prefix changes every day, your home network
will get renumbered every day. What does this have to do with NAT?

If you want to protect the privacy of individuals within the home (etc.)
behind the CPE, you can use IPv6 privacy addresses. But the traffic will
still be traceable back to the CPE, of course.

The so-called IPv6 privacy addresses are terminology fud.

No, there is no fear, uncertainty or doubt involved. If you don't want
to be traceable by your MAC address, use privacy addresses. That will
even conceal from parents which child is downloading music.

I hope you aren't under the illusion that NAT44 in CPE provides any
privacy.

For my ISP (and it seems to be the norm for german home customers),
that is not an illusion, but rather a feature.

You mean there is a privacy benefit in translating some address such
as 10.1.1.2 into a routeable IPv4 address that can, as you say, be traced
back to you even if it changes every day?

You'll have to explain that.

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

Re: An Antitrust Policy for the IETF

2011-12-02 Thread Brian E Carpenter

On 2011-12-03 06:12, Marshall Eubanks wrote:
 On Thu, Dec 1, 2011 at 10:24 PM, John Levine jo...@iecc.com wrote:
 Rather than trying to set up rules that cover all hypothetical 
 developments, I would suggest
 a practical approach. In our process, disputes are materialized by an 
 appeal. Specific legal
 advice on the handling of a specific appeal is much more practical than 
 abstract rulemaking.
 +1

 This has the admirable advantage of waiting until there is an actual
 problem to address, rather than trying to guess what has not happened
 in the past 30 years but might happen in the future.

 R's,
 John


 
 I must admit that I don't understand that reasoning at all, assuming
 that this discussion is still about anti-Trust policy. Once there is
 an actual problem to address, it will be because we are enmeshed in a
 lawsuit, and it will be much too late to change our policies. Now, I
 realize that that does not prove that we have to change our policies
 (I regard that as the output of this exercise), but saying you want to
 wait until there is a problem to consider changes is IMO akin to
 saying you don't want to consider putting in fire extinguishers until
 there is a fire.

+1. We should ask a specific concrete question to a litigator who
understands antitrust law: are there any significant gaps in the IETF
process rules, including the formal Note Well warning given to all
participants, that expose us (the IETF officers, the IETF Trust,
the ISOC) to civil or criminal action in any jurisdiction?

If the answer is no we're done. If yes, we'll know what to do.

We amateur lawyers should shut up until we hear back from a professional.

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

Re: Consensus Call: draft-weil-shared-transition-space-request

2011-12-01 Thread Brian E Carpenter

Ted,

 There are enterprises that currently use
 172.16/12.

Yes, but I thought the topic of discussion when I wrote was the
default prefix used by mass-market NAT CPE boxes. That's a very
different problem than dealing with enterprise networks or even
ISPs that have intentionally deployed 172.16/12. I'm not suggesting
that reconfiguring those intentional deployments is easy, but then
no solution to this problem is easy. Reconfiguring mass-market boxes
is simply impossible.

Regards
   Brian

On 2011-12-02 11:27, Ted Hardie wrote:
 Notes below.
 
 On Wed, Nov 30, 2011 at 6:14 PM, Pete Resnick presn...@qualcomm.com wrote:
 
 **
 Daryl,

 The problem described in the draft is that CPEs use 1918 space *and that
 many of them can't deal with the fact that there might be addresses on the
 outside interface that are the same as on the inside interface*. The claim
 was made by Randy, among others, that only 192.168/16 space was used by
 such unintelligent CPEs. I believe I have seen the claim that 10/8 space is
 also used in unintelligent equipment that can't deal with identical
 addresses inside and outside. Is there reason to believe that within the
 ISP network / back-office etc. that there is equipment that can't deal with
 17.16/12 space being on both the inside and outside? I haven't seen anyone
 make that specific claim.

 If we know that 172.16/12 used both inside and outside will break a
 significant amount of sites that CGNs will be used with, we can ignore this
 argument. But if not, then let's rewrite the document to say that CGNs
 should use 172.16/12 and that any device that wants to use 172.16/12 needs
 the ability to deal with identical addresses on the inside and the outside
 interface. Of course, all equipment should have always been able to deal
 with identical addresses inside and outside for all 1918 addresses anyway.
 But if we think the impact of using 172.16/12 for this purpose will cause
 minimal harm, then there's no compelling reason to allocate new space for
 this purpose.

 pr


 I wrote a response to Brian's original statement then deleted it because I
 assumed others would ignore it as clearly last minute and ill-researched.
 Apparently, that was wrong.  There are enterprises that currently use
 172.16/12.  (There are enterprises which use every tiny piece of RFC 1918
 space.)  *Any* piece of the current RFC 1918 space you attempt to define as
 being used for this will conflict *somewhere*.  Anyone who happened to
 chose this for an enterprise deployment and gets stuck behind a CGN would
 be forced to renumber, in other words, because of this statement.  That is,
 if they actually followed the statement--they're much more likely to work
 with the CGN operator to use squat space on the CGN instead, since that's
 the existing way of avoiding this pain.
 
 Rubbing my crystal ball real hard, in other words, I predict that the
 consequences of assigning a piece of existing RFC 1918 space to this at
 this late date will have the same consequences as assigning no space at
 all, with the addition of a tiny increment of confusion among those souls
 who happen to read the RFC and briefly think it reflects reality.
 
 Either allocate new space or reject; the middle ground of assuming that
 some part of RFC 1918 can be safely allocated for this should not be
 considered as an option.
 
 My personal opinion, not that of my employer, spouse, child, or the man on
 the street.
 
 regards,
 
 Ted
 
 
 
 
 On 11/30/11 3:04 PM, Daryl Tanner wrote:

 It's not just about the CPE devices and customer LANs.

 Address conflicts are also going to happen within the ISP network /
 back-office etc. 172.16.0.0/12 is used there.


 Daryl


 On 30 November 2011 20:52, Brian E Carpenter 
 brian.e.carpen...@gmail.comwrote:

 On 2011-12-01 09:28, Chris Grundemann wrote:
 ...
 It is more conservative to share a common pool.
  It suddenly occurs to me that I don't recall any serious analysis
 of using 172.16.0.0/12 for this. It is a large chunk of space
 (a million addresses) and as far as I know it is not used by default
 in any common CPE devices, which tend to use the other RFC 1918 blocks.

 I realise that ISPs with more than a million customers would have to
 re-use this space, whereas a /10 would only bring this problem above 4M
 customers, but at that scale there would be multiple CGN monsters anyway.

 Sorry to bring this up on the eve of the telechat.

 --
 Pete Resnick http://www.qualcomm.com/~presnick/ 
 http://www.qualcomm.com/%7Epresnick/
 Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


 ___
 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

Re: Consensus Call: draft-weil-shared-transition-space-request

2011-11-30 Thread Brian E Carpenter

On 2011-12-01 09:28, Chris Grundemann wrote:
...
 It is more conservative to share a common pool.

It suddenly occurs to me that I don't recall any serious analysis
of using 172.16.0.0/12 for this. It is a large chunk of space
(a million addresses) and as far as I know it is not used by default
in any common CPE devices, which tend to use the other RFC 1918 blocks.

I realise that ISPs with more than a million customers would have to
re-use this space, whereas a /10 would only bring this problem above 4M
customers, but at that scale there would be multiple CGN monsters anyway.

Sorry to bring this up on the eve of the telechat.

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

Re: Netfilter (Linux) Does IPv6 NAT

2011-11-30 Thread Brian E Carpenter

Does it support RFC 6296?

Regards
   Brian Carpenter

On 2011-12-01 13:07, Sabahattin Gucukoglu wrote:
 In case you didn't see this:
 http://www.h-online.com/open/news/item/Netfilter-developers-working-on-NAT-for-ip6tables-1385877.html
 
 It's a complete IPv6 NAT implementation with the functionality of the IPv4 
 one in the same stack.  ALGs.  Port translation.  Connection tracking.  You 
 don't need me to tell you why I don't like this.
 
 Cheers,
 Sabahattin
 ___
 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: An Antitrust Policy for the IETF

On 2011-11-29 08:10, IETF Chair wrote:
 Ted:
 
 The IETF legal counsel and insurance agent suggest that the IETF ought to 
 have an antitrust policy.  To address this need, a lawyer is needed.  As a 
 way forward, I suggest that IASA pay a lawyer to come up with an initial 
 draft, and then this draft be brought to the community for review and 
 comment (and probably revision).  I think a new mail list should be used for 
 the discussion.  Once the new mail list reaches rough consensus on the 
 antitrust policy document, I suggest using the usual process for adopting 
 the policy as an IETF BCP.

 What do others think?  I am open to suggestions for an alternative approach.


 Sorry, can you expand on the threat model here?  Are we developing one in 
 order to defend against some specific worry about our not having one?  
 Because it has become best practice in other SDOs?  Because the insurance 
 agent wishes to see something in particular?

 I hesitate to develop something that we have not needed in the past unless 
 it is clear what benefit it gives us.  In particular, if we develop one 
 without some particular characteristic, do we lose the benefits of being 
 where we are now?
 
 Recent suits against other SDOs is the source of the concern.  The idea is t 
 make it clear which topics are off limits at IETF meetings and on IETF mail 
 lists.  In this way, if such discussions take place, the good name of the 
 IETF can be kept clean.

I think we should be very careful before creating makework for a lawyer.
In other words there are two initial questions that need to be answered:

1. What is the threat model? What type of exposure *of the IETF itself*
(including its volunteer officers) exists? Of course, this is not just
about US law. The EU has strong antitrust law, for example.

2. Are there any aspects of that threat model that are not already
covered by the Note Well, the documents it refers to, and their chain
of references?

These two questions do need legal expertise. But if the answer to Q2 is
no we can stop there.

I think a separate list for this is appropriate.

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

Re: Plagued by PPTX again

Henrik,

On 2011-11-29 07:20, Henrik Levkowetz wrote:
 Hi,
 
 I just came across this (very long) thread started by Brian's post, 

I apologise to everybody. I should know better by now than to mention
anything to do with document format on this list.

 and since
 (as Robinson Tryon mentioned in a post already) libreoffice can convert
 both .ppt and .pptx to .pdf, I've now set up the tools servers to convert
 any .ppt and .pptx to .pdf as soon as they see them.
 
 This means that .pdf versions of powerpoint slides in the future should be
 available at the tools servers a little while (less than an hour) after 
 upload.

Superb. We don't deserve you, Henrik. Thankyou.

   Brian

 You'll find them linked in to the WG agenda pages, see for instance this page
 
   http://tools.ietf.org/wg/abfab/agenda
 
 where the abfab-3.pdf and abfab-4.pdf were originally submitted as .pptx
 
 I've set the converter ('unoconv', which uses libreoffice) up to convert to
 PDF/A, but the converter doesn't always fully succeed in producing valid PDF/A
 (also mentioned by Robinson in one of his posts) -- the result still works 
 fine
 in the viewer I've tested, though.
 
 
 Best regards,
 
   Henrik
 
 
 On 2011-11-15 03:24 Brian E Carpenter said:
 Please can everybody who doesn't upload PDF to the meeting materials page
 at least take care to upload PPT instead of PPTX?

 Not everybody has paid the ransom necessary to open PPTX files.

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

Re: An Antitrust Policy for the IETF

On 2011-11-29 14:51, John Levine wrote:
 Here is some relevant language from the Complaint:

 100.   By their failures to monitor and enforce the SSO Rules, and to
 respond to TruePosition's  specific complaints concerning violations of the
 SSO Rules, 3GPP and ETSI have acquiesced in, are responsible for, and
 complicit in, the abuse of authority and anticompetitive conduct ...
 
 As I read that, we'd be much better off having no antitrust policy
 at all. Any volunteers to monitor and enforce whatever policy our
 lawyer invents?

John, if they'd had no relevant rules, it would probably have read

 100.   By their failures to promulgate appropriate SSO Rules, and to
 respond to TruePosition's  specific complaints concerning resultant 
 violations
 of antitrust laws, 3GPP and ETSI have acquiesced in, are responsible for, and
 complicit in, the abuse of authority and anticompetitive conduct ...

WG Chairs and ADs are already responsible for applying IETF process rules.

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

Re: Consensus Call: draft-weil-shared-transition-space-request