A Framework for Session Initiation Protocol User Agent Profile Delivery
draft-ietf-sipping-config-framework-18

[Ballot comment]
[This was a part of my DISCUSS, but after discussing this on IESG call I am Ok (not happy, but Ok) that missing information about data model in a framework document is Ok]:

I have some major concerns about lack of data model definition in this document. Without that it is not possible to write 2 interoperable implementations. The document says that specific configuration formats are going to be specified in future documents. Are there any examples of such configuration formats?




6.2.3.  effective-by parameter

  Effective-By =  "effective-by" EQUAL 1*DIGIT

Does this value have an upper limit?

[Ballot discuss]
1) Section 5.3.5 says:

  While this framework does not impose specific constraints on any such
  framework, it does allow for the propagation of profile content to
  the PDS (specifically the PCC) from a network element or the device.

Figure 1 does not show the interaction between the network element.  Should Figure 1 be updated or should Section 5.3.5 be fixed?

[Ballot comment]
[This was a part of my DISCUSS, but after discussing this on IESG call I am Ok (not happy, but Ok) that missing information about data model in a framework document is Ok]:

I have some major concerns about lack of data model definition in this document. Without that it is not possible to write 2 interoperable implementations. The document says that specific configuration formats are going to be specified in future documents. Are there any examples of such configuration formats?




6.2.3.  effective-by parameter

  Effective-By =  "effective-by" EQUAL 1*DIGIT

Does this value have an upper limit?


9.1.  Local-network profile

  Alternatively, certain deployments may require the entities - device
  and the PDS - to authenticate each other prior to successful profile
  enrollment.  Such networks may pre-configure user identities to the
  devices and allow user-specific local-network profiles.  In such
  networks the PDS will support digest, and the devices are configured

COMMENT: suggest changing "suport digest" to "support Digest authentication" or similar.

[Ballot discuss]
I have a couple of very minor points and some questions about this document:

1)
5.1.1.  Profile Enrollment

      Upon failure to obtain the profile using any methods specified in
      this framework, the device MAY provide a user interface to allow
      for user intervention.  This can result in temporary, one-time
      data to bootstrap the device.  Such temporary data is not
      considered to be "configured" and SHOULD NOT not be cached across
      resets.

Did you mean "SHOULD be cached" (the "NOT not" part)?

2) ABNF needs to be a Normative reference for this document.

[Ballot discuss]
1. I share Alexey's concern about the difficulty of proving interoperability in the absence of a data model. Actually my conern is even broader, there are so many cases, and types of profiles, and the framework allows for newer types to be added that I cannot really see how parts of this document can be tested for interoperability. Maybe it would be useful to specify what of the whole text in the RFC is normative - probably most of section 5 and section 6, but not more.

2. [this comment cleared following editor clarification - thank you]

3. I am unconfortable with the way bootstraping of devices is described in Section 5.3.1. There are too many methods of doing the same thing, and there is no requirement for a mandatory method for compliance. Which of the ways of bootstrapping a device with the required identities and credentials is required, or if more than one is supported which one is preferred?

4. I find the discussion about Device Types in section 5.3.3 rather expedited and superficial in what concerns devices that do not directly communicate with any users like gateways, media servers or SIP servers. These ones have other functions than of an UA and may be configured by different methods and protocols, not only the ones that are being mentioned in this document. How do configuration operations that are performed part by using the framework, part by using other protocols work together?

[Ballot comment]
[This was a part of my DISCUSS, but after discussing this on IESG call I am Ok (not happy, but Ok) that missing information about data model in a framework document is Ok]:

I have some major concerns about lack of data model definition in this document. Without that it is not possible to write 2 interoperable implementations. The document says that specific configuration formats are going to be specified in future documents. Are there any examples of such configuration formats?



5.2.1.  Securing Profile Enrollment

  Transmission of
  sensitive profile data also requires message integrity.  This can be
  accomplished by configuring the device with, or by ensuring that the
  discovery process during profile enrollment provides, a SIPS URI
  resulting in TLS establishment ([RFC5246]).  TLS also prevents
  offline dictionary attacks when digest authentication is used.  Thus,
  in the absence of TLS, the device MUST NOT respond to any
  authentication challenges.

The last sentence: are you saying that Digest authentication MUST only be used over TLS?


6.2.1.  profile-type

  Profile-type  = "profile-type" EQUAL profile-value
  profile-value  =  profile-types / token
  profile-types  = "device" / "user" / "local-network"

So just to confirm, the values are case insensitive?

6.2.3.  effective-by parameter

  Effective-By =  "effective-by" EQUAL 1*DIGIT

