[NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole"

[NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole"

[Frantisek Borsik]

[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

"Net neutrality proponents argued that these separate lanes for different
kinds of traffic would degrade performance of traffic that isn't favored.
The final FCC order released yesterday addresses that complaint.

"We clarify that a BIAS [Broadband Internet Access Service] provider's
decision to speed up 'on the basis of Internet content, applications, or
services' would 'impair or degrade' other content, applications, or
services which are not given the same treatment," the FCC's final order
said.

The "impair or degrade" clarification means that speeding up is banned
because the no-throttling rule says that ISPs "shall not impair or degrade
lawful Internet traffic on the basis of Internet content, application, or
service."

https://arstechnica.com/tech-policy/2024/05/fcc-explicitly-prohibits-fast-lanes-closing-possible-net-neutrality-loophole/


All the best,

Frank

Frantisek (Frank) Borsik



https://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: +421919416714

iMessage, mobile: +420775230885

Skype: casioa5302ca

frantisek.borsik@gmail.com

[-- Attachment #2: Type: text/html, Size: 2508 bytes --]

Re: [NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole"

[Mike Conlow]

[-- Attachment #1: Type: text/plain, Size: 2183 bytes --]

I'm sure this was a difficult thing to write a regulation on. I'm glad the
FCC took a swing. Here's why:

If the Internet community wants to [continue] to develop technologies where
applications (or users) can signal a need for low latency treatment and
other networks in the path can honor that need -- great.

But one of the networks in the chain -- the access network -- making the
determination of what types of traffic get the low latency treatment, in my
personal opinion is reasonably interpreted as throttling.

I think it's also worth noting that these rules only apply to last-mile
mass-market ISP plans. And any network is still free to offer "network
slicing" as an enterprise offering, which I'm sure they will.

On Fri, May 10, 2024 at 10:32 AM Frantisek Borsik via Nnagain <
nnagain@lists.bufferbloat.net> wrote:

> "Net neutrality proponents argued that these separate lanes for different
> kinds of traffic would degrade performance of traffic that isn't favored.
> The final FCC order released yesterday addresses that complaint.
>
> "We clarify that a BIAS [Broadband Internet Access Service] provider's
> decision to speed up 'on the basis of Internet content, applications, or
> services' would 'impair or degrade' other content, applications, or
> services which are not given the same treatment," the FCC's final order
> said.
>
> The "impair or degrade" clarification means that speeding up is banned
> because the no-throttling rule says that ISPs "shall not impair or degrade
> lawful Internet traffic on the basis of Internet content, application, or
> service."
>
>
> https://arstechnica.com/tech-policy/2024/05/fcc-explicitly-prohibits-fast-lanes-closing-possible-net-neutrality-loophole/
>
>
> All the best,
>
> Frank
>
> Frantisek (Frank) Borsik
>
>
>
> https://www.linkedin.com/in/frantisekborsik
>
> Signal, Telegram, WhatsApp: +421919416714
>
> iMessage, mobile: +420775230885
>
> Skype: casioa5302ca
>
> frantisek.borsik@gmail.com
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
>

[-- Attachment #2: Type: text/html, Size: 4043 bytes --]

Re: [NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole"

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 2527 bytes --]

I have not read this but I am pretty sure it does not ban fair queuing.

On Friday, May 10, 2024, Mike Conlow via Nnagain <
nnagain@lists.bufferbloat.net> wrote:

> I'm sure this was a difficult thing to write a regulation on. I'm glad the
> FCC took a swing. Here's why:
>
> If the Internet community wants to [continue] to develop technologies
> where applications (or users) can signal a need for low latency treatment
> and other networks in the path can honor that need -- great.
>
> But one of the networks in the chain -- the access network -- making the
> determination of what types of traffic get the low latency treatment, in my
> personal opinion is reasonably interpreted as throttling.
>
> I think it's also worth noting that these rules only apply to last-mile
> mass-market ISP plans. And any network is still free to offer "network
> slicing" as an enterprise offering, which I'm sure they will.
>
> On Fri, May 10, 2024 at 10:32 AM Frantisek Borsik via Nnagain <
> nnagain@lists.bufferbloat.net> wrote:
>
>> "Net neutrality proponents argued that these separate lanes for different
>> kinds of traffic would degrade performance of traffic that isn't favored.
>> The final FCC order released yesterday addresses that complaint.
>>
>> "We clarify that a BIAS [Broadband Internet Access Service] provider's
>> decision to speed up 'on the basis of Internet content, applications, or
>> services' would 'impair or degrade' other content, applications, or
>> services which are not given the same treatment," the FCC's final order
>> said.
>>
>> The "impair or degrade" clarification means that speeding up is banned
>> because the no-throttling rule says that ISPs "shall not impair or degrade
>> lawful Internet traffic on the basis of Internet content, application, or
>> service."
>>
>> https://arstechnica.com/tech-policy/2024/05/fcc-explicitly-
>> prohibits-fast-lanes-closing-possible-net-neutrality-loophole/
>>
>>
>> All the best,
>>
>> Frank
>>
>> Frantisek (Frank) Borsik
>>
>>
>>
>> https://www.linkedin.com/in/frantisekborsik
>>
>> Signal, Telegram, WhatsApp: +421919416714
>>
>> iMessage, mobile: +420775230885
>>
>> Skype: casioa5302ca
>>
>> frantisek.borsik@gmail.com
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>>
>

-- 
https://www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s Waves Podcast
Dave Täht CSO, LibreQos

[-- Attachment #2: Type: text/html, Size: 4692 bytes --]

Re: [NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole"

[Karl Auerbach]

[-- Attachment #1: Type: text/plain, Size: 4050 bytes --]

As a matter of drafting the FCC has left some potholes:

"We clarify that a BIAS [Broadband Internet Access Service] provider's 
decision to speed up 'on the basis of Internet content, applications, or 
services' would 'impair or degrade' other content, applications, or 
services which are not given the same treatment,"

That phrase "speed up" is too vague.  Does it conflict with active or 
fair queue management?  Does it prohibit things that some Ethernet NIC 
"offloads" do (but which could be done by a provider) such as TCP data 
aggregation (i.e. the merging of lots of small TCP segments into one big 
one)? Does it prohibit insertion of an ECN bit that would have the 
effect of slowing a sender of packets?  Might it preclude a provider 
"helpfully" dropping stale video packets that would arrive at a users 
video rendering codec too late to be useful?  Could there be an issue 
with selective compression?  Or, to really get nerdy - given that a lot 
of traffic uses Ethernet frames as a model, there can be a non-trivial 
amount of hidden, usually unused, bandwidth in that gap between the end 
of tiny IP packets and the end of minimum length Ethernet frames. (I've 
seen that space used for things like license management.)  Or might this 
impact larger path issues, such as routing choices, either dynamic or 
based on contractual relationships - such as conversational voice over 
terrestrial or low-earth-orbit paths while background file transfers are 
sent via fat, but large latency paths such as geo-synch satellite?  If 
an ISP found a means of blocking spam from being delivered, would that 
violate the rules?  (Same question for blocking of VoIP calls from 
undesirable sources.  It may also call into question even the use of IP 
address blacklists or reverse path algorithms that block traffic coming 
from places where it has no business coming from.)

The answers may be obvious to tech folks here but in the hands of 
troublesome lawyers (I'm one of those) these ambiguities could be 
elevated to be real headaches.

These may seem like minor or even meaningless nits, but these are the 
kinds of things that can be used by lawyers (again, like me) to tie 
regulatory bodies into knots, which often a goal of some large 
organizations that do not like regulation.

In addition, I can't put my finger on it, but I am sensing that without 
some flexibility the FCC neutrality rules may be creating a kind of no 
cost, tragedy of the commons situation.  Sometimes a bit of friction - 
cost - can be useful to either incentivize improvements and invention or 
to make things (like spam) less desirable/more expensive to abusers.

         --karl--

On 5/10/24 7:31 AM, Frantisek Borsik via Nnagain wrote:
> "Net neutrality proponents argued that these separate lanes for 
> different kinds of traffic would degrade performance of traffic that 
> isn't favored. The final FCC order released yesterday addresses that 
> complaint.
>
> "We clarify that a BIAS [Broadband Internet Access Service] provider's 
> decision to speed up 'on the basis of Internet content, applications, 
> or services' would 'impair or degrade' other content, applications, or 
> services which are not given the same treatment," the FCC's final 
> order said.
>
> The "impair or degrade" clarification means that speeding up is banned 
> because the no-throttling rule says that ISPs "shall not impair or 
> degrade lawful Internet traffic on the basis of Internet content, 
> application, or service."
>
> https://arstechnica.com/tech-policy/2024/05/fcc-explicitly-prohibits-fast-lanes-closing-possible-net-neutrality-loophole/
>
>
> All the best,
>
> Frank
>
> Frantisek (Frank) Borsik
>
> https://www.linkedin.com/in/frantisekborsik
>
> Signal, Telegram, WhatsApp: +421919416714
>
> iMessage, mobile: +420775230885
>
> Skype: casioa5302ca
>
> frantisek.borsik@gmail.com
>
>
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain

[-- Attachment #2: Type: text/html, Size: 8205 bytes --]

Re: [NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole"

[Robert McMahon]

[-- Attachment #1: Type: text/plain, Size: 5528 bytes --]

Hmm, seems more about wiglomeration than regulation.  Per Dickens,

"Here he is, Esther," said Mr. Jarndyce, comfortably putting his hands into
his pockets and stretching out his legs. "He must have a profession; he
must make some choice for himself. There will be a world more wiglomeration
about it, I suppose, but it must be done."

"More what, guardian?" said I.

"More wiglomeration," said he. "It's the only name I know for the thing. He
is a ward in Chancery, my dear. Kenge and Carboy will have something to say
about it; Master Somebody--a sort of ridiculous sexton, digging graves for
the merits of causes in a back room at the end of Quality Court, Chancery
Lane--will have something to say about it; counsel will have something to
say about it; the Chancellor will have something to say about it; the
satellites will have something to say about it; they will all have to be
handsomely feed, all round, about it; the whole thing will be vastly
ceremonious, wordy, unsatisfactory, and expensive, and I call it, in
general, wiglomeration. How mankind ever came to be afflicted with
wiglomeration, or for whose sins these young people ever fell into a pit of
it, I don't know; so it is."

On Wed, May 15, 2024, 2:43 PM Karl Auerbach via Nnagain <
nnagain@lists.bufferbloat.net> wrote:

> As a matter of drafting the FCC has left some potholes:
>
> "We clarify that a BIAS [Broadband Internet Access Service] provider's
> decision to speed up 'on the basis of Internet content, applications, or
> services' would 'impair or degrade' other content, applications, or
> services which are not given the same treatment,"
>
> That phrase "speed up" is too vague.  Does it conflict with active or fair
> queue management?  Does it prohibit things that some Ethernet NIC
> "offloads" do (but which could be done by a provider) such as TCP data
> aggregation (i.e. the merging of lots of small TCP segments into one big
> one)? Does it prohibit insertion of an ECN bit that would have the effect
> of slowing a sender of packets?  Might it preclude a provider "helpfully"
> dropping stale video packets that would arrive at a users video rendering
> codec too late to be useful?  Could there be an issue with selective
> compression?  Or, to really get nerdy - given that a lot of traffic uses
> Ethernet frames as a model, there can be a non-trivial amount of hidden,
> usually unused, bandwidth in that gap between the end of tiny IP packets
> and the end of minimum length Ethernet frames. (I've seen that space used
> for things like license management.)  Or might this impact larger path
> issues, such as routing choices, either dynamic or based on contractual
> relationships - such as conversational voice over terrestrial or
> low-earth-orbit paths while background file transfers are sent via fat, but
> large latency paths such as geo-synch satellite?  If an ISP found a means
> of blocking spam from being delivered, would that violate the rules?  (Same
> question for blocking of VoIP calls from undesirable sources.  It may also
> call into question even the use of IP address blacklists or reverse path
> algorithms that block traffic coming from places where it has no business
> coming from.)
>
> The answers may be obvious to tech folks here but in the hands of
> troublesome lawyers (I'm one of those) these ambiguities could be elevated
> to be real headaches.
>
> These may seem like minor or even meaningless nits, but these are the
> kinds of things that can be used by lawyers (again, like me) to tie
> regulatory bodies into knots, which often a goal of some large
> organizations that do not like regulation.
>
> In addition, I can't put my finger on it, but I am sensing that without
> some flexibility the FCC neutrality rules may be creating a kind of no
> cost, tragedy of the commons situation.  Sometimes a bit of friction - cost
> - can be useful to either incentivize improvements and invention or to make
> things (like spam) less desirable/more expensive to abusers.
>
>         --karl--
> On 5/10/24 7:31 AM, Frantisek Borsik via Nnagain wrote:
>
> "Net neutrality proponents argued that these separate lanes for different
> kinds of traffic would degrade performance of traffic that isn't favored.
> The final FCC order released yesterday addresses that complaint.
>
> "We clarify that a BIAS [Broadband Internet Access Service] provider's
> decision to speed up 'on the basis of Internet content, applications, or
> services' would 'impair or degrade' other content, applications, or
> services which are not given the same treatment," the FCC's final order
> said.
>
> The "impair or degrade" clarification means that speeding up is banned
> because the no-throttling rule says that ISPs "shall not impair or degrade
> lawful Internet traffic on the basis of Internet content, application, or
> service."
>
>
> https://arstechnica.com/tech-policy/2024/05/fcc-explicitly-prohibits-fast-lanes-closing-possible-net-neutrality-loophole/
>
>
> All the best,
>
> Frank
>
> Frantisek (Frank) Borsik
>
>
>
> https://www.linkedin.com/in/frantisekborsik
>
> Signal, Telegram, WhatsApp: +421919416714
>
> iMessage, mobile: +420775230885
>
> Skype: casioa5302ca
>
> frantisek.borsik@gmail.com
>
> _______________________________________________
> Nnagain mailing listNnagain@lists.bufferbloat.nethttps://lists.bufferbloat.net/listinfo/nnagain
>
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
>

[-- Attachment #2: Type: text/html, Size: 9828 bytes --]

Re: [NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole"

[Vint Cerf]

[-- Attachment #1.1: Type: text/plain, Size: 4838 bytes --]

An interpretation of the intent might be not so much a prohibition of
various grades of service but that all grades are available on the same
terms to all comers.

v


On Wed, May 15, 2024 at 5:43 PM Karl Auerbach via Nnagain <
nnagain@lists.bufferbloat.net> wrote:

> As a matter of drafting the FCC has left some potholes:
>
> "We clarify that a BIAS [Broadband Internet Access Service] provider's
> decision to speed up 'on the basis of Internet content, applications, or
> services' would 'impair or degrade' other content, applications, or
> services which are not given the same treatment,"
>
> That phrase "speed up" is too vague.  Does it conflict with active or fair
> queue management?  Does it prohibit things that some Ethernet NIC
> "offloads" do (but which could be done by a provider) such as TCP data
> aggregation (i.e. the merging of lots of small TCP segments into one big
> one)? Does it prohibit insertion of an ECN bit that would have the effect
> of slowing a sender of packets?  Might it preclude a provider "helpfully"
> dropping stale video packets that would arrive at a users video rendering
> codec too late to be useful?  Could there be an issue with selective
> compression?  Or, to really get nerdy - given that a lot of traffic uses
> Ethernet frames as a model, there can be a non-trivial amount of hidden,
> usually unused, bandwidth in that gap between the end of tiny IP packets
> and the end of minimum length Ethernet frames. (I've seen that space used
> for things like license management.)  Or might this impact larger path
> issues, such as routing choices, either dynamic or based on contractual
> relationships - such as conversational voice over terrestrial or
> low-earth-orbit paths while background file transfers are sent via fat, but
> large latency paths such as geo-synch satellite?  If an ISP found a means
> of blocking spam from being delivered, would that violate the rules?  (Same
> question for blocking of VoIP calls from undesirable sources.  It may also
> call into question even the use of IP address blacklists or reverse path
> algorithms that block traffic coming from places where it has no business
> coming from.)
>
> The answers may be obvious to tech folks here but in the hands of
> troublesome lawyers (I'm one of those) these ambiguities could be elevated
> to be real headaches.
>
> These may seem like minor or even meaningless nits, but these are the
> kinds of things that can be used by lawyers (again, like me) to tie
> regulatory bodies into knots, which often a goal of some large
> organizations that do not like regulation.
>
> In addition, I can't put my finger on it, but I am sensing that without
> some flexibility the FCC neutrality rules may be creating a kind of no
> cost, tragedy of the commons situation.  Sometimes a bit of friction - cost
> - can be useful to either incentivize improvements and invention or to make
> things (like spam) less desirable/more expensive to abusers.
>
>         --karl--
> On 5/10/24 7:31 AM, Frantisek Borsik via Nnagain wrote:
>
> "Net neutrality proponents argued that these separate lanes for different
> kinds of traffic would degrade performance of traffic that isn't favored.
> The final FCC order released yesterday addresses that complaint.
>
> "We clarify that a BIAS [Broadband Internet Access Service] provider's
> decision to speed up 'on the basis of Internet content, applications, or
> services' would 'impair or degrade' other content, applications, or
> services which are not given the same treatment," the FCC's final order
> said.
>
> The "impair or degrade" clarification means that speeding up is banned
> because the no-throttling rule says that ISPs "shall not impair or degrade
> lawful Internet traffic on the basis of Internet content, application, or
> service."
>
>
> https://arstechnica.com/tech-policy/2024/05/fcc-explicitly-prohibits-fast-lanes-closing-possible-net-neutrality-loophole/
>
>
> All the best,
>
> Frank
>
> Frantisek (Frank) Borsik
>
>
>
> https://www.linkedin.com/in/frantisekborsik
>
> Signal, Telegram, WhatsApp: +421919416714 <+421%20919%20416%20714>
>
> iMessage, mobile: +420775230885 <+420%20775%20230%20885>
>
> Skype: casioa5302ca
>
> frantisek.borsik@gmail.com
>
> _______________________________________________
> Nnagain mailing listNnagain@lists.bufferbloat.nethttps://lists.bufferbloat.net/listinfo/nnagain
>
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice

[-- Attachment #1.2: Type: text/html, Size: 8934 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4006 bytes --]

Re: [NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole"

[Jack Haverty]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 6455 bytes --]

Whatever "the service" is, I wonder what the new rules imply about how 
traffic is processed.

Even 40 years ago, we tried lots of heuristics to improve performance.  
One example I remember was treating datagrams differently depending 
simply on the size of their content.   Putting a minimal-length datagram 
at the front of the output queue would slightly "degrade" the service 
delivered to the large datagrams behind it, but it might avoid a 
retransmission by delivering an ACK before a retransmission timer ran out.

If the new rules prohibit such behavior, I suspect a lot of more modern 
"smart queue" strategies might be also prohibited, such that all 
datagrams are given the exact same treatment.   FIFO may now be the law?

With circuits in the 80s running <56kb/sec, such scenarios were of real 
concern.  Today, with "bufferbloat" and such characteristics of the 
Internet, the scenarios are different but still exist.

Jack Haverty

On 5/15/24 17:55, Vint Cerf via Nnagain wrote:
> An interpretation of the intent might be not so much a prohibition of 
> various grades of service but that all grades are available on the 
> same terms to all comers.
>
> v
>
>
> On Wed, May 15, 2024 at 5:43 PM Karl Auerbach via Nnagain 
> <nnagain@lists.bufferbloat.net> wrote:
>
>     As a matter of drafting the FCC has left some potholes:
>
>     "We clarify that a BIAS [Broadband Internet Access Service]
>     provider's decision to speed up 'on the basis of Internet content,
>     applications, or services' would 'impair or degrade' other
>     content, applications, or services which are not given the same
>     treatment,"
>
>     That phrase "speed up" is too vague.  Does it conflict with active
>     or fair queue management?  Does it prohibit things that some
>     Ethernet NIC "offloads" do (but which could be done by a provider)
>     such as TCP data aggregation (i.e. the merging of lots of small
>     TCP segments into one big one)? Does it prohibit insertion of an
>     ECN bit that would have the effect of slowing a sender of packets?
>     Might it preclude a provider "helpfully" dropping stale video
>     packets that would arrive at a users video rendering codec too
>     late to be useful?  Could there be an issue with selective
>     compression?  Or, to really get nerdy - given that a lot of
>     traffic uses Ethernet frames as a model, there can be a
>     non-trivial amount of hidden, usually unused, bandwidth in that
>     gap between the end of tiny IP packets and the end of minimum
>     length Ethernet frames. (I've seen that space used for things like
>     license management.)  Or might this impact larger path issues,
>     such as routing choices, either dynamic or based on contractual
>     relationships - such as conversational voice over terrestrial or
>     low-earth-orbit paths while background file transfers are sent via
>     fat, but large latency paths such as geo-synch satellite?  If an
>     ISP found a means of blocking spam from being delivered, would
>     that violate the rules?  (Same question for blocking of VoIP calls
>     from undesirable sources.  It may also call into question even the
>     use of IP address blacklists or reverse path algorithms that block
>     traffic coming from places where it has no business coming from.)
>
>     The answers may be obvious to tech folks here but in the hands of
>     troublesome lawyers (I'm one of those) these ambiguities could be
>     elevated to be real headaches.
>
>     These may seem like minor or even meaningless nits, but these are
>     the kinds of things that can be used by lawyers (again, like me)
>     to tie regulatory bodies into knots, which often a goal of some
>     large organizations that do not like regulation.
>
>     In addition, I can't put my finger on it, but I am sensing that
>     without some flexibility the FCC neutrality rules may be creating
>     a kind of no cost, tragedy of the commons situation.  Sometimes a
>     bit of friction - cost - can be useful to either incentivize
>     improvements and invention or to make things (like spam) less
>     desirable/more expensive to abusers.
>
>             --karl--
>
>     On 5/10/24 7:31 AM, Frantisek Borsik via Nnagain wrote:
>>     "Net neutrality proponents argued that these separate lanes for
>>     different kinds of traffic would degrade performance of traffic
>>     that isn't favored. The final FCC order released yesterday
>>     addresses that complaint.
>>
>>     "We clarify that a BIAS [Broadband Internet Access Service]
>>     provider's decision to speed up 'on the basis of Internet
>>     content, applications, or services' would 'impair or degrade'
>>     other content, applications, or services which are not given the
>>     same treatment," the FCC's final order said.
>>
>>     The "impair or degrade" clarification means that speeding up is
>>     banned because the no-throttling rule says that ISPs "shall not
>>     impair or degrade lawful Internet traffic on the basis of
>>     Internet content, application, or service."
>>
>>     https://arstechnica.com/tech-policy/2024/05/fcc-explicitly-prohibits-fast-lanes-closing-possible-net-neutrality-loophole/
>>
>>
>>     All the best,
>>
>>     Frank
>>
>>     Frantisek (Frank) Borsik
>>
>>     https://www.linkedin.com/in/frantisekborsik
>>
>>     Signal, Telegram, WhatsApp: +421919416714
>>     <tel:+421%20919%20416%20714>
>>
>>     iMessage, mobile: +420775230885 <tel:+420%20775%20230%20885>
>>
>>     Skype: casioa5302ca
>>
>>     frantisek.borsik@gmail.com
>>
>>
>>     _______________________________________________
>>     Nnagain mailing list
>>     Nnagain@lists.bufferbloat.net
>>     https://lists.bufferbloat.net/listinfo/nnagain
>     _______________________________________________
>     Nnagain mailing list
>     Nnagain@lists.bufferbloat.net
>     https://lists.bufferbloat.net/listinfo/nnagain
>
>
>
> -- 
> Please send any postal/overnight deliveries to:
> Vint Cerf
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346
>
>
> until further notice
>
>
>
>
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain


[-- Attachment #1.1.1.2: Type: text/html, Size: 13611 bytes --]

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 2469 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 665 bytes --]

Re: [NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole"

[Mike Conlow]

[-- Attachment #1: Type: text/plain, Size: 7181 bytes --]

It's important to remember that "reasonable network management" allows a
lot of the things being discussed as examples here. Specifically:

"As in past Orders, we continue to recognize that in order to optimize
> end-user experience, BIAS providers must be permitted to engage in
> reasonable network management practices." (para 499)


While I don't love the "speed up" language either, it seems clear from my
reading that these rules target the case where the ISP intervenes to apply
a traffic policy to certain types of traffic that are not open to any
application, thereby "throttling" the selected traffic w/r/t any other
traffic (and it's not reasonable network management because they're
charging the user).




On Wed, May 15, 2024 at 9:14 PM Jack Haverty via Nnagain <
nnagain@lists.bufferbloat.net> wrote:

> Whatever "the service" is, I wonder what the new rules imply about how
> traffic is processed.
>
> Even 40 years ago, we tried lots of heuristics to improve performance.
> One example I remember was treating datagrams differently depending simply
> on the size of their content.   Putting a minimal-length datagram at the
> front of the output queue would slightly "degrade" the service delivered to
> the large datagrams behind it, but it might avoid a retransmission by
> delivering an ACK before a retransmission timer ran out.
>
> If the new rules prohibit such behavior, I suspect a lot of more modern
> "smart queue" strategies might be also prohibited, such that all datagrams
> are given the exact same treatment.   FIFO may now be the law?
>
> With circuits in the 80s running <56kb/sec, such scenarios were of real
> concern.  Today, with "bufferbloat" and such characteristics of the
> Internet, the scenarios are different but still exist.
>
> Jack Haverty
>
> On 5/15/24 17:55, Vint Cerf via Nnagain wrote:
>
> An interpretation of the intent might be not so much a prohibition of
> various grades of service but that all grades are available on the same
> terms to all comers.
>
> v
>
>
> On Wed, May 15, 2024 at 5:43 PM Karl Auerbach via Nnagain <
> nnagain@lists.bufferbloat.net> wrote:
>
>> As a matter of drafting the FCC has left some potholes:
>>
>> "We clarify that a BIAS [Broadband Internet Access Service] provider's
>> decision to speed up 'on the basis of Internet content, applications, or
>> services' would 'impair or degrade' other content, applications, or
>> services which are not given the same treatment,"
>>
>> That phrase "speed up" is too vague.  Does it conflict with active or
>> fair queue management?  Does it prohibit things that some Ethernet NIC
>> "offloads" do (but which could be done by a provider) such as TCP data
>> aggregation (i.e. the merging of lots of small TCP segments into one big
>> one)? Does it prohibit insertion of an ECN bit that would have the effect
>> of slowing a sender of packets?  Might it preclude a provider "helpfully"
>> dropping stale video packets that would arrive at a users video rendering
>> codec too late to be useful?  Could there be an issue with selective
>> compression?  Or, to really get nerdy - given that a lot of traffic uses
>> Ethernet frames as a model, there can be a non-trivial amount of hidden,
>> usually unused, bandwidth in that gap between the end of tiny IP packets
>> and the end of minimum length Ethernet frames. (I've seen that space used
>> for things like license management.)  Or might this impact larger path
>> issues, such as routing choices, either dynamic or based on contractual
>> relationships - such as conversational voice over terrestrial or
>> low-earth-orbit paths while background file transfers are sent via fat, but
>> large latency paths such as geo-synch satellite?  If an ISP found a means
>> of blocking spam from being delivered, would that violate the rules?  (Same
>> question for blocking of VoIP calls from undesirable sources.  It may also
>> call into question even the use of IP address blacklists or reverse path
>> algorithms that block traffic coming from places where it has no business
>> coming from.)
>>
>> The answers may be obvious to tech folks here but in the hands of
>> troublesome lawyers (I'm one of those) these ambiguities could be elevated
>> to be real headaches.
>>
>> These may seem like minor or even meaningless nits, but these are the
>> kinds of things that can be used by lawyers (again, like me) to tie
>> regulatory bodies into knots, which often a goal of some large
>> organizations that do not like regulation.
>>
>> In addition, I can't put my finger on it, but I am sensing that without
>> some flexibility the FCC neutrality rules may be creating a kind of no
>> cost, tragedy of the commons situation.  Sometimes a bit of friction - cost
>> - can be useful to either incentivize improvements and invention or to make
>> things (like spam) less desirable/more expensive to abusers.
>>
>>         --karl--
>> On 5/10/24 7:31 AM, Frantisek Borsik via Nnagain wrote:
>>
>> "Net neutrality proponents argued that these separate lanes for different
>> kinds of traffic would degrade performance of traffic that isn't favored.
>> The final FCC order released yesterday addresses that complaint.
>>
>> "We clarify that a BIAS [Broadband Internet Access Service] provider's
>> decision to speed up 'on the basis of Internet content, applications, or
>> services' would 'impair or degrade' other content, applications, or
>> services which are not given the same treatment," the FCC's final order
>> said.
>>
>> The "impair or degrade" clarification means that speeding up is banned
>> because the no-throttling rule says that ISPs "shall not impair or degrade
>> lawful Internet traffic on the basis of Internet content, application, or
>> service."
>>
>>
>> https://arstechnica.com/tech-policy/2024/05/fcc-explicitly-prohibits-fast-lanes-closing-possible-net-neutrality-loophole/
>>
>>
>> All the best,
>>
>> Frank
>>
>> Frantisek (Frank) Borsik
>>
>>
>>
>> https://www.linkedin.com/in/frantisekborsik
>>
>> Signal, Telegram, WhatsApp: +421919416714 <+421%20919%20416%20714>
>>
>> iMessage, mobile: +420775230885 <+420%20775%20230%20885>
>>
>> Skype: casioa5302ca
>>
>> frantisek.borsik@gmail.com
>>
>> _______________________________________________
>> Nnagain mailing listNnagain@lists.bufferbloat.nethttps://lists.bufferbloat.net/listinfo/nnagain
>>
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>>
>
>
> --
> Please send any postal/overnight deliveries to:
> Vint Cerf
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346
>
>
> until further notice
>
>
>
>
> _______________________________________________
> Nnagain mailing listNnagain@lists.bufferbloat.nethttps://lists.bufferbloat.net/listinfo/nnagain
>
>
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
>

[-- Attachment #2: Type: text/html, Size: 13969 bytes --]

Re: [NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole"

[Karl Auerbach]

[-- Attachment #1: Type: text/plain, Size: 7887 bytes --]

You are right, a simple expression of the goal is almost certainly a far 
better way to express a regulation than an endlessly detailed 
enumeration of things.

My concerns arise from a variety of sources.

First is the natural inclination of some large organizations to use 
regulatory language as a weapon, often twisting inadequately detailed 
expressions of intent around a Procrustean iron bed of regulatory 
definitions.

Second is that the US Supreme Court seems to be tending to cast disdain 
on the expertise of regulatory bodies, such as the FCC, to find sensible 
ways through difficult and ambiguous situations. (This legal stuff tends 
to go under the header of "Chevron deference" - 
https://www.law.cornell.edu/wex/chevron_deference ) Personally, I'd 
rather that smart people at the FCC figure this out rather than a bunch 
of j-random Congress critters.

Third is that sometimes it is useful to have a bit of financial or 
competitive fire to push innovation or to impede ill use. (Imagine if 
sending emails had a cost - that could have [perhaps] have slowed the 
rise of spam.)  So perhaps a small amount of non-neutrality could act as 
a driver or catalyst.

I am intrigued by the possibility of obtaining better efficiency from 
the net - by using underused bandwidth (hence my example of the spare 
space where a small IP packet does not fully occupy a minimum sized 
Ethernet frame.)  Some of these ideas could cause streams to piggyback 
on one another (such as how SMS messaging kinda piggybacked into the 
empty spaces of telco signalling protocols.)  We tend to focus our 
attention of big fat flows, like entertainment video or gaming, but 
there are a lot of small flows that could ride, with adequately 
reliability, for essentially no technical cost. These could include a 
lot of home, security, or medical monitoring stuff.)  This is hard to 
articulate - but there are real life analogies, such as the notion of 
van-pooling to airports, where a single vehicle carries diverse 
loads/passengers that have little relationship to one another except 
that they are traveling to and from roughly the same locations.)

A while back I wrote some notes about network measuring tools such as 
iperf.  One of the things that struck me was the number of bits that 
wrap even the smallest of packets. (For instance - 
https://www.iwl.com/blog/counting-bits )  For video that overhead is 
negligible, but for some forms of traffic (e.g. security alarms) that 
overhead can add up.

And yes, I am stepping dangerously close to notions of multiplexing 
within packets or at least within one of our most common wrappers for IP 
packets, Ethernet frames.

         --karl--

On 5/15/24 5:55 PM, Vint Cerf wrote:
> An interpretation of the intent might be not so much a prohibition of 
> various grades of service but that all grades are available on the 
> same terms to all comers.
>
> v
>
>
> On Wed, May 15, 2024 at 5:43 PM Karl Auerbach via Nnagain 
> <nnagain@lists.bufferbloat.net> wrote:
>
>     As a matter of drafting the FCC has left some potholes:
>
>     "We clarify that a BIAS [Broadband Internet Access Service]
>     provider's decision to speed up 'on the basis of Internet content,
>     applications, or services' would 'impair or degrade' other
>     content, applications, or services which are not given the same
>     treatment,"
>
>     That phrase "speed up" is too vague.  Does it conflict with active
>     or fair queue management?  Does it prohibit things that some
>     Ethernet NIC "offloads" do (but which could be done by a provider)
>     such as TCP data aggregation (i.e. the merging of lots of small
>     TCP segments into one big one)? Does it prohibit insertion of an
>     ECN bit that would have the effect of slowing a sender of packets?
>     Might it preclude a provider "helpfully" dropping stale video
>     packets that would arrive at a users video rendering codec too
>     late to be useful?  Could there be an issue with selective
>     compression?  Or, to really get nerdy - given that a lot of
>     traffic uses Ethernet frames as a model, there can be a
>     non-trivial amount of hidden, usually unused, bandwidth in that
>     gap between the end of tiny IP packets and the end of minimum
>     length Ethernet frames. (I've seen that space used for things like
>     license management.)  Or might this impact larger path issues,
>     such as routing choices, either dynamic or based on contractual
>     relationships - such as conversational voice over terrestrial or
>     low-earth-orbit paths while background file transfers are sent via
>     fat, but large latency paths such as geo-synch satellite?  If an
>     ISP found a means of blocking spam from being delivered, would
>     that violate the rules?  (Same question for blocking of VoIP calls
>     from undesirable sources.  It may also call into question even the
>     use of IP address blacklists or reverse path algorithms that block
>     traffic coming from places where it has no business coming from.)
>
>     The answers may be obvious to tech folks here but in the hands of
>     troublesome lawyers (I'm one of those) these ambiguities could be
>     elevated to be real headaches.
>
>     These may seem like minor or even meaningless nits, but these are
>     the kinds of things that can be used by lawyers (again, like me)
>     to tie regulatory bodies into knots, which often a goal of some
>     large organizations that do not like regulation.
>
>     In addition, I can't put my finger on it, but I am sensing that
>     without some flexibility the FCC neutrality rules may be creating
>     a kind of no cost, tragedy of the commons situation.  Sometimes a
>     bit of friction - cost - can be useful to either incentivize
>     improvements and invention or to make things (like spam) less
>     desirable/more expensive to abusers.
>
>             --karl--
>
>     On 5/10/24 7:31 AM, Frantisek Borsik via Nnagain wrote:
>>     "Net neutrality proponents argued that these separate lanes for
>>     different kinds of traffic would degrade performance of traffic
>>     that isn't favored. The final FCC order released yesterday
>>     addresses that complaint.
>>
>>     "We clarify that a BIAS [Broadband Internet Access Service]
>>     provider's decision to speed up 'on the basis of Internet
>>     content, applications, or services' would 'impair or degrade'
>>     other content, applications, or services which are not given the
>>     same treatment," the FCC's final order said.
>>
>>     The "impair or degrade" clarification means that speeding up is
>>     banned because the no-throttling rule says that ISPs "shall not
>>     impair or degrade lawful Internet traffic on the basis of
>>     Internet content, application, or service."
>>
>>     https://arstechnica.com/tech-policy/2024/05/fcc-explicitly-prohibits-fast-lanes-closing-possible-net-neutrality-loophole/
>>
>>
>>     All the best,
>>
>>     Frank
>>
>>     Frantisek (Frank) Borsik
>>
>>     https://www.linkedin.com/in/frantisekborsik
>>
>>     Signal, Telegram, WhatsApp: +421919416714
>>     <tel:+421%20919%20416%20714>
>>
>>     iMessage, mobile: +420775230885 <tel:+420%20775%20230%20885>
>>
>>     Skype: casioa5302ca
>>
>>     frantisek.borsik@gmail.com
>>
>>
>>     _______________________________________________
>>     Nnagain mailing list
>>     Nnagain@lists.bufferbloat.net
>>     https://lists.bufferbloat.net/listinfo/nnagain
>     _______________________________________________
>     Nnagain mailing list
>     Nnagain@lists.bufferbloat.net
>     https://lists.bufferbloat.net/listinfo/nnagain
>
>
>
> -- 
> Please send any postal/overnight deliveries to:
> Vint Cerf
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346
>
>
> until further notice
>
>
>

[-- Attachment #2: Type: text/html, Size: 14994 bytes --]

Re: [NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole"

[Sebastian Moeller]

Hi Karl,

being a lawyer you know how this works, until a court come to an interpretation all is in some degree of limbo, so if you want clarification sue somebody to force an interpretation ;)


> On 15. May 2024, at 23:43, Karl Auerbach via Nnagain <nnagain@lists.bufferbloat.net> wrote:
> 
> As a matter of drafting the FCC has left some potholes:
> "We clarify that a BIAS [Broadband Internet Access Service] provider's decision to speed up 'on the basis of Internet content, applications, or services' would 'impair or degrade' other content, applications, or services which are not given the same treatment,"
> That phrase "speed up" is too vague. 

[SM] I wholeheartedly agree, speed is delta distance/delta time, and is typically 2/3 of the speed of light in vacuum for almost all internet access technologies and not really what an ISP sells, they offer capacity or information rate, not speed.

> Does it conflict with active or fair queue management? 

[SM] No it does not, equitable sharing between entities is a core principle behind the internet fair queuing is just the consequent implementation of the IETF's 'do not starve any flow' principle... you could rather argue that not doing equitable sharing might get you in hot water. (Sidenote the IMHO best argument for equitable sharing is not that it is the 'most best' policy but that it is the 'least bad', to elaborate knowing the relative importance of data packets one can do a lot better than treating all equal, but lacking that knowledge treating all equally is what avoids really bad outcomes, and since arbitrary bottlenecks never will have robust and reliable information about the relative importance of packets... equitable sharng is the 'good enough' solution.)

> Does it prohibit things that some Ethernet NIC "offloads" do (but which could be done by a provider) such as TCP data aggregation (i.e. the merging of lots of small TCP segments into one big one)?

[SM] No the relevant TCP stack actions happens on the end points not the ISP, the ISP's job is to transport the data, if that entails transient merging and re-segmentation as long as that is opaque to the end user no. Another thing is ACK filtering where ISPs interfere with customer data, albeit with the goal to improve the link quality for the customer.

> Does it prohibit insertion of an ECN bit that would have the effect of slowing a sender of packets? 

[SM] Not really, as alternatively a packet would have been dropped with even more drastic effects, not only is this a 'slow down' signal but the dropped packet will need to be retransmitted....

> Might it preclude a provider "helpfully" dropping stale video packets that would arrive at a users video rendering codec too late to be useful? 

[SM] Hard to say, even  a late packet might help decoding later packets versus dropping it, so I would argue not the ISPs business to interfere.

> Could there be an issue with selective compression? 

[SM] Yes, if an ISP recompresses material unasked he better make sure the compression is completely invisible to the end user, which IMHO rules out lossy compression schemes. An ISP is in the business of transporting bits not manipulating bits.

> Or, to really get nerdy - given that a lot of traffic uses Ethernet frames as a model, there can be a non-trivial amount of hidden, usually unused, bandwidth in that gap between the end of tiny IP packets and the end of minimum length Ethernet frames. (I've seen that space used for things like license management.) 

[SM] The maximal minimum payload size for ethernet is 46 bytes (with VLAN only 42), an IPv4 header takes 20 bytes, a UDP or TCP header another 20, so we are down to 6-2 bytes for license management (controllable ny the user via adding a VLAN tag) that seems a harebrained idea based on 'nobody is going to look there'. More space left over with ICMP or ARP... 
But at least that is novel, all I knew is that the MACs of network cards have been used for licensing.

> Or might this impact larger path issues, such as routing choices, either dynamic or based on contractual relationships - such as conversational voice over terrestrial or low-earth-orbit paths while background file transfers are sent via fat, but large latency paths such as geo-synch satellite? 
> If an ISP found a means of blocking spam from being delivered, would that violate the rules?  (Same question for blocking of VoIP calls from undesirable sources. 

[SM] That one is easy, if the ISP acts under explicit instruction of the end user this is A-OK otherwise not.

> It may also call into question even the use of IP address blacklists or reverse path algorithms that block traffic coming from places where it has no business coming from.)

[SM] That is IMHO FUD, BCP38 still applies. That is normal network hygene...

> The answers may be obvious to tech folks here but in the hands of troublesome lawyers (I'm one of those) these ambiguities could be elevated to be real headaches.

[SM] But a headache you likely will be remunerated well for dealing with, no?

> These may seem like minor or even meaningless nits, but these are the kinds of things that can be used by lawyers (again, like me) to tie regulatory bodies into knots, which often a goal of some large organizations that do not like regulation.

[SM] Sure, see above thgis is why this requires court decisions, so maybe the best to do is bring your own cases to speed up that process?

> In addition, I can't put my finger on it, but I am sensing that without some flexibility the FCC neutrality rules may be creating a kind of no cost, tragedy of the commons situation. 

[SM] There is no tragedy of the commons, the commons are known as "commons" as they operated reasonably successful for a long time, it is the failure of meaningful policing/regulation of the rules towards their demise that made the commons fail. So repeat after me (or not), the tragedy of the commons really is just ineffective regulation and policing of the rules. We are discovering that the same is true of market economies, if you let the market players cheat/side step normal market mechanisms, markets fail to be efficient resource distribution optimisers. 

> Sometimes a bit of friction - cost - can be useful to either incentivize improvements and invention or to make things (like spam) less desirable/more expensive to abusers.

[SM] Indeed, the question is 'is the increase in inconvenience for  the abusers larger than for the normal users', because we might end up in a situation where all users now have increased friction plus SPAM...

Regards
	Sebastian

>         --karl--
> On 5/10/24 7:31 AM, Frantisek Borsik via Nnagain wrote:
>> "Net neutrality proponents argued that these separate lanes for different kinds of traffic would degrade performance of traffic that isn't favored. The final FCC order released yesterday addresses that complaint. 
>> 
>> "We clarify that a BIAS [Broadband Internet Access Service] provider's decision to speed up 'on the basis of Internet content, applications, or services' would 'impair or degrade' other content, applications, or services which are not given the same treatment," the FCC's final order said. 
>> 
>> The "impair or degrade" clarification means that speeding up is banned because the no-throttling rule says that ISPs "shall not impair or degrade lawful Internet traffic on the basis of Internet content, application, or service."
>> 
>> https://arstechnica.com/tech-policy/2024/05/fcc-explicitly-prohibits-fast-lanes-closing-possible-net-neutrality-loophole/
>> 
>> 
>> All the best,
>> 
>> Frank
>> Frantisek (Frank) Borsik
>>  
>> https://www.linkedin.com/in/frantisekborsik
>> Signal, Telegram, WhatsApp: +421919416714 
>> iMessage, mobile: +420775230885
>> Skype: casioa5302ca
>> frantisek.borsik@gmail.com
>> 
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>> 
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole"

[Livingood, Jason]

[-- Attachment #1: Type: text/plain, Size: 2444 bytes --]

> That phrase "speed up" is too vague.  Does it conflict with active or fair queue management?

No, I don’t think so. AQM is widely deployed to tens of millions of homes in the US – I don’t think the FCC’s intent is to ban such an obviously beneficial improvement in the internet. Rather, they are focused on the notion of creating paid-for “fast lanes” – such as where destination X pays ISP A to prioritize their internet content over other internet content, etc.

> Does it prohibit things that some Ethernet NIC "offloads" do (but which could be done by a provider) such as TCP data aggregation (i.e. the merging of lots of small TCP segments into one big one)?

No

> Does it prohibit insertion of an ECN bit that would have the effect of slowing a sender of packets?

No. The use of ECN as a congestion signal is specified in IETF RFCs, is already deployed, is an improvement on waiting for packet drops, and ECN deployment is growing and is to the benefit of internet users & traffic.

> Might it preclude a provider "helpfully" dropping stale video packets that would arrive at a users video rendering codec too late to be useful?

Maybe – this will fall into whether that is considered reasonable network management (and for example, why in must be done at the network layer rather than by the user’s client).

> Or might this impact larger path issues, such as routing choices, either dynamic or based on contractual relationships - such as conversational voice over terrestrial or low-earth-orbit paths while background file transfers are sent via fat, but large latency paths such as geo-synch satellite?

Maybe – could be a reasonable network management decision & it may take a complaint if some party felt disadvantaged - to define what is judged reasonable here.

> If an ISP found a means of blocking spam from being delivered, would that violate the rules?  (Same question for blocking of VoIP calls from undesirable sources.  It may also call into question even the use of IP address blacklists or reverse path algorithms that block traffic coming from places where it has no business coming from.)

Could be an issue – we’ll have to see what complaints arise. But likely also falls under the reasonable network management clause, especially if the traffic is not lawful and/or is malicious/abuse. In the past this has been challenging with shared/virtual infrastructure.

JL

[-- Attachment #2: Type: text/html, Size: 4173 bytes --]

Re: [NNagain] "FCC explicitly prohibits fast lanes, closing possible net neutrality loophole"

[Livingood, Jason]

[-- Attachment #1: Type: text/plain, Size: 271 bytes --]

> First is the natural inclination of some large organizations to use regulatory language as a weapon, often twisting inadequately detailed expressions of intent around a Procrustean iron bed of regulatory definitions.

Many people expect to see the same. ;-)

JL


[-- Attachment #2: Type: text/html, Size: 1864 bytes --]