Subject: RE: [Sipping] Deadline extended: WGLC:draft-ietf-sipping-config-framework-12.txt

From: "Elwell, John" <[email-masked]>
Date: Tue, 03 Jul 2007 09:14:54 +0100

Well, I'm not sure I committed to do a full review, but I said I would
look at it. Having spent a few hours trying to get to grips with it, I
am afraid I have only been able to put together a few random comments
and thoughts, which do not constitute a full review.

1. General
I have in the past raised a concern about this document's complexity. I
am not sure how much this is due just to the way the document is written
(64 pages seems an awful lot to have to read and understand in order to
implement this) and how much is due to unnecessary technical complexity.
Certainly some of the complexity comes from having 3 profiles that
potentially are obtained from different sources. In the enterprise
environment, which concerns me mostly, I don't see this being a likely
situation. Also, is an authority responsible for the network and/or the
device but not VoIP likely to support a SIP event package as a means of
making policy available?

Furthermore, before enrolment can take place for any of the profiles,
the device already has to be configured with certain SIP information,
e.g., the address of the outbound proxy, a CA certificate for verifying
the identity of the proxy during TLS handshake. I think there is a
requirement for a non-SIP means of bootstrapping the configuration. SIP
undoubtedly has a role later on for providing notifications of changes,
but I sense that too much pre-configuration is needed (or perhaps that
is just my perception, since the whole draft is too complex for me to
take in the complete picture).

I believe another Internet Draft will appear shortly, proposing a much
simpler solution, and I would like to hear what the community thinks
about that.

However, putting those thoughts aside, I still think this draft needs
more work.

2. Basically I don't find it an easy document to read. Some examples (in
no particular order):
- "6.  Profile Delivery Framework
   This section presents the profile delivery framework, the subject of
   this document."
I get quite a number of pages into the document before I get to this
statement. I would expect the subject of the document to be presented
right up front.

- "The section starts by explaining the framework via
   the profile delivery stages.  It then explains how the framework
   secures the profile data propagation.  It ends with considerations
   such as back-off and retry mechanisms and profile data."
However, mixed into this section 6 are a lot of normative statements. I
don't think we should be mixing explanation and normative statements
like this.

- Section 6.1 explains about the three profile delivery stages, yet that
is already explained to some extent in section 4.3.

- Section 5 gives some use cases, yet these same two use cases are
described (but in less detail) in section 4.1. Furthermore there are
extended examples in section 8.

- In section 1 there is the statement "This framework
   also addresses change notifications when profiles change"
This is the first mention of profile - I would expect to be told what a
profile is before being told about profile changes. Expecting the reader
to look ahead to section 2 is not very satisfactory.

- Section 3 has the title "Executive Summary". While this new section
does provide a concise overview of the solution, I don't think we
normally use the title "Executive Summary" for such things.

- Section 4.2 has the title "Data Model and Profile Types", yet the
contents of the section talk only about profile types.

- There are two terms Profile Delivery Server and Profile Delivery
Stages (both capitalised). Although the acronym PDS is used only for the
former, it is rather confusing.

- "Profile enrolment is initiated when the device transmits an
      enrolment request using a SIP SUBSCRIBE request [RFC3265] for the
      event package specified in Section 7.2."
and much later in the same section:
  "To enroll, the device needs to request enrollment.  This is done via
   a SIP SUBSCRIBE message."
We should try to keep everything to do with device behaviour on
enrollment together and avoid repetition.

I would like to see a clear separation into:
- Introduction
- Motivation
- Overview of solution
- Normative part
- Examples
with avoidance of repetition.

Furthermore, the normative part should be sub-structured to make it
clear what are the requirements for devices, what are the requirements
for PDSs, and what (if any) are the requirements for proxies.

3. Other comments
- "If a SIP infrastructure
      element receives the request, it will relay it to the
      authoritative proxy for the domain indicated in the Request-URI.
      The authoritative proxy is required to examine the request (e.g.,
      event package) and transmit it to a PDS capable of addressing the
      profile enrollment request."
This seems to be imposing special requirements on proxies - this seems
undesirable.

- "The device MUST set the host and port of the Request URI to the
      concatenation of "_sipuaconfig" and the local network