Does this value have an upper limit?


9.1.  Local-network profile

  Alternatively, certain deployments may require the entities - device
  and the PDS - to authenticate each other prior to successful profile
  enrollment.  Such networks may pre-configure user identities to the
  devices and allow user-specific local-network profiles.  In such
  networks the PDS will support digest, and the devices are configured

COMMENT: suggest changing "suport digest" to "support Digest authentication" or similar.

[Ballot discuss]
I have a couple of very minor points and some questions about this document:

1)
5.1.1.  Profile Enrollment

      Upon failure to obtain the profile using any methods specified in
      this framework, the device MAY provide a user interface to allow
      for user intervention.  This can result in temporary, one-time
      data to bootstrap the device.  Such temporary data is not
      considered to be "configured" and SHOULD NOT not be cached across
      resets.

Did you mean "SHOULD be cached" (the "NOT not" part)?

2) ABNF needs to be a Normative reference for this document.

[Ballot comment]
For what it is worth, I think the configuration model is overly
complicated and some of the design decisions do not IMO work well
in the Internet environment. For instance, I would prefer discovery
and probing of the local network conditions as opposed to expecting
there to be a SIP-specific configuration server that delivers such
information. For instance, for most networks there will not be
a reliable way to provide any information about available bandwidth,
due to inability to estimate number of concurrent users, radio
conditions, and so on.

[Ballot discuss]
1. I share Alexey's concern about the difficulty of proving interoperability in the absence of a data model. Actually my conern is even broader, there are so many cases, and types of profiles, and the framework allows for newer types to be added that I cannot really see how parts of this document can be tested for interoperability. Maybe it would be useful to specify what of the whole text in the RFC is normative - probably most of section 5 and section 6, but not more.

2. In the operational model describe in Figure 3 - I cannot understand the difference between a 'Device Provider' and a 'Local Network Provider'. If a device is pre-configured, than its configuration is not subject to the framework (is it?). If not in all cases I know the 'device provider' is the same as the network provider (which needs not be only local BTW). Actually networks are configured by configuring devices.

3. I am unconfortable with the way bootstraping of devices is described in Section 5.3.1. There are too many methods of doing the same thing, and there is no requirement for a mandatory method for compliance. Which of the ways of bootstrapping a device with the required identities and credentials is required, or if more than one is supported which one is preferred?

4. I find the discussion about Device Types in section 5.3.3 rather expedited and superficial in what concerns devices that do not directly communicate with any users like gateways, media servers or SIP servers. These ones have other functions than of an UA and may be configured by different methods and protocols, not only the ones that are being mentioned in this document. How do configuration operations that are performed part by using the framework, part by using other protocols work together?

[Ballot comment]
1) 5.1.4.2: r/subscription URI/Subscription URI

2) 5.2: I noted the same thing as Peter did wrt the use of the term "privacy".

3) 5.2.1: I also noted the same thing Alexey did wrt to the use of Digest authentication over TLS.

4) 5.3.2: r/device must enroll/device MUST enroll

5) 5.3.2: I'd like to see some discussion about what happens when the device uses a cached device, user, and local network profile and it's no the same domain/local network which provided the cached data.

6) 5.3.4: r/This framework recommends the device profile to provide the identities and credentials due to a couple of reasons./This framework recommends the device profile provide the identities and credentials due to a couple of reasons.

7) 5.3.4: r/i.e., data that cannot be compromised/i.e., data that cannot be disclosed to unauthorized parties

8) 6.10: r/NOTIFY requests/NOTIFY requests.

9) 9: r/Compromise of sensitive data/Disclosure of sensitive data

10) 9: r/For sensitive data that should not be subject to snooping, privacy is also required./For sensitive data that should not be disclosed to unauthorized parties, privacy is also required.

11) 9.1: r/In such networks the PDS will support digest, and .../In such networks the PDS will support digest authentication, and ...

[Ballot discuss]
1) Section 5.3.5 says:

  While this framework does not impose specific constraints on any such
  framework, it does allow for the propagation of profile content to
  the PDS (specifically the PCC) from a network element or the device.

Figure 1 does not show the interaction between the network element.  Should Figure 1 be updated or should Section 5.3.5 be fixed?

2) Sec 5.2.1 caused me to pause a bit.  Sec 5.2.1 requires 3921 which requires digest authentication (HTTP Digest) which uses MD5 (section 5.2.2 also requires digest authentication).  MD5 is well liked anymore.  I'd like to see a security consideration added that says something to the effect of: when RFC 3921 was published MD5 might have been specified because it was "reasonable choice" but it probably isn't anymore; use of another hash alg (e.g., SHA-256) is preferred/recommended as specified in some sip document (not sure where it should point).

