I am having trouble connecting the goal of the requirement, the expected
protocol behavior, and the expected real-world operation.
Lets keep it simple. A master, connected by wired internet to the
World. A set of slaves who want to use whitespace to talk to the
master. All within a small physical space. All within the the time
limit of whatever answer the master gets from the database.
The Ofcom requirement is described as being important for understanding
interference effects. Therefore, presumably, it needs to relate to
actual spectrum usage.
The stated protocol behavior is that the master would reply to the
shitespace database with an ack indicating what it expects to use, at
what power level.
The way folks are writing this, I believe the intention is "respond once".
As I understand such master / slave behavior (and I am by no means a
radio expert), the actual usage of spectrum, within the whitespace band,
will depend upon how many slaves are active, and possibly on what they
are doing.
If the actual usage is going to depend upon the slave device population
/ behavior, then the only answer the master can correctly provide is "I
will use all of the whitespace you have identified, with the highest
power I might use.
Such an answer is a valid answer in terms of protocol and in terms of
the stated regulatory requirements. However, it is utterly useless in
terms of the stated goal.
As an engineer, I am very uncomfortable designing a protocol messaging
exchange which I know will not meet the end-users needs.
Note1: If I have mischaracterized ro misunderstood what folks ahve
explained, I apologize.
Note2: If instead the intention is for the master to update the database
every time it changes the spectrum usage pattern, then this is NOT an
acknowledgment of the reply from the database. It is a dynamic behavior
reporting requirement.
Yours,
Joel
On 3/9/2012 6:36 AM, [email protected] wrote:
Hi
My reading of the UK regulatory requirements that Ofcom has made available is
that the Acknowledgement message that must be communicated back to the database
from the white space device is simply the frequency range (or ranges) and
maximum eirp density that the device intends to use (a subset of what it would
have been offered by the database). I don't believe there is any intent to
limit modulation schemes etc. as part of this exchange. This seems a relatively
straightforward requirement and the PAWS protocol should accommodate this if it
is to be relevant for the UK regulatory environment.
Regards,
Chris
-----Original Message-----
From: Paul Lambert [mailto:[email protected]]
Sent: 09 March 2012 02:15
To: Das, Subir; 'Siew Yoon Tan'; Zuniga, Juan Carlos;
[email protected]; [email protected]; [email protected];
[email protected]
Cc: [email protected]; [email protected]; Reza Karimi; Dixon,JS,Johnny,COD R;
Cheeseman,CJ,Chris,COD R
Subject: RE: [paws] WGLC for
draft-ietf-paws-problem-stmt-usecases-rqmts-03:channel reporting
I have a question here. Is it really an acknowledgement or we would
like to see a kind of notification message that includes channel, and
other parameters?
What if it's multiple channels? What happens if the device adapts and changes
between modulation technique or bandwidth? Does every change over the air need
to be indicated to the GDB?
This Channel acknowledgement does not seem useful and would limit real world
behaviors (like channel and modulation adaptation).
If viewed as a potential regulatory requirement - does this imply we need to
parameterize the protocol to have different behaviors in different regions?
Paul
Regards,
_Subir
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Siew Yoon Tan
Sent: Thursday, March 08, 2012 4:06 PM
To: Zuniga, Juan Carlos; [email protected];
[email protected]; [email protected];
[email protected]
Cc: [email protected]; [email protected]; Reza Karimi;
[email protected]; [email protected]
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-
rqmts-03:channel reporting
Dear All,
Regarding Ofcom's requirement to have a return channel as part of the
protocol between the WSD and WSDB, I would like to confirm to following
sequence of messaging
Channel request
Channel response
Channel acknowledgement
which was raised in an earlier email to this list.
Our view is that it would be beneficial to define the protocol between
WSD and WSDB that supports this requirement even though how the
information could be used is still subject to discussion in the UK.
Best regards,
Siew Yoon
________________________________________
From: [email protected] [[email protected]] on behalf of
Zuniga, Juan Carlos [[email protected]]
Sent: 08 March 2012 20:41
To: [email protected]; [email protected];
[email protected]; [email protected]
Cc: [email protected]; [email protected]; [email protected];
[email protected]
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-
rqmts-03:channel reporting
Hi Raj,
I was reusing the language used from Gerald (which I know is familiar
to people working on IEEE 802 WS groups):
[GC] You got it. This would be useless for spectrum regulators. One
should realize that, from the spectrum regulator's point of view,
the second and third messages could be iterated upon to optimize the
spectrum use.
Knowing
what channels the systems in an area are using, the spectrum
regulators and/or other entities such as those taking care of
coexistence could use the database in near-real-time to iterate on
the two last messages to reduce the range of channels that some
systems may use once they know precisely what channels are being
used in the area. The PAWS protocol would carry the information back
and forth but would not be involved in such spectrum use optimization.
Having said that, I have no issue sticking to the WSDB terminology. I
like keeping things simple :)
JC
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Thursday, March 08, 2012 3:33 PM
To: Zuniga, Juan Carlos; [email protected];
[email protected]; [email protected]
Cc: [email protected]; [email protected]; [email protected];
[email protected]
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-
rqmts-03:channel reporting
Hi JC,
Where/why did the coexistence manager come into the picture? Your
comment about "communicating back to the WSDB/coexistence manager"
may result in further misunderstanding. If we simply stick to to WSDB
I think we are okay.
-Raj
On 3/8/12 2:25 PM, "ext Zuniga, Juan Carlos"
<[email protected]> wrote:
So, from Gerald and Andy's comments, it seems like from the point of
view
of (at least) two regulatory entities it is important for the
protocol
to
allow communicating back to the WSDB/coexistence manager the actual
channel usage after the first query is made.
This is to me a very clear requirement.
The actual messages/IEs that would carry this information should be
discussed as part of the solution document, and not the requirements.
JC
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf
Of
Gerald Chouinard
Sent: Thursday, March 08, 2012 1:59 PM
To: 'Joel M. Halpern'; [email protected]
Cc: [email protected]; [email protected]; [email protected];
[email protected]
Subject: Re: [paws] WGLC for
draft-ietf-paws-problem-stmt-usecases-
rqmts-03:channel reporting
Joel, Scott,
Interesting discussion! See my comments in line below.
Gerald
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf
Of
Joel
M. Halpern
Sent: Thursday, 08 March, 2012 13:17
To: [email protected]
Cc: [email protected]; [email protected]; [email protected];
[email protected]
Subject: Re: [paws] WGLC for
draft-ietf-paws-problem-stmt-usecases-
rqmts-03:
channel reporting
So why won't the device simply say "I will use all of this?"
[GC] This would defeat the purpose of the acknowledgement message.
After all, that way it needs to do less work with the database.
And
it
can change frequencies when it wants.
Given that the stated goal of the Ofcom requriement was to be able
to
analyze interference effects, it seems that this will not actually
lead
to them getting what they want, even if it does comply with the
regulations.
[GC] You got it. This would be useless for spectrum regulators.
One should realize that, from the spectrum regulator's point of
view, the
second
and
third messages could be iterated upon to optimize the spectrum use.
Knowing
what channels the systems in an area are using, the spectrum
regulators
and/or other entities such as those taking care of coexistence
could use the database in near-real-time to iterate on the two
last messages to reduce the range of channels that some systems
may use once they know precisely what channels are being used in the area.
The PAWS protocol would carry
the
information back and forth but would not be involved in such
spectrum
use
optimization.
Yours,
joel
On 3/8/2012 1:09 PM, [email protected] wrote:
Hi Peter,
Answers below.
Kind Regards,
Scott
On 3/8/12 11:39 AM, "ext Peter Saint-Andre"<[email protected]>
wrote:
Hi Scott, I have two clarifying questions:
1. Does the device know, when it receives the channel response,
which
channel it will actually use?
Scott->This is all new and I am not aware of any existing
implementations.
I would argue that the device must decide what channel(s) it
will
use
when
it receives the channel response.
[GC] Agree with Scott but this is only a portion of the
considerations.
If a
device was to operate on its own, this would be true but a
communication device usually implies at least 2 devices to
communicate. Hence, the choice of the channel to be used will need
to be negotiated between the two devices before a choice can be
made. The chosen channel will belong to the
set
of
available channels that is common to both devices. Remember that
some
channels may be available at one device and not at the other
because
of
their geolocation or other reason. Extending this concept to a
star network topology, the channel that will be selected by this
network will
have
to
belong to the set of channels that are available to all devices.
Each
device
will not be able to decide by itself which channel it wants to use.
This is why in such a star topology, it makes sense that the slave
devices to a base station or access point be represented by the
base station acting as the master on their behalf to query the
database and receive the list of available channels (and/or
maximum EIRP per channel). It is then the responsibility of the
base station to identify the set of available channels that is
common for itself and all its slaves to decide on the
channel
that
the network will use. As you can see, in this case, there is no
need for each slave to receive its list of available channels. On
its own, it would not know what to do with it. The only thing that
needs to be sent
from
the
master device to its slaves is the resulting operating channel.
I a more sophisticated operation, the master device may add one or
a few backup channels extracted from the common set of available
channel
to
the
message going to its slave so that if a change in channel
availability
occurs, an instantaneous switch to the next backup channel can be
made
without any further signaling, thus providing for a channel switch
that
is
transparent to the user. It is the scheme that has been included
in
the
IEEE
802.22-2011 Standard. This is why I don't believe that PAWS should
get
involved in defining this signaling between the base station and
its slaves devices.
2. If the device then uses another channel or a different
channel,
does
it need to report that change to the database?
Scott->My interpretation of section 3.18 is that the device can
only
transmit within the upper& lower frequencies returned in the
acknowledgment. I do not (quickly) find any reference in the
requirements
to changing channels. Thus operationally it could be that the
channel
request process must be repeated before the device can use a
different
channel (frequencies).
[GC] If the process involves 2 messages, then, the device and its
associated devices could change channels at will as long as all
these channels belong to the set of available channel. However, if
the third message is added, it would make sense that the master
device reports to the database any channel change that would occur
to the database, otherwise, the status of
the
spectrum occupation would be wrong at any moment and would be
useless
for
the purpose of any spectrum usage optimization such as coexistence.
Thanks!
Peter
On 3/8/12 10:17 AM, [email protected] wrote:
Hi,
The point from Brian is very relevant:
Channel request
Channel response
Channel acknowledgement
What Ofcom does with the information in the acknowledgement
does
not
matter. As the regulator in UK, they write rules that must be
followed
in
order to operate a whitespace radio in the UK. I believe the
scope
of
the
WG must be focused on a working solution. If this is simple
channel
request& response in one regulator's domain, PAWS can support
this. If
it
means a channel request, response and acknowledgement in
another regulator's domain, PAWS can support this. As a
participating
member of
the work group, I believe the scope should be basic working
solution,
not
limited to a specific number of messages.
Kind Regards,
Scott
On 3/8/12 11:11 AM, "ext Zuniga, Juan Carlos"
<[email protected]> wrote:
Peter, Nancy,
I agree should design a protocol with the best of our current
knowledge, and that should be accounting for all the known
regulations at
present
time. We should not limit the scope with the purpose of
designing
a
protocol 'faster'. Our goal is not only to design a WSDB
protocol.
Our
goal is to design a WSDB protocol that is USEFUL to the
community.
The charter does state that
"...the group should also reach out to other potential
"customers" for a white space database access method and
consider
input
>from regulatory entities that are involved in the
specification
of
the
rules for secondary use of spectrum in specific radio bands. "
I think that is exactly what we are doing now.
Regarding whether the types of requirements belong to #1 or
#2,
I
believe
it is more of #1 type, as the information to be exchanged
would
be
known
after the initial query/response.
If we know it today, I see no reason why we should not work
on
it
in
the
first phase of the work.
Regards,
Juan Carlos
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On
Behalf
Of
Peter Saint-Andre
Sent: Thursday, March 08, 2012 11:59 AM
To: Nancy Bravin
Cc: [email protected]; [email protected];
[email protected];
Pete
Resnick
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-
usecases-
rqmts-03: channel reporting
Hi Nancy,
You are absolutely right that different locales will have
different
rules and requirements. We need to understand those, and
work
to
address
them if possible (although we don't necessarily need to
address
them
all
at the same time). I see several kinds of requirements:
1. Some requirements might lead to features beyond the
query/response
protocol we've envisioned so far. One example might be real-
time
reporting about the channels that a device is actually using.
In
my
opinion, it would be best to handle those in the next phase
of
work,
because as far as I can see they are outside the scope of
our
charter.
2. Some requirements might be handled through by defining
additional
fields that can be included in the query or response. We
definitely
planned for that when working on the charter with the IESG:
In addition, the particular
data exchanged between a device and a database might
depend
on
the
ranges of radio spectrum that are to be used, the
requirements
of
the
database operators and their governing regulations, and
other
factors.
Therefore, the database access method and the
query/response
data
formats that are exchanged using that method need to be
designed
for
extensibility rather than being tied to any specific
spectrum,
country, or phy/mac/air interface.
It's unclear to me right now if the Ofcom requirement fits
into
#1 or
#2, which is why we're having this discussion. :)
Peter
On 3/7/12 8:17 PM, Nancy Bravin wrote:
Peter and all,
I agree that it is important to revisit now, so that in the
future,
it will be easy to align things in their proper place.
Every
country
may have different regulations, spectrum, policy and what
responsibility is in the domain of the system, and what
comes
under
the PAWS charter is important. Maybe some separation might
be
possible, and dividing and clarifying issues now will help
in
the
future. Certainly it seems that the FCC may change some
rules,
and
we know that Ofcom is not yet finished with their
regulations.
Canada
has their own, and other countries are working on this as
well.
Just
a thought...Sharing is a realistic goal...as is off
loading...
Or you
slim line and every 6 months decide what to incorporate in
the
protocol based on new information, new ideas, new
innovation
new
regulations and maybe spend more time than you could if
addressed
now.
That way you leave the door open and outside of referencing
what
is
known today, by referencing regulations i.e. Ofcom, FCC,
Industry
Canada etc as of XX-XX-XXXX date. Out of scope not
something
we
know
enough about to say at this point, In my opinion.
My 2 cents..
Sincerely, Nancy
On Mar 7, 2012, at 4:41 PM, Peter Saint-Andre wrote:
<hat type='AD'/>
As your responsible Area Director (until March 28, when
Pete Resnick will take over from me), I have reviewed this
thread.
In my opinion (I am happy to be proven wrong), this new
requirement
goes beyond what the charter defined as the scope of this
working
group, which was to enable a device to discover the white
space
available to it in its current location. Reporting usage
back
to
the database is simply not mentioned in the charter.
Earlier in this thread, Andy Sago wrote:
There's no language I can find in the charter that
explicitly
puts
this out of scope.
An IETF charter defines what the working group shall work
on.
Many
interesting features could be developed here. However, it
is
not
the job of the charter to mention explicitly that each of
those
interesting features is out of scope.
The charter does say:
Once the device learns of the available white space (e.g.,
in a
TV
white space implementation, the list of available channels
at
that
location), it can then select one of the bands from the
list
and
begin to transmit and receive on the selected band.
This text might have assumed that no further communication
or
authorization was required in order to select one of the
bands
from
the list and then transmit/receive. Perhaps that
assumption
was
mistaken. If so, it would be good to have a discussion
about
that,
so we can determine if we need to revisit the assumptions
we
made
early on. If in fact we made some faulty or limited
assumptions,
then let's get that out in the open.
Peter
On 3/7/12 9:40 AM, Rosen, Brian wrote:
<as individual, at least for now> I'd also suggest that
our
charter limitation is really support for sharing of
whitespace
by
whitespace devices. Reporting what you use is not
sharing,
it's
just data gathering.
The point of excluding sharing was to eliminate the
complexities
of what constituted fairness, and what kinds of
communication
might be needed between databases, where more than one
could
supply available whitespace in a band. This doesn't have
any
of
those issues, As long as it's just sending information, I
don't
have a problem. Once the database is supposed to do
anything
with it that involves changing what spectrum it reports,
then
I
think we cross the line.
Brian
On Mar 6, 2012, at 12:28 PM,<[email protected]>
<[email protected]> wrote:
Joel
Indeed, the regulator has not described the process or
provided
a flow diagram, so there may be some wrinkles, but we
need
to
provide for their intent. To answer your question, the
channels
that the master will use are sent in a separate message
(described in P.12 ter), that occurs after the master
receives
the response to its channel request, but before the
master
can
transmit. At this point, it knows what channels are
available,
and which one it will use. As far as the slaves are
concerned,
as they associate, the master will need to gather their
details
and send further channel usage messages to the database
on their behalf.
Regards
Andy
-----Original Message----- From: [email protected]
[mailto:[email protected]] On Behalf Of Joel M.
Halpern
Sent: 06 March 2012 17:05 To: [email protected]
Cc:
[email protected]; Cheeseman,CJ,Chris,COD R;
Dixon,JS,Johnny,COD
R
Subject: Re: [paws] WGLC for
draft-ietf-paws-problem-stmt-usecases-rqmts-03: channel
reporting
Ahh. I think I see where the request and my
understanding divurge. If the idea here is that the
master must provide,
in
the request, an indication of what channels it expects
to
use,
I can at least understand that. I will return to
technical
concerns in a moment.
However, when you say "provide channel usage
information,
in
order to evaluate interference", what that says to me is
providing, during operation, information as to what
channels
are being used, and at what power levels. That is what
would
be needed to analyze actual interference effects. And
that
is
out of scope as I understand our scope.
I do see a technical difficulty with having the master
provide,
as part of either registering or requesting spectrum
information, what channels it intends to use. It
doesn;t
know
what channels it intends to use. It intends to use some
number
of available channels. It will figure out which ones
when
it
is told what is available. How can it send that
information
in
the request?
Yours, Joel
On 3/6/2012 11:48 AM, [email protected] wrote:
Hi,
There is a similarity here with device ID. In context
of
PAWS
we are not concerned with why a device ID is required
by
a
regulator, we accept it is a requirement from a
regulator
and
include it to the protocol. Ofcom identifies in 3.18&
3.19
that channel usage information is required and thus we
need
to include this information. Since the master must
provide
this information prior to transmitting, PAWS will not
function in the UK without this information and thus I
believe channel usage information is integral to the
channel
request& response messaging.
Kind Regards, Scott
On 3/6/12 10:30 AM, "ext Joel M.
Halpern"<[email protected]> wrote:
I would draw a distinction. Ofcom regulations about
whitespace requests are very much relevant. Ofcom
regulations about notification of dynamic behavior
(which
spectrum is being used) are not in scope as I
understand the earlier discussions, particularly the
chartering discussions.
Yours, Joel
On 3/6/2012 11:22 AM, [email protected] wrote:
The ofcom requirements are very much relevant to the
scope of the PAWS WG. The only other regulatory
requirements that we have today is the FCC. Ofcom
requirements are a good addition to the set.
-Raj
On 3/6/12 10:03 AM, "ext
[email protected]"<[email protected]> wrote:
Hi Joel
There's no language I can find in the charter that
explicitly puts this out of scope. On the other
hand, the charter says that the group will "consider
input from regulatory entities", and this is one of
the requirements from Ofcom that they have just
published.
The protocol will be worthless for the UK if it
omits some requirements.
Regards
Andy
-----Original Message----- From: Joel M. Halpern
[mailto:[email protected]] Sent: 06 March 2012
15:53
To: Sago,AJ,Andy,COD R Cc: [email protected];
[email protected] Subject: Re: [paws] WGLC for
draft-ietf-paws-problem-stmt-usecases-rqmts-03:
channel
reporting
As I understand, the information you are asking for
is explicitly out of scope for the working group.
Yours, Joel
On 3/6/2012 10:42 AM, [email protected] wrote:
All
Comparing the draft with the Ofcom requirements at
http://www.cept.org/Documents/se-
43/4161/SE43(12)Info03_Draft-UK-r
egul
atory-requirements-for-white-space-devices-in-the-
UHF-
TV-
band,
I believe the WG draft is deficient in the area of reporting
frequencies and powers actually used by masters and
slaves (Ofcom requirements 3.18 and 3.19.8). Ofcom
intends to collect this data to assesses the impact
of aggregate interference into other services. It
would also provide usage information (frequency in
use) that would inform the operation of a kill
switch capability. I suggest this deficiency can be
remedied with the following changes:
New P requirements (probably best placed following
P.12):
P.12bis: The protocol MUST support a channel usage
message from the slave device to the master device.
The channel usage message MUST include parameters
as required by local regulatory requirement. These
parameters MAY include device ID, manufacturer's
serial number, channel usage and power level
information.
P.12ter: The protocol MUST support a channel usage
message from the master device to the database.
The channel usage message MUST include parameters
as required by local regulatory requirement for the
master and its associated slaves. These parameters
MAY include device ID, manufacturer's serial
number, channel usage and power level information.
P.12qua: The protocol MUST support a channel usage
message acknowledgement.
New O requirements (probably best placed following
O13):
O.13bis: According to local regulatory policy,
after connecting to a master device's radio network
a slave device MAY inform the master device of the
actual channel usage. The slave MUST include
parameters required by local regulatory policy, e.g.
device ID, manufacturer's serial number, channel
usage and power level information.
O.13ter: According to local regulatory policy, a
master device MAY inform the database of the actual
channel usage of the master and its slaves. The
master MUST include parameters required by local
regulatory policy, e.g. device ID, manufacturer's
serial number, channel usage and power level
information of the master and its slaves.
New steps could be introduced into one or more use
cases to cover these Ofcom requirements, e.g. new
steps 6bis and 9bis in the hotspot use case at
4.2.1:
6bis. Prior to initiating transmission, if required
by local regulation, the master/AP informs the
database of the channel and power level it has
chosen. This is repeated for each slave that
associated with the master.
9bis. Prior to initiating transmission, if required
by local regulation, the slave informs the
master/AP of the channel and power level it has
chosen, and the master/AP relays this information
to the
database.
- end of new text -
For information, for those not accessing the url in
the first paragraph of this email, the full Ofcom
requirements leading to this new PAWS text are as
follows:
3.18 After receiving instructions from a WSDB in
relation to the maximum permitted EIRPs over the
DTT channels, and prior to initiating transmissions
within the UHF TV band, a master WSD must
communicate to the WSDB the following information:
3.18.1 The lower and upper frequency boundaries^13
of the in-block emissions of the master WSD, and
those of the in-block emissions of its associated
slaves. A lower frequency will be specified as (470
+ 8k +
0.2n) MHz, with the corresponding upper frequency
specified as (470 + 8k + 0.2m) MHz, where 0 3?4 k
3?4
39, 0 3?4 n 3?4 39, 1 3?4 m 3?4 40, and n< m.
3.18.2 The maximum in-block EIRP spectral densities
(in dBm/(0.2 MHz)) that the master WSD, and its
associated slaves, actually radiate between each
reported lower frequency boundary and its
corresponding upper frequency boundary.
Footnote 13 states:
The use of upper and lower frequency boundaries
(defined over a 200 kHz raster) allows a WSDB to
collect more granular information with regards to
the usage of the frequency resource by narrowband
WSD technologies. The upper and lower frequencies
of a boundary pair do not straddle a DTT channel
boundary.
Note that a WSD may transmit over multiple,
non-contiguous, whole DTT channels or fractions of
DTT channels.
3.19 A master WSD must be able to receive the
following information^14 from a WSDB:
<snip>
3.19.8 [An acknowledgement from the WSDB, in the
context of 3.18, that the reported information on
the DTT channels and EIRP spectral densities
actually used by the master and slave WSDs were
received successfully by the WSDB^18 ].
Footnote 14 states:
14 While the communication of some of this
information from a WSDB to a master WSD is
optional, master WSDs must be able to receive and
interpret these.
Footnote 18 states:
18 This forms part of a handshake protocol and may
be an area where industry could harmonise without
the need for an explicit requirement in the
regulations.
Regards
Andy
*From:*[email protected]
[mailto:[email protected]] *On Behalf Of
*[email protected] *Sent:* 05 March 2012 19:46
*To:* [email protected] *Subject:* [paws] WGLC for
draft-ietf-paws-problem-stmt-usecases-rqmts-03
The authors of the use cases and requirements draft
have just posted a new version of the draft and
indicated that there are no unresolved
comments/issues they are aware of.
Therefore, I'd like to initiate a WG Last Call for
comments on
http://www.ietf.org/internet-drafts/draft-ietf-paws
-
problem-
stmt-u
seca
ses-rqmts-03.txt
Please review the draft and send your comments to
the list by March 20th, 2012.
If you review the draft and have no comments, send
a note to the list that the draft is good as it is,
we need these notes as much as we need the actual
comments.
Thanks, Gabor
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
________________________________
***********************************************************************
*
******************************************
For more information visit www.ofcom.org.uk
This email (and any attachments) is confidential and intended for the
use of the addressee only.
If you have received this email in error please notify the originator
of the message and delete it from your system.
This email has been scanned for viruses. However, you open any
attachments at your own risk.
Any views expressed in this message are those of the individual sender
and do not represent the views or opinions of Ofcom unless expressly
stated otherwise.
***********************************************************************
*
******************************************
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