domain/port."
This is not backed up by the examples. For example, the example in
section 8.1 has the following Request-URI:
"sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB
             @example.com"

- "the profile provider's domain name, identities and
      credentials.  Such data can be "configured" during device
      manufacturing, by the user prior to network connectivity, or via
      profile data retrieval."
This last (profile data retrieval) seems to suggest some sort of
recursion. I think we need more explanation. For example, can a given
profile provide data that causes a further version of that same profile
to be retrieved? Or does one profile provide data on where to retrieve a
different profile? What exactly are the requirements on a device in
order to support this?

- "The From field is populated with the user AoR, if available.  This
   allows the local network provider to propagate user-specific profile
   data, if available.  The "+sip.instance" parameter is set to the
   device identifier or specifically, the SIP UA instance.  Even though
   every device may get the same (or similar) local-network Profile, the
   uniqueness of the "+sip.instance" parameter provides an important
   capability.  Having unique From fields allows the management of the
   local network to track devices present in the network and
   consequently also manage resources such as bandwidth allocation."
I was not aware that a From header field could contain such a parameter.
Also this is not reflected in the example in section 8.1.

- Section 6.1.4.2. This represents a very complex procedure for forming
a SUBSCRIBE request for the device profile. I had great difficulty
understanding it. In particular, I don't understand the concept of
"device AoR". Is there one value for a class of devices, and all devices
of that class send the SUBSCRIBE request to that AoR? Or does each
individual device have a different value of device AoR?

- Then it goes on to say "If the device does not have a configured or
   cached Subscription URI, then it can use the device AoR."
But earlier it said that the device AoR is configured, so something is
wrong.

- And then: "When the device needs to present its device identifier it
MUST use
   the UUID-based URN representation for the user portion of the
   Request-URI, as specified in [RFC4122]."
But this seems to be in conflict with the use of a device AoR, if
available.

- Sections 6.2.1 and 6.2.2 talk about TLS on the first hope. Section
6.2.2 states requirements for the PDS to have an X.509 certificate.
However, this is of no relevance when going via a proxy.

- Also in 6.2.2: "PDSs that are configured with X.509 certificates (as
described
   above) SHOULD implement SIP Identity as specified in [RFC4474].  When
   the SIP Identify header is included, the PDS MUST set the host
   portion of the AoR in the 'From' header to the local network domain."
According to my understanding, the PDS acts as the UAS for the SUBSCRIBE
request, so its only involvement in RFC 4474 would be as a verifier. The
statement above does not make sense. Or are we talking about NOTIFY
requests here? If so, are we using the capabilities of RFC 4916 to allow
modification of a From header field URI within a dialog?

- "A PDS that does not support TLS MUST use content indirection to
      a PCC that supports authentication and integrity protection for
      conveying sensitive profile data".
Even if the PDS supports TLS and TLS is indeed used on the last hop to
the PDS, there is no guarantee that it is used on all hops. So should
there be a requirement for content indirection in such cases?

- "If the device established next-hop authentication TLS then any such
   notifications SHOULD be sent over the same TLS session.  If the TLS
   session exists, the device MUST ignore any notifications sent outside
   the TLS session."
Isn't this in conflict with sip-outbound, which allows different TLS
connections to be used (different flows) or which allows a TLS
connection to be rebuilt if the connectivity check fails?

4. NITS
- In sub-section 6.1 it states "Devices
   and PDSs MUST comply with the requirements as specified in this
   section."
Does this mean sub-section 6.1 or section 6?

- "for the
      event package specified in Section 7.2."
The event package is specified in 7, not just 7.2.

John