3) The term "mandatory" is not defined and it seems to be specifying conformance requirements.  Please point to where it is defined or modify the text is Sec 6.2 with something like:

OLD:

  m - mandatory
  s - SHOULD be provided
  o - optional

NEW:

  m - MUST be provided
  s - SHOULD be provided
  o - OPTIONAL to be provided

[Ballot comment]
Section 2 uses the term "entity" inconsistently -- for example, a Device can "contain entities such as a DHCP client" but the term SIP Service Provider can "refer to ... "public entities". I suggest changing the first instance to "application" and the second to "services".

Section 5.1.1 states: 

  The device needs certain data to create an enrollment request,
  form a Request-URI, and authenticate to the network.  This
  includes the profile provider's domain name, identities and
  credentials.

What are the provider's credentials here? Does this in fact mean the device's or user's credentials with the provider? If so, please express this more clearly.

Section 5.2 uses the term "privacy" when the term "data confidentiality" is meant.  See RFC 4949 for details (and if possible please align the usage of security terminology with RFC 4949).

Section 9.1 that "a PDS may not implement any authentication requirements or TLS". Does this mean that a PDS might happen to operate insecurely, or that it is allowed to (MAY) operate insecurely?

Section 11 includes organizational affiliations.  This information is not typically included in acknowledgements, since it goes against the IETF tradition of treating people as individuals, not as corporate representatives.  In any case, many of the affiliations are out of date.

[Ballot discuss]
[new DISCUSSes added 2010-04-21]

In Section 5.1.4.2, the guidelines for generating a device identifier seem overly complex. Why not simply re-use the Instance ID guidelines from Section 4.1 of RFC 5626, since the Instance ID is already a "URN that uniquely identifies the device"?

In Sections 5.2.1 and 5.2.2, this specification references RFC 2818 (HTTP over TLS) for authentication and server identity checking. Given that communication here occurs over SIP, the normative reference really should be draft-ietf-sip-domain-certs, not Section 3.1 of RFC 2818.

[Ballot comment]
5.2.1.  Securing Profile Enrollment

  Transmission of
  sensitive profile data also requires message integrity.  This can be
  accomplished by configuring the device with, or by ensuring that the
  discovery process during profile enrollment provides, a SIPS URI
  resulting in TLS establishment ([RFC5246]).  TLS also prevents
  offline dictionary attacks when digest authentication is used.  Thus,
  in the absence of TLS, the device MUST NOT respond to any
  authentication challenges.

The last sentence: are you saying that Digest authentication MUST only be used over TLS?


6.2.1.  profile-type

  Profile-type  = "profile-type" EQUAL profile-value
  profile-value  =  profile-types / token
  profile-types  = "device" / "user" / "local-network"

So just to confirm, the values are case insensitive?

6.2.3.  effective-by parameter

  Effective-By =  "effective-by" EQUAL 1*DIGIT

Does this value have an upper limit?


9.1.  Local-network profile

  Alternatively, certain deployments may require the entities - device
  and the PDS - to authenticate each other prior to successful profile
  enrollment.  Such networks may pre-configure user identities to the
  devices and allow user-specific local-network profiles.  In such
  networks the PDS will support digest, and the devices are configured

COMMENT: suggest changing "suport digest" to "support Digest authentication" or similar.

[Ballot discuss]
[Updated DISCUSS]

I have some major concerns about lack of data model definition in this document. Without that it is not possible to write 2 interoperable implementations. The document says that specific configuration formats are going to be specified in future documents. Are there any examples of such configuration formats?

[The remaining text is unchanged:]

I have a couple of very minor points and some questions about this document:

1)
5.1.1.  Profile Enrollment

      Upon failure to obtain the profile using any methods specified in
      this framework, the device MAY provide a user interface to allow
      for user intervention.  This can result in temporary, one-time
      data to bootstrap the device.  Such temporary data is not
      considered to be "configured" and SHOULD NOT not be cached across
      resets.

Did you mean "SHOULD be cached" (the "NOT not" part)?

2) ABNF needs to be a Normative reference for this document.

[Ballot comment]
5.2.1.  Securing Profile Enrollment

  Transmission of
  sensitive profile data also requires message integrity.  This can be
  accomplished by configuring the device with, or by ensuring that the
  discovery process during profile enrollment provides, a SIPS URI
  resulting in TLS establishment ([RFC5246]).  TLS also prevents
  offline dictionary attacks when digest authentication is used.  Thus,
  in the absence of TLS, the device MUST NOT respond to any
  authentication challenges.

The last sentence: are you saying that Digest authentication MUST only be used over TLS?


6.2.1.  profile-type

  Profile-type  = "profile-type" EQUAL profile-value
  profile-value  =  profile-types / token
  profile-types  = "device" / "user" / "local-network"

So just to confirm, the values are case insensitive?

6.2.3.  effective-by parameter

  Effective-By =  "effective-by" EQUAL 1*DIGIT

Does this value have an upper limit?

[Ballot discuss]
[Updated DISCUSS]

I have some major concerns about lack of data model definition in this document. Without that it is not possible to write 2 interoperable implementations. The document says that specific configuration formats are going to be specified in future documents. Are there any examples of such configuration formats?

[The remaining text is unchanged:]

I have a couple of very minor points and some questions about this document:

1)
5.1.1.  Profile Enrollment

      Upon failure to obtain the profile using any methods specified in
      this framework, the device MAY provide a user interface to allow
      for user intervention.  This can result in temporary, one-time
      data to bootstrap the device.  Such temporary data is not
      considered to be "configured" and SHOULD NOT not be cached across
      resets.

Did you mean "SHOULD be cached" (the "NOT not" part)?

2) ABNF needs to be a Normative reference for this document.

[Ballot comment]
Section 3.2., paragraph 5:
>    In more complex deployments, devices connect via a local network that
>    is not controlled by the SIP Service Provider, such as devices that
>    connect via available public WiFi hot spots.  In such cases, local
>    network providers may wish to provide local network information such
>    as bandwidth constraints to the devices.

  If by "bandwidth constraints" you mean *available* bandwidth, that'd
  be a bad example - it's clearly not configuration data. Is there a
  better example or a better way to phrase this?


Section 3.3., paragraph 5:
>    Additional profile types may also be specified.

  By whom? The IETF in future RFCs? Anyone out there deploying this
  framework? (Section 5.3.6 also doesn't make this clear.)


Section 6.2.2., paragraph 1:
>    The
>    implementer SHOULD use their DNS domain name (e.g., example.com) as
>    the value of the "vendor" parameter so that it is known to be unique.

  If you leave this a SHOULD, you cannot depend on it being unique.
  (Because two vendors may decide to not follow the SHOULD and pick
  conflicting values.)


Section 6.2.3., paragraph 1:
>    A value of 0 (zero) indicates that the subscribing
>    user agent must attempt to make the profiles effective immediately
>    (despite possible service interruptions).

  s/must attempt to/MUST/


Section 6.10., paragraph 1:
>    The rate of notifications for the profiles in this framework is
>    deployment specific, but expected to be infrequent.  Hence, the Event
>    Package specification does not specify a throttling or minimum period
>    between NOTIFY requests

  If its expected to be infrequent, you can easily specify a minimum
  period that won't interfere with operation and will prevent accidental
  bursts due to misconfiguration, etc. Please do so?

[Ballot comment]
Section 2 uses the term "entity" inconsistently -- for example, a Device can "contain entities such as a DHCP client" but the term SIP Service Provider can "refer to ... "public entities". I suggest changing the first instance to "application" and the second to "services".

Section 5.1.1 states: 

  The device needs certain data to create an enrollment request,
  form a Request-URI, and authenticate to the network.  This
  includes the profile provider's domain name, identities and
  credentials.

What are the provider's credentials here? Does this in fact mean the device's or user's credentials with the provider? If so, please express this more clearly.

Section 5.2 uses the term "privacy" when the term "data confidentiality" is meant.  See RFC 4949 for details (and if possible please align the usage of security terminology with RFC 4949).

Section 9.1 that "a PDS may not implement any authentication requirements or TLS". Does this mean that a PDS might happen to operate insecurely, or that it is allowed to (MAY) operate insecurely?

Section 11 includes organizational affiliations.  This information is not typically included in acknowledgements, since it goes against the IETF tradition of treating people as individuals, not as corporate representatives.  In any case, many of the affiliations are out of date.

[Ballot comment]
5.2.1.  Securing Profile Enrollment

  Transmission of
  sensitive profile data also requires message integrity.  This can be
  accomplished by configuring the device with, or by ensuring that the
  discovery process during profile enrollment provides, a SIPS URI
  resulting in TLS establishment ([RFC5246]).  TLS also prevents
  offline dictionary attacks when digest authentication is used.  Thus,
  in the absence of TLS, the device MUST NOT respond to any
  authentication challenges.

The last sentence: are you saying that Digest authentication MUST only be used over TLS?


6.2.1.  profile-type

  Profile-type  = "profile-type" EQUAL profile-value
  profile-value  =  profile-types / token
  profile-types  = "device" / "user" / "local-network"

So just to confirm, the values are case insensitive?

6.2.3.  effective-by parameter

  Effective-By =  "effective-by" EQUAL 1*DIGIT

Does this value have an upper limit?

[Ballot discuss]
I have a couple of very minor points and some questions about this document:

1)
5.1.1.  Profile Enrollment

      Upon failure to obtain the profile using any methods specified in
      this framework, the device MAY provide a user interface to allow
      for user intervention.  This can result in temporary, one-time
      data to bootstrap the device.  Such temporary data is not
      considered to be "configured" and SHOULD NOT not be cached across
      resets.