> -----Original Message-----
> From: Mary Barnes [mailto:[email-masked]] 
> Sent: 29 June 2007 13:50
> To: [email-masked]
> Subject: [Sipping] Deadline extended: 
> WGLC:draft-ietf-sipping-config-framework-12.txt
> 
> Hi all,
> 
> We are extending the deadline for this WGLC to 9 July as 
> there has been
> no feedback. The good news is that we do have two people that have
> committed to reviewing the document, they were just unable to meet the
> deadline due to other commitments. Thanks in advance to John 
> Elwell and
> Shida Schubert.  
> 
> For folks that just don't feel they have time to do a comprehensive
> review, a short "I read the document and I think it's ready 
> (or not)" is
> valid and important input. Although, if you're input is "not 
> ready", it
> really is imperative that we get some constructive feedback as to why
> the "not".  
> 
> Thanks,
> Mary
> 
> 
> -----Original Message-----
> From: Barnes, Mary (RICH2:AR00) 
> Sent: Monday, June 04, 2007 4:02 PM
> To: [email-masked]'
> Cc: 'Sumanth Channabasappa'
> Subject: WGLC: draft-ietf-sipping-config-framework-12.txt
> 
> 
> Hi all,
> 
> This is to announce Working Group Last Call on the following document:
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-
> framework-
> 12.txt
> 
> This WGLC will end on 25 June 2007.
> 
> As folks know, this document has been reviewed in the past (and WGLCed
> in the past) but there was a major rewrite for the -10 
> version and it's
> been well over a year since the original detailed reviews.  Thus, we
> would like 3 volunteers to commit to reviewing the document in detail
> (past reviewers should certainly feel free to re-volunteer).  If
> interested, please let the chairs know.  
> 
> Official reviewers and anyone else that gets a chance to review should
> send
> their feedback to the author (in the cc of this email) and copy the
> SIPPING mailing list (or if it's easier, just do a "Reply to all" to
> this email).  
> 
> Thanks, 
> Mary 
> SIPPING WG co-chair
> 
> 
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Wed, 4 Jul 2007 13:16:31 -0600

John,

Thanks for your comments. Please find enclosed a few responses inline.

In general:
-  The document contains requirements, use cases, framework details,
security requirements and examples which does make it lengthy out of
necessity (based on earlier WG comments). The design team also added
enough information (most of which was requested by WG participants) to
make it clear to implement. The introductory sections are mostly for a
better understanding of what the framework tried to provide, and why. 

To make it easier to navigate, we were asked to, and added the
'Executive Summary' (as agreed upon by at the last IETF, even if it is
not standard nomenclature). Given the nature of the various sections,
there is some repetition to let the reader understand the concepts if
they don't read every section.

- Examples are not comprehensive. They do not cover all the possible
cases. For example, the use of "_sipuaconfig" for the local network
profile and a special case of device profile is indicated in section 6.
However, the examples which cover the device profile type do not
highlight this special case and hence you will not see it (they indicate
the use of the device identifier). 

Certainly some of the complexity comes from having 3 profiles that
potentially are obtained from different sources. In the enterprise
environment, which concerns me mostly, I don't see this being a likely
situation. Also, is an authority responsible for the network and/or the
device but not VoIP likely to support a SIP event package as a means of
making policy available?
[S] Firstly, the I-D presents a framework to cater to various
deployments and not a specific deployment. Now, we have discussed the
different profile types at various points in time and the general
consensus (from the design team; and at the presentation during the last
IETF) was that we needed the separation to be able to cater to various
deployment scenarios. I do agree (personally) that there may be
scenarios where the different profile types may not be required, but
that is left to implementation (the configuration of the device, using
the framework or otherwise, can indicate the required profile types).
Similarly, there are deployments which may require additional profile
types, such as the 'application' profile type (examples include
PacketCable and OMA). 

Furthermore, before enrolment can take place for any of the profiles,
the device already has to be configured with certain SIP information,
e.g., the address of the outbound proxy, a CA certificate for verifying
the identity of the proxy during TLS handshake. I think there is a
requirement for a non-SIP means of bootstrapping the configuration. SIP
undoubtedly has a role later on for providing notifications of changes,
but I sense that too much pre-configuration is needed (or perhaps that
is just my perception, since the whole draft is too complex for me to
take in the complete picture).
[S] I idea of the I-D is to allow for a client that is not
pre-configured to be able to request and obtain configuration. Security
requirements are provided, when and where applicable. Refer to section
6.2.3 for an explanation on how the identities and credentials are
obtained. 

- Section 5 gives some use cases, yet these same two use cases are
described (but in less detail) in section 4.1. Furthermore there are
extended examples in section 8.
[S] This was intentional, based on earlier comments (around -09) to
introduce the problem space, use cases, the solution and then detailed
usage examples.

3. Other comments
- "If a SIP infrastructure
      element receives the request, it will relay it to the
      authoritative proxy for the domain indicated in the Request-URI.
      The authoritative proxy is required to examine the request (e.g.,
      event package) and transmit it to a PDS capable of addressing the
      profile enrollment request."
This seems to be imposing special requirements on proxies - this seems
undesirable.
[S] I am not sure if we are stating anything outside of SIP here
(correct me if I am mistaken). Isn't this normal SIP behavior (we can
clarify it to be less of a requirement, and more of an informative
explanation).

[S] See Section 6.2.3.

- "The From field is populated with the user AoR, if available.  This
   allows the local network provider to propagate user-specific profile
   data, if available.  The "+sip.instance" parameter is set to the
   device identifier or specifically, the SIP UA instance.  Even though
   every device may get the same (or similar) local-network Profile, the
   uniqueness of the "+sip.instance" parameter provides an important
   capability.  Having unique From fields allows the management of the
   local network to track devices present in the network and
   consequently also manage resources such as bandwidth allocation."
I was not aware that a From header field could contain such a parameter.
Also this is not reflected in the example in section 8.1.
[S] Actually, the '+sip.instance' parameter is in the 'Contact' Header
(as reflected in the example. It is specified in
[I-D.ietf-sip-outbound]. We previously had a place holder within the
'From' header and we did not clear (or clean) this up!

[S] I believe 6.1.4.2 explains what a device AoR is. 

- Then it goes on to say "If the device does not have a configured or
   cached Subscription URI, then it can use the device AoR."
But earlier it said that the device AoR is configured, so something is
wrong.
[S] Well, the statement reads:
" To request the device profile, the device needs a unique device
identifier, the device provider's domain name and optionally a device
AoR (if configured)"

So, it does not say that it is always configured, but optionally allows
for it to be configured (and used, when required).

The concepts of cached, configured and discovered information is
explained in 6.1.1.

- And then: "When the device needs to present its device identifier it
MUST use
   the UUID-based URN representation for the user portion of the
   Request-URI, as specified in [RFC4122]."
But this seems to be in conflict with the use of a device AoR, if
available.
[S] Again, 'When the device needs to present' refers to when the option
applies (i.e., it does not have a configured 'device AoR').

- Sections 6.2.1 and 6.2.2 talk about TLS on the first hope. Section
6.2.2 states requirements for the PDS to have an X.509 certificate.
However, this is of no relevance when going via a proxy.
[S] Well, the idea is to be able to authenticate the next-hop proxy,
when say SIPS is used. And the requirement on the PDS is a strong
recommendation (SHOULD) since a PDS can cater to clients that connect
directly or via a proxy.

[S] NOTIFY requests. If you check 6.2.4 (which specifies usage), it
says:
"   the PDS SHOULD provide the notifications and include the SIP
   Identity header."

- "A PDS that does not support TLS MUST use content indirection to
      a PCC that supports authentication and integrity protection for
      conveying sensitive profile data".
Even if the PDS supports TLS and TLS is indeed used on the last hop to
the PDS, there is no guarantee that it is used on all hops. So should
there be a requirement for content indirection in such cases?
[S] The PCC, as you may recall is where the device obtains its data
from, such as a HTTP/S server (the only one specified in the I-D, while
allowing for other protocols). So the SIP proxies do not come into play.
(And if someone uses a protocol that has similar constraints, they would
need to specify the security requirements.)

- "If the device established next-hop authentication TLS then any such
   notifications SHOULD be sent over the same TLS session.  If the TLS
   session exists, the device MUST ignore any notifications sent outside
   the TLS session."
Isn't this in conflict with sip-outbound, which allows different TLS
connections to be used (different flows) or which allows a TLS
connection to be rebuilt if the connectivity check fails?
[S] I would defer this to the OUTBOUND experts. I believe this
requirement has been in the I-D for quite a while now. 

4. NITS
- In sub-section 6.1 it states "Devices
   and PDSs MUST comply with the requirements as specified in this
   section."
Does this mean sub-section 6.1 or section 6?
[S] Section 6. Will correct

- "for the
      event package specified in Section 7.2."
The event package is specified in 7, not just 7.2.
[S] Agreed. Will be corrected.

There are a couple of other good observations (such as the 4.2 having
data model in the title, when it should not). Thanks

- S

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 05 Jul 2007 08:05:30 +0100

Sumanth,

Thanks for considering my comments. See below.

John 

> From: Sumanth Channabasappa [mailto:[email-masked]] 
> Sent: 04 July 2007 20:17
> To: Elwell, John; Mary Barnes; [email-masked]
> Subject: RE: [Sipping] Deadline extended: 
[JRE] My concern is the complexity imposed on implementation at the UA
in order to support this. On the one hand, of course we want a single
implementation of UA to be able to be used in multiple environments. On
the other hand, it seems that to achieve this the implementation is
going to be quite complex - look at 6.1.4 and 6.2 for example. Perhaps
part of the problem is a documentation issue: as a UA implementer, I
cannot find all the requirements in one place. For example, in order to
submit a SUBSCRIBE request I need to look for normative statements in
6.1.1, 6.1.4 and its subsections, 6.1.5 (but shouldn't this be a
subsection of 6.1.4?), 6.2.2, 6.2.4 and its subsection, 6.3.1, plus of
course relevant aspects of the event package definition in section 7.
This makes it seem a lot, even if some simplifications can be made in
practice.

> clarify it to be less of a requirement, and more of an informative
[JRE] A pure proxy according to RFC 3261 would not even need to
understand a SUBSCRIBE request, let alone specific event packages. A
SUBSCRIBE request is just another non-INVITE request.

> [S] I believe 6.1.4.2 explains what a device AoR is. 
[JRE] That is where I was looking, yet it isn't clear to me. How many
devices would share the same "device AoR" - all devices of a given
class, all devices supporting a given user, all devices of a specific
class supporting a specific user, only one device?

> The concepts of cached, configured and discovered information is
[JRE] OK, but this was hard to understand.

> "   the PDS SHOULD provide the notifications and include the SIP
[JRE] Another example of information scattered in different places.

> need to specify the security requirements.)
[JRE] I think you misunderstood my question. I am talking about SIP
signalling to the PDS. If that is not secured on all hops, shouldn't
content indirection be used?

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 8 Jul 2007 16:12:32 +0300