Did you mean "SHOULD be cached" (the "NOT not" part)?

2) ABNF needs to be a Normative reference for this document.

IANA comments:

Action #1:

Upon approval of this document, IANA will make the following assignment
in the "Session Initiation Protocol (SIP) Event Types Namespace"
registry at http://www.iana.org/assignments/sip-events

Package Name Type Contact Reference
-------------------------- ---------------- ----------------- --------
-
ua-profile package Daniel Petrie dan.ietf AT SIPez DOT com,
sumanth@cablelabs.com [RFC-sipping-config-framework-16]


Action #2:

Upon approval of this document, IANA will make the following assignments
in the "Header Field Parameters and Parameter Values" registry at
http://www.iana.org/assignments/sip-parameters

Predefined
Header Field Parameter Name Values Reference
---------------------------- --------------- --------- ---------
Event profile-type Yes [RFC-sipping-config-framework-16]
Event vendor No [RFC-sipping-config-framework-16]
Event model No [RFC-sipping-config-framework-16]
Event version No [RFC-sipping-config-framework-16]
Event effective-by No [RFC-sipping-config-framework-16]


Action #3:

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/sip-parameters

Registry Name: SIP Configuration Profile Types
Registration Procedure: Specification Required

Initial contents of this registry will be:
Profile Type Reference
-------------- ---------
local-network [RFC-sipping-config-framework-16]
device [RFC-sipping-config-framework-16]
user [RFC-sipping-config-framework-16]


We understand the above to be the only IANA Actions for this document.

PROTO questionnaire for: draft-ietf-sipping-config-framework-15

To be Published as: Proposed Standard

Prepared by: Mary Barnes (mary.barnes@nortel.com) on 29 February 2008


(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Mary Barnes is the document shepherd. She has reviewed this version of
the document and believes it is ready.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes, the document has had adequate review. The design team has
thoroughly
reviewed the document. The document has also been extensively reviewed
by
many key WG members, in particular John Elwell provided very detailed
reviews and suggestions for the document.
Other non-WG experts (security, Eric Rescorla and DNS, Peter Koch) have
been consulted and have reviewed relevant parts and concepts in this
doucment.
There are no concerns about the depth or breadth of reviews that have
been performed.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?
No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

There are no specific concerns or issues. There is no IPR disclosure.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is WG consensus behind this document and no one has
expressed concerns about its progression.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes. The draft has been validated for nits using idnits 2.08.04. The
only
nits identified will be resolved before the document is published
(references
to RFCXXXX and older versions of drafts).

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes, the references are split and all normative references have been
published.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

Yes, the IANA considerations section exists and includes the appropriate
registration
for a new Event package and defines a registry for the profile types.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There are no sections written in a formal language per se. The Event
package
defined follows the requirements specificed in RFC 3265.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
This document specifies a framework to enable configuration
of
Session Initiation Protocol (SIP) User Agents in SIP
deployments.
The framework provides a means to deliver profile data that
User
Agents need to be functional, automatically and with
minimal or no
User and Administrative intervention. The framework
describes how
SIP User Agents can discover sources, request profiles and
receive
notifications related to profile modifications. As part of
this
framework, a new SIP event package is defined for
notification of
profile changes. The framework provides minimal data
retrieval
options to ensure interoperability. The framework does not
include
specification of the profile data within its scope.

Working Group Summary
The SIPPING WG supports the development and advancement of
this document.

Document Quality
This document defines a new SIP event package and profile
types
for configuring SIP User agents. The document has
been thoroughly reviewed by members of the SIPPING WG
and members of the design team.

Personnel
Mary Barnes is the WG chair shepherd. Jon Peterson is the
responsible Area director.

There is still review activity surrounding this draft in the SIPPING WG. Will hold in AD Followup until this clears, and probably until it is revised.