Hi,
I have read this draft. I think it is ready for publication.

Still I am wondering if it make sense to take out the event package
specification to a separate draft but I do not think it is crucial.

There are some nits

1. In 5.2 just before section 6 "retrieves" to "retrieves"

2. In  6.1.4.1 second bullet "explicity" to "explicitly"
Same typo  in 6.2.4.1

3. In section 6.1.4.2 (configured or discoverd) to (configured or
discovered)

4. In section 6.3.1 "the device must enrol in the order" to  "the device
must enroll in the following order"

Roni Even

> Sent: Friday, June 29, 2007 3:50 PM
> To: [email-masked]
> Subject: [Sipping] Deadline extended: WGLC:draft-ietf-sipping-config-
> framework-12.txt
> 
> Hi all,
> 
> We are extending the deadline for this WGLC to 9 July as there has
been
> deadline due to other commitments. Thanks in advance to John Elwell
and
> review, a short "I read the document and I think it's ready (or not)"
is
> valid and important input. Although, if you're input is "not ready",
it
> This is to announce Working Group Last Call on the following document:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-
> in the past) but there was a major rewrite for the -10 version and
it's

---

From: David Robbins <[email-masked]>
Date: Sun, 08 Jul 2007 23:42:30 -0400

Speaking from some implementation experience with the framework (as  
it was defined about two years ago), although speaking up very late  
in the game (severe time constraints prevented me from participating  
in this discussion before now), I have some comments and suggestions  
on the -12 draft.

The complexity of this is more or less unavoidable, given the variety  
of deployment scenarios that the framework is intended to address,  
and credit is due to the contributors who have worked this almost to  
death over the years. And I generally like how this has evolved since  
we took our snapshot two years ago. Nevertheless, as other commenters  
have noted, there still seem to be some rough spots.

To begin with, I tend to concur with many of John Elwell's comments,  
particular as they relate to the difficulty in reading and  
understanding the draft. In fairness, this is due in part to the  
inherent complexity of the framework in its need to cater to several  
widely disparate deployment scenarios. It is a real challenge to  
describe the framework in terms that are easy to understand and at  
the same time sufficiently precise to specify clear and unambiguous  
requirements. While the meaning and technical content of the draft is  
fairly clear to me, I can see some room for improvement.

At the cost of making the draft larger, a few more use cases might be  
helpful in justifying the complexity. (I'm not totally sure about  
this, and have none to suggest at the moment.)

The state diagram on page 30 fails to recognize the possibility that  
the NOTIFY may arrive before the 2XX, that the NOTIFY may arrive but  
the 2XX may never be received, or that the NOTIFY may signal the  
termination of the subscription (in which case it says nothing about  
the corresponding profile document).

There are various race conditions involving the 2XX and NOTIFY  
responses to a SUBSCRIBE and retransmissions of the SUBSCRIBE, but  
they are generally resolved simply by carefully following the  
procedures specified by RFC 3261, RFC 3263, and RFC 3265.

Regarding the discussion of timeouts on page 31, IIRC HTTP and HTTPS  
do not specify timeouts, leaving it up to the client to decide when  
to declare a request timeout. The draft should explicitly require the  
UA to set a timeout on an HTTP/HTTPS request; the timeout should  
probably be in the range of 30-60 seconds. Also, RFC 3265 does not  
address the situation where a SUBSCRIBE elicits a 2XX response but  
not the mandatory NOTIFY. The draft should require the UA to set a  
NOTIFY timeout upon sending the SUBSCRIBE; a value perhaps somewhat  
larger than 64*T1 would be appropriate.

I found the pseudocode on page 32 somewhat hard to read, as it is a  
format I've never seen before. Not wholly unreadable, though. One nit  
-- the use of "Abort this function" to mean "success" is jarring,  
because "abort" generally connotes failure.

I agree with the principle of exponential backoff, but I'm  
uncomfortable with starting at 64*T1 and limiting to eight retries.  
In at least some circumstances, you want the client to autonomously  
continue retrying indefinitely, you may want to start at something  
more like one minute, and you may want to cap it at something like 30  
minutes or an hour.

I would also recommend that a retry be directed to an alternate  
server only if no response at all was received from one server. One  
can generally assume that if one server out of a set of servers  
returned for a given domain name returns an error response, all other  
servers will return the same error response, since they are all peers  
and should be interchangeable. A response shows that the server is  
alive, but doesn't like the request, whereas a timeout means that the  
server may be dead or severely overloaded, in which case an alternate  
server is likely to respond successfully.

On page 40, I'm puzzled by the notion that the notifier may be  
"unsure" whether the NOTIFY is expected to contain profile contents.  
Since the notifier by definition is responsible for sending the  
NOTIFY, it presumably knows what it will be sending. At least I'd  
like to think this is more or less deterministic. :-)

To protect the notifier against attacks and to prevent disclosure of  
even seemingly innocuous information to an attacker, the notifier  
should always authenticate the SUBSCRIBE, regardless of what will be  
sent in the NOTIFY, except in the case noted, where the notifier is  
explicitly configured to accept requests from subscribers that do not  
possess credentials. In most cases that I can imagine, you want to  
accept subscriptions only from credentialed subscribers. For  
protection of profile content, you generally want to deliver it via  
content indirection and HTTPS, so that the requestor must  
authenticate the actual retrieval request and so that you have  
integrity protection over the content. You could use direct content  
if your NOTIFY is sent over a known secure channel (i.e. TLS or IPsec  
all the way between UA and PDS).

Although this draft defers for future consideration a mechanism by  
which the UA can complain to the PDS or PCC about a malformed profile  
document, it turns out in practice that such a capability is  
incredibly important. Unless you have an alternate "debug" interface  
to the device, diagnosing a malformed profile document is a major,  
major PITA. I don't have a solution to propose, but if we could think  
of something fairly straightforward, it would be worth including in  
the draft.

Many of my comments above are made against what is largely  
descriptive text in section 6, so to the extent that these comments  
are address in a revision of the draft, normative text will be  
impacted as well.

Regards,
Dave

On Jun 29, 2007, at 8:50 AM, Mary Barnes wrote:

> review, a short "I read the document and I think it's ready (or  
> not)" is