Skip to main content

Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)
draft-ietf-bliss-shared-appearances-15

Revision differences

Document history

Date Rev. By Action
2015-03-24
15 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-03-23
15 (System) RFC Editor state changed to AUTH48 from AUTH48-DONE
2015-02-23
15 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-02-09
15 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2015-01-26
15 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2015-01-26
15 (System) RFC Editor state changed to EDIT from AUTH
2015-01-14
15 (System) RFC Editor state changed to AUTH from EDIT
2014-11-13
15 (System) RFC Editor state changed to EDIT from MISSREF
2013-02-11
15 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2013-02-06
15 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2013-01-18
15 (System) IANA Action state changed to Waiting on Authors from In Progress
2013-01-18
15 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent
2013-01-16
15 (System) IANA Action state changed to In Progress
2013-01-16
15 Cindy Morgan State changed to Approved-announcement sent from IESG Evaluation::AD Followup
2013-01-16
15 Cindy Morgan IESG has approved the document
2013-01-16
15 Cindy Morgan Closed "Approve" ballot
2013-01-16
15 Cindy Morgan Ballot approval text was generated
2013-01-16
15 Pete Resnick [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Discuss
2013-01-16
15 Alan Johnston New version available: draft-ietf-bliss-shared-appearances-15.txt
2013-01-10
14 Pete Resnick
[Ballot discuss]
I still have some concerns with a few pieces of section 5.3:

  User Agents that support the Shared Appearance feature MUST support …
[Ballot discuss]
I still have some concerns with a few pieces of section 5.3:

  User Agents that support the Shared Appearance feature MUST support
  the dialog state package [RFC4235] with the shared appearance
  extensions and the 'shared' Event header field parameter defined in
  Section 13.

  User Agents MUST support the dialog package extensions in Section 5.2
  along with SUBSCRIBE and NOTIFY [I-D.ietf-sipcore-rfc3265bis] and
  PUBLISH [RFC3903].

The MUSTs are wrong here. Instead: "User Agents that support the Shared Appearance feature use the dialog state package..." or even better: "The Shared Appearance feature uses the dialog state package...". There is no interoperability warning here; you're simply describing what the protocol does. Just as you don't ever say "MUST support SIP" (which would be silly), it is equally silly to say say that you "MUST support the dialog package stuff". If I could not sensibly choose to do otherwise, the MUST is not useful.

  When publishing or notifying dialog package information, a UA MUST
  include all dialog identification available at the time of
  publication, with the exception that a UA may omit information if it
  wishes to prevent other UAs from joining or picking up a call.

Again, you're not saying something about timing ("at the time of publication") or other interoperability concern. You're saying, "If you want to include dialog information, you MUST include dialog information." That's not a needed MUST. (Again, unless I'm missing something.)

  If the call is an emergency call, a UA MUST never wait for a
  confirmed seizure before sending an INVITE.  Instead, the emergency
  call MUST proceed without waiting for the PUBLISH transaction.

  Otherwise, in the following cases, before sending the INVITE, a UA
  MUST send a dialog package PUBLISH request and wait for a 2xx
  response before proceeding:

I still don't really understand the MUST in the second paragraph. If you don't have to wait for the response to send the INVITE in the emergency case, what harm is there in not waiting in non-emergency cases?
2013-01-10
14 Pete Resnick Ballot comment and discuss text updated for Pete Resnick
2013-01-09
14 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2013-01-02
14 Brian Haberman [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss
2012-12-27
14 Stephen Farrell
[Ballot discuss]

-13 has some changes from discussion in August '12, but
REQ-3 seems unchanged. Not sure if changes reflect all
the rest of the …
[Ballot discuss]

-13 has some changes from discussion in August '12, but
REQ-3 seems unchanged. Not sure if changes reflect all
the rest of the email from August yet. Emailed authors
on 2012-12-27.

4.1, REQ-3: what does "in a secure way" mean? I think
that's very vague and it means its not possible to know
if section 12 meets the requirement, since, just to take
one example "secure way" might mean that the UA
authorizes the appearance agent to be such a thing, or
it might mean that UAs will believe whoever is first to
claim to be the appearance agent. I think this needs a
bit more elucidation, and depending on the outcome, some
or no change might be needed, mainly in section 12 I
would guess, but hard to say until the meaning of REQ-3
is clear.
2012-12-27
14 Stephen Farrell
[Ballot comment]
- I can't see where (in the mail archive) the WG are ok
with the IPR declaration here. All I found so far …
[Ballot comment]
- I can't see where (in the mail archive) the WG are ok
with the IPR declaration here. All I found so far is the
announcement of the declaration and nothing else. Did
the WG in fact consider this IPR declaration and decide
they were ok with it? (It may have happened, I didn't
read the list, just searched the on-line archive for the
string "IPR.")

Some of my comments below are probably down to not
being familiar with the terminology/use-cases but then that
will be true of other RFC readers so may be worth
considering.

- 4.1: lower case "must" in the requirements confused
me, better to use MUST if you mean 2119 MUST or explain
if you don't

- 4.1, REQ-3: I also wondered how you'd setup a group
over the public Internet and whether that's addressed
here or not - the use cases don't clarify but I can
imagine home workers using this

- 4.1, REQ-5: introducing the n,N notation here seems
like wrong and isn't really needed

- 4.1, REQ-6: I wondered why I couldn't have an
appearance name, icon or avatar and why it must be a
number

- 4.1, REQ-7: I don't know what appearance contention
means exactly.

- section 5: what's the max appearance number that
MUST be supported? Can I seize line [1]? :-) That
may be caught by some generic SIP thing, I dunno.

  [1] http://primes.utm.edu/primes/page.php?id=85527

- p14, s/Increading/Increasing/

- p15, Is this not a repeated MUST about emergency
calling from some other RFC(s)? If so, is that needed
here or not? Repeating normative language is usually
not such a good plan.

- p17, s/not have/not having/

- section 7, 3rd para: I don't get what "If an
appearance number parameter is already present
(associated with another AOR or by mistake), the value
is rewritten adding the new appearance number" means.
Can't two AORs use appearance=1 via the same proxy or
something?  That's a surprise.

- section 7, I'm surprised that ring-tones need to
be mentioned here.
2012-12-27
14 Stephen Farrell Ballot comment and discuss text updated for Stephen Farrell
2012-12-21
14 Barry Leiba
[Ballot comment]
Updated for version -14:
Version -14 resolves all the issues I brought up -- thanks very much for dealing with them.  In particular, …
[Ballot comment]
Updated for version -14:
Version -14 resolves all the issues I brought up -- thanks very much for dealing with them.  In particular, I like the changes in Section 5.3, especially about the appearance numbers... and I'm surprised that it took so few text changes to take care of that.

Good work, and, again, thanks.
2012-12-21
14 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2012-12-21
14 (System) Sub state has been changed to AD Followup from Revised ID Needed
2012-12-21
14 Alan Johnston New version available: draft-ietf-bliss-shared-appearances-14.txt
2012-08-21
13 Pete Resnick
[Ballot comment]
[Removed duplicated info already in the DISCUSS; sorry for the additional message.]

4.1: REQ-16: This struck me as perhaps over-constrained, but maybe I'm …
[Ballot comment]
[Removed duplicated info already in the DISCUSS; sorry for the additional message.]

4.1: REQ-16: This struck me as perhaps over-constrained, but maybe I'm just reading it wrong. Are you saying that there needs to at least pipeline the two requests, or are you saying that there needs to be a way to combine the two actions into a single request? It wasn't clear to me what precisely the requirement was.

5.2.2:

  It is important to note that this element is a hint.

This sentence leaves me wondering why Appearance Agents are not required to prevent the Join or Replaces if the UA says . It seems like it would be a potential security issue to not have a requirement on the Appearance Agent to honor the . Furthermore, trying to prevent such things by hiding dialog information seems like a hacky way to do this. Something seems goofy here.

5.3:

  User Agents that support the Shared Appearance feature MUST support
  the dialog state package [RFC4235] with the shared appearance
  extensions and the 'shared' Event header field parameter defined in
  Section 13.

  User Agents MUST support the dialog package extensions in Section 5.2
  along with SUBSCRIBE and NOTIFY [I-D.ietf-sipcore-rfc3265bis] and
  PUBLISH [RFC3903].

I'm not clear on what interoperability problem you are trying to avoid by saying "MUST support" here. Can you tell me what happens if I write a user agent that doesn't support these things? Could "MUST support" simply be replaced with "will need to implement"? (The other two "MUST support" phrases in this section are about what you need to put on or take off the wire, so they didn't strike me as odd as the others.)

  When publishing or notifying dialog package information, a UA MUST
  include all dialog identification available at the time of
  publication, with the exception that a UA may omit information if it
  wishes to prevent other UAs from joining or picking up a call.

Are you saying that there are no other imaginable circumstances where I might not include some dialog information other than preventing joining or replacing? That MUST seems overdone.

  A user may select an appearance number but then abandon placing a
  call (go back on hook).  In this case, the UA MUST free up the
  appearance number by removing the event state with a PUBLISH as
  described in [RFC3903].
 
I'm not clear on why the above is a MUST. Are we saying that if the UA doesn't free up the number, we're going to get a bunch of stale appearance numbers and potentially run out of them? It seems rather brittle to depend on the UA to do this.

  A UA SHOULD register against the AOR only if it is likely the UA will
  be answering incoming calls.  If the UA is mainly going to be
  monitoring the status of the shared appearance group calls and
  picking or joining calls, the UA SHOULD only subscribe to the AOR and
  not register against the AOR.

Why is there 2119 language here? Is there some problem if I simply register, even if I'm not sure I'm going to be answering calls? Rather than the 2119 language (or in addition to if this is really trying to limit the potential for causing harm), an explanation of the potential downside is in order.
2012-08-21
13 Pete Resnick Ballot comment text updated for Pete Resnick
2012-08-21
13 Pete Resnick
[Ballot discuss]
I generally agree with Barry's DISCUSS item regarding 2119 language. The following are a couple of examples from section 5.3 that I find …
[Ballot discuss]
I generally agree with Barry's DISCUSS item regarding 2119 language. The following are a couple of examples from section 5.3 that I find particularly egregious:

  When calls are placed on hold, the
  "+sip.rendering=no" feature tag MUST be included in dialog package
  notifications.

This MUST seems completely bogus. What if I want to have a feature called "Hold but keep private" so that someone can be put on hold, but nobody else knows that I'm not listening to what the person says? You're saying that I MUST NOT do that? I don't buy it as an interoperability requirement.

  In the following cases, before sending the INVITE, A UA MUST send a
  dialog package PUBLISH request and wait for a 2xx response before
  proceeding:
  [...]
  An exception is an emergency call, when a UA MUST never wait for a
  confirmed seizure before sending an INVITE.  Instead, the emergency
  call MUST proceed without waiting for the PUBLISH transaction.

The first MUST is really a SHOULD; there are circumstances (or at least one circumstance: the emergency call) in which you do not need to send the PUBLISH and wait. The other two MUSTs seem all about usability, not interoperability or damage to the network. That is, the MUSTs are not protocol requirements; they are user requirements. The last paragraph should be rewritten.

  An exception is an emergency call, where the UA will certainly want
  to send the INVITE immediately and not bother waiting for the
  PUBLISH transaction. It is more important for the emergency call to
  go through than to confirm the seizure.

2119 text there is wrong.

  Appearance numbers are a shorthand label for active and pending
  dialogs related to an AOR.  Many of the features and services built
  using this extension rely on the correct rendering of this
  information to the human user.  [...]

The 2119 language in this paragraph is simply bogus. As the paragraph says, these are about "correct rendering" along with "value and usefulness". They are not about interoperability and not about limiting potential for harm. Describing the intended semantics is fine, but trying to dictate particular user interface elements is not. As 2119 says, "they must not be used to try to impose a particular method on implementors where the method is not required for interoperability."

Below in the COMMENTs are additional 2119 uses that might be a problem, but I've got some questions about them. They might end up as part of the DISCUSSion if there are not good reasons to use them.
2012-08-21
13 Pete Resnick
[Ballot comment]
4.1: REQ-16: This struck me as perhaps over-constrained, but maybe I'm just reading it wrong. Are you saying that there needs to at …
[Ballot comment]
4.1: REQ-16: This struck me as perhaps over-constrained, but maybe I'm just reading it wrong. Are you saying that there needs to at least pipeline the two requests, or are you saying that there needs to be a way to combine the two actions into a single request? It wasn't clear to me what precisely the requirement was.

5.2.2:

  It is important to note that this element is a hint.

This sentence leaves me wondering why Appearance Agents are not required to prevent the Join or Replaces if the UA says . It seems like it would be a potential security issue to not have a requirement on the Appearance Agent to honor the . Furthermore, trying to prevent such things by hiding dialog information seems like a hacky way to do this. Something seems goofy here.

5.3:

  User Agents that support the Shared Appearance feature MUST support
  the dialog state package [RFC4235] with the shared appearance
  extensions and the 'shared' Event header field parameter defined in
  Section 13.

  User Agents MUST support the dialog package extensions in Section 5.2
  along with SUBSCRIBE and NOTIFY [I-D.ietf-sipcore-rfc3265bis] and
  PUBLISH [RFC3903].

I'm not clear on what interoperability problem you are trying to avoid by saying "MUST support" here. Can you tell me what happens if I write a user agent that doesn't support these things? Could "MUST support" simply be replaced with "will need to implement"? (The other two "MUST support" phrases in this section are about what you need to put on or take off the wire, so they didn't strike me as odd as the others.)

  When publishing or notifying dialog package information, a UA MUST
  include all dialog identification available at the time of
  publication, with the exception that a UA may omit information if it
  wishes to prevent other UAs from joining or picking up a call.

Are you saying that there are no other imaginable circumstances where I might not include some dialog information other than preventing joining or replacing? That MUST seems overdone.

  When calls are placed on hold, the
  "+sip.rendering=no" feature tag MUST be included in dialog package
  notifications.

This MUST seems completely bogus. What if I want to have a feature called "Hold but keep private" so that someone can be put on hold, but nobody else knows that I'm not listening to what the person says? You're saying that I MUST NOT do that? I don't buy it as an interoperability requirement.

  In the following cases, before sending the INVITE, A UA MUST send a
  dialog package PUBLISH request and wait for a 2xx response before
  proceeding:
  [...]
  An exception is an emergency call, when a UA MUST never wait for a
  confirmed seizure before sending an INVITE.  Instead, the emergency
  call MUST proceed without waiting for the PUBLISH transaction.

The first MUST is really a SHOULD; there are circumstances (or at least one circumstance: the emergency call) in which you do not need to send the PUBLISH and wait. The other two MUSTs seem all about usability, not interoperability or damage to the network. That is, the MUSTs are not protocol requirements; they are user requirements. The last paragraph should probably be rewritten.

  An exception is an emergency call, where the UA will certainly want
  to send the INVITE immediately and not bother waiting for the
  PUBLISH transaction. It is more important for the emergency call to
  go through than to confirm the seizure.

2119 text there is wrong.

  Appearance numbers are a shorthand label for active and pending
  dialogs related to an AOR.  Many of the features and services built
  using this extension rely on the correct rendering of this
  information to the human user.  [...]

The 2119 language in this paragraph is simply bogus. As the paragraph says, these are about "correct rendering" along with "value and usefulness". They are not about interoperability and not about limiting potential for harm. Describing the intended semantics is fine, but trying to dictate particular user interface elements is not. As 2119 says, "they must not be used to try to impose a particular method on implementors where the method is not required for interoperability."

  A user may select an appearance number but then abandon placing a
  call (go back on hook).  In this case, the UA MUST free up the
  appearance number by removing the event state with a PUBLISH as
  described in [RFC3903].
 
I'm not clear on why the above is a MUST. Are we saying that if the UA doesn't free up the number, we're going to get a bunch of stale appearance numbers and potentially run out of them? It seems rather brittle to depend on the UA to do this.

  A UA SHOULD register against the AOR only if it is likely the UA will
  be answering incoming calls.  If the UA is mainly going to be
  monitoring the status of the shared appearance group calls and
  picking or joining calls, the UA SHOULD only subscribe to the AOR and
  not register against the AOR.

Why is there 2119 language here? Is there some problem if I simply register, even if I'm not sure I'm going to be answering calls? Rather than the 2119 language (or in addition to if this is really trying to limit the potential for causing harm), an explanation of the potential downside is in order.
2012-08-21
13 Pete Resnick [Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick
2012-08-16
13 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation
2012-08-16
13 Barry Leiba
[Ballot discuss]
General issue in Section 5.3: I'm teetering between not commenting and objecting to the inclusion of 2119 language related to UA behaviour.  It …
[Ballot discuss]
General issue in Section 5.3: I'm teetering between not commenting and objecting to the inclusion of 2119 language related to UA behaviour.  It strikes me that lots of it might be very good advice, but not be at the level of 2119 MUST and SHOULD and SHOULD NOT.

For instance, this one does appear to relate to proper operation of the protocol, and merits the MUST:

  A user may select an appearance number but then abandon placing a
  call (go back on hook).  In this case, the UA MUST free up the
  appearance number by removing the event state with a PUBLISH as
  described in [RFC3903].

There are others of that nature in here.  On the other hand, with this (parenthesized bits removed to make the point more clear):

  The appearances number for each active and pending dialog SHOULD be
  explicitly or implicitly rendered to the user.  The far end identity
  of each dialog MUST NOT be rendered in place of the appearance number.
  The state of each appearance SHOULD also be rendered.

...isn't that all just quality of implementation stuff?  Could any entity on the other end tell whether your UA did or did not abide by this?  How would it affect interoperability (as opposed to just user experience) if a UA paid no attention to this at all?

I think you should be reserving 2119 language for things that really affect how the protocol works, and make advice that affects the user experience and usability be normal lower-case English.  (And I like Section 8, which gives good UA advice with no 2119 language.)
2012-08-16
13 Barry Leiba Ballot discuss text updated for Barry Leiba
2012-08-16
13 Sean Turner
[Ballot comment]
Robert addressed my discuss points on the call.  Thanks.

1) s4.1, REQ-3: Same question as Stephen.

2) s4.2: Tripped over the fact that …
[Ballot comment]
Robert addressed my discuss points on the call.  Thanks.

1) s4.1, REQ-3: Same question as Stephen.

2) s4.2: Tripped over the fact that the section is informative, the intro of s4.2 para says s5 is normative, but the definition of the appearance parameter is in s7.  Maybe add a forward pointer to s7 when you start to discuss the parameter?

3) s4.2m step 2: State Agent or Appearance Agent?

4) s5.2.2/s5.3: call-id or Call-ID, From tag or from-tag, local tag or local-tag?

5) s5.3: There's a couple of paragraphs that are indented - was this done purposely?  Are these supposed to be notes?

6) s5.3: If a UA does insert an 'appearance' parameter what happens?

7) s7/s5.3: probably worth driving home again that the 'appearance' parameter is only inserted by an appearance agent (then again maybe 3261 already says this?).

8) s11: Pretty please can we have one example with security!?
2012-08-16
13 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2012-08-15
13 Barry Leiba
[Ballot discuss]
1. It's not clear to me why this needs to "Update" 3261 and 4235.  It seems to add new optional function, but not …
[Ballot discuss]
1. It's not clear to me why this needs to "Update" 3261 and 4235.  It seems to add new optional function, but not make any required changes that would constitute an "Update".  Anyone who didn't need this function could implement 3261 and 4235 without ever looking at this, and their implementation would be fine, right?  Please explain why this should have an "Updates" relationship.

2. General issue in Section 5.3: I'm teetering between not commenting and objecting to the inclusion of 2119 language related to UA behaviour.  It strikes me that lots of it might be very good advice, but not be at the level of 2119 MUST and SHOULD and SHOULD NOT.

For instance, this one does appear to relate to proper operation of the protocol, and merits the MUST:

  A user may select an appearance number but then abandon placing a
  call (go back on hook).  In this case, the UA MUST free up the
  appearance number by removing the event state with a PUBLISH as
  described in [RFC3903].

There are others of that nature in here.  On the other hand, with this (parenthesized bits removed to make the point more clear):

  The appearances number for each active and pending dialog SHOULD be
  explicitly or implicitly rendered to the user.  The far end identity
  of each dialog MUST NOT be rendered in place of the appearance number.
  The state of each appearance SHOULD also be rendered.

...isn't that all just quality of implementation stuff?  Could any entity on the other end tell whether your UA did or did not abide by this?  How would it affect interoperability (as opposed to just user experience) if a UA paid no attention to this at all?

I think you should be reserving 2119 language for things that really affect how the protocol works, and make advice that affects the user experience and usability be normal lower-case English.  (And I like Section 8, which gives good UA advice with no 2119 language.)
2012-08-15
13 Barry Leiba
[Ballot comment]
Substantive comments; these are non-blocking, but please consider them
seriously, and feel free to chat with me about them:

-- Section 4.1 -- …
[Ballot comment]
Substantive comments; these are non-blocking, but please consider them
seriously, and feel free to chat with me about them:

-- Section 4.1 --

I'm puzzled by REQs 11 and 12.  What does it mean for a UA that's not aware of this feature to register as part of the group.  It seems that it would then in effect violate REQ 12, by behaving in a way that's contrary to what's expected for the group (seizing and manipulating appearance numbers badly).  Please enlighten me.

-- Section 5.3 --

OLD
  In the following cases, before sending the INVITE, A UA MUST send a
  dialog package PUBLISH request and wait for a 2xx response before
  proceeding:

  [four-item list appears here]

  An exception is an emergency call, when a UA MUST never wait for a
  confirmed seizure before sending an INVITE.  Instead, the emergency
  call MUST proceed without waiting for the PUBLISH transaction.

This last bit seems important, but it can be hard to see what it's an exception to, because the antecedent is too far ahead of it, separated from it by too much.  I suggest moving this up and re-phrasing it.  Something like this:

NEW
  If the call is an emergency call, a UA MUST never wait for a
  confirmed seizure before sending an INVITE.  Instead, the emergency
  call MUST proceed without waiting for the PUBLISH transaction.

  Otherwise, in the following cases, before sending the INVITE, a
  UA MUST send a dialog package PUBLISH request and wait for a 2xx
  response before proceeding:
---

-- Section 5.3.3 --

OLD
  If Alice is the transferee, the triggered INVITE from the REFER is
  treated as a consultation call.  Alice SHOULD publish requesting that
  the Appearance Agent not assign an appearance number for this INVITE.
  When the transfer completes, Alice SHOULD publish again to move the
  appearance number from the dialog with Carol to the dialog with
  David.  Note that this publication MUST be sent prior to sending the
  BYE to Carol to avoid a race condition where the Appearance Agent
  reassigns the appearance number after seeing the BYE.

I'm confused about the MUST after the two SHOULDs.  It seems that there could be conditions when Alice might not publish at all (if there are good reasons to violate both SHOULDs).  How does the MUST apply then?  Can you re-organize or re-word this paragraph to fix this?

-- Section 5.4 --

  The Appearance Agent MUST have a way of discovering the state of all
  dialogs associated with the AOR.  If this information is not
  available from a call stateful proxy or Back-to-Back User Agent
  (B2BUA), the Appearance Agent MAY use the registration event package
  [RFC3680] to learn of UAs associated with the AOR and MAY subscribe
  to their dialog event state.  Also, an Appearance Agent MAY subscribe
  to a UAs dialog event state in order to reconstruct state.  As a
  result, the registrar MUST support the registration event package.

I think the MAYs are all wrong here, as 2119 words.  I think the keys are the two MUSTs, and the rest of it is just suggesting ways that the Appearance Agent might comply with the first MUST.

-- Section 13.2 --
Because IANA figured this out, I'm not making this a DISCUSS... but please do fix this: you changed Section 13.1 to answer IANA's question, but you left 13.2 as it was (because they figured it out).  But it looks like 13.2 should have the same(-ish) text as 13.1, specifying the same registry.  So:

OLD
  This document defines the 'appearance' parameter to the Alert-Info
  header in the SIP Parameters registry.
NEW
  This document defines the 'appearance' header field parameter to the
  Alert-Info header field in the "SIP Header Field Parameters and Parameter
  Values" registry defined by [RFC3968].

(I'll also note that the last line of both 13.1 and 13.2 (the ones that say "[RFC-to-be]") are two characters too long (this is an ID-nit).  While you're at it, you might just delete two extraneous characters from each, to shorten them.  But the RFC Editor will take care of this if you don't, so it doesn't really matter.)

========
Other comments; no need to respond to these. Take them or modify them
as you please:

-- Section 4.1 --
  REQ-5 The mechanism must scale for large numbers of appearances, n,
  and large numbers of UAs, N, without introducing excessive messaging
  traffic.

You don't further use "n" and "N", so what's the point of having them here?

-- Section 4.2 --
  - The SIP Replaces and Join header fields meets REQ-3.
They meets it?  Umph.
How about:
  - The SIP Replaces and Join header fields, used together, meet REQ-3.
Or:
  - The combination of the SIP Replaces and Join header fields meets REQ-3.
2012-08-15
13 Barry Leiba Ballot comment and discuss text updated for Barry Leiba
2012-08-15
13 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms
2012-08-15
13 Barry Leiba
[Ballot discuss]
It's not clear to me why this needs to "Update" 3261 and 4235.  It seems to add new optional function, but not make …
[Ballot discuss]
It's not clear to me why this needs to "Update" 3261 and 4235.  It seems to add new optional function, but not make any required changes that would constitute an "Update".  Anyone who didn't need this function could implement 3261 and 4235 without ever looking at this, and their implementation would be fine, right?  Please explain why this should have an "Updates" relationship.
2012-08-15
13 Barry Leiba
[Ballot comment]
Still reviewing, but I wanted to get this in without more delay.  I might update this later.

Substantive comments; these are non-blocking, but …
[Ballot comment]
Still reviewing, but I wanted to get this in without more delay.  I might update this later.

Substantive comments; these are non-blocking, but please consider them
seriously, and feel free to chat with me about them:

-- Section 4.1 --

I'm puzzled by REQs 11 and 12.  What does it mean for a UA that's not aware of this feature to register as part of the group.  It seems that it would then in effect violate REQ 12, by behaving in a way that's contrary to what's expected for the group (seizing and manipulating appearance numbers badly).  Please enlighten me.

-- Section 13.2 --
Because IANA figured this out, I'm not making this a DISCUSS... but please do fix this: you changed Section 13.1 to answer IANA's question, but you left 13.2 as it was (because they figured it out).  But it looks like 13.2 should have the same(-ish) text as 13.1, specifying the same registry.  So:
OLD
  This document defines the 'appearance' parameter to the Alert-Info
  header in the SIP Parameters registry.
NEW
  This document defines the 'appearance' header field parameter to the
  Alert-Info header field in the "SIP Header Field Parameters and Parameter
  Values" registry defined by [RFC3968].

(I'll also note that the last line of both 13.1 and 13.2 (the ones that say "[RFC-to-be]") are two characters too long (this is an ID-nit).  While you're at it, you might just delete two extraneous characters from each, to shorten them.  But the RFC Editor will take care of this if you don't, so it doesn't really matter.)

========
Other comments; no need to respond to these. Take them or modify them
as you please:

-- Section 4.1 --
  REQ-5 The mechanism must scale for large numbers of appearances, n,
  and large numbers of UAs, N, without introducing excessive messaging
  traffic.

You don't further use "n" and "N", so what's the point of having them here?

-- Section 4.2 --
  - The SIP Replaces and Join header fields meets REQ-3.
They meets it?  Umph.
How about:
  - The SIP Replaces and Join header fields, used together, meet REQ-3.
Or:
  - The combination of the SIP Replaces and Join header fields meets REQ-3.
2012-08-15
13 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2012-08-15
13 Sean Turner
[Ballot discuss]
1) Wanting to make sure we bake security in from the get-go:

s4.2: In the steps where do the UAs register their certificate …
[Ballot discuss]
1) Wanting to make sure we bake security in from the get-go:

s4.2: In the steps where do the UAs register their certificate in case they wants to use S/MIME to provide confidentiality?  Is 6702 supposed to be used?

2) s5.3: For emergency calls, can the UA prohibit others from joining?  I can see where maybe that would be good: There's a hostage situation, I'm under the desk, bad guys don't know I'm there, I'd like to get a call through and maybe not have them listen in.  Also bad though: the bad guys call for help, disallowing others to join, and just letting the phone hang off the hook.  Was this kind of thing considered - or is addressed somewhere else in the SIP library ;) 

3) s12: Forgive me if this is covered in 3261, 4235, 3265bis, or 3903, but could an adversary also learn about the members of the AOR.  Say I'm in the SSID (super secret investigations unit) with four other folks, all of which are supposed to be UC (undercover), if an adversary can see over time who answers the calls from the AOR they'd be able to piece together who was in the SSID.
2012-08-15
13 Sean Turner
[Ballot comment]
1) s4.1, REQ-3: Same question as Stephen.

2) s4.2: Tripped over the fact that the section is informative, the intro of s4.2 para …
[Ballot comment]
1) s4.1, REQ-3: Same question as Stephen.

2) s4.2: Tripped over the fact that the section is informative, the intro of s4.2 para says s5 is normative, but the definition of the appearance parameter is in s7.  Maybe add a forward pointer to s7 when you start to discuss the parameter?

3) s4.2m step 2: State Agent or Appearance Agent?

4) s5.2.2/s5.3: call-id or Call-ID, From tag or from-tag, local tag or local-tag?

5) s5.3: There's a couple of paragraphs that are indented - was this done purposely?  Are these supposed to be notes?

6) s5.3: If a UA does insert an 'appearance' parameter what happens?

7) s7/s5.3: probably worth driving home again that the 'appearance' parameter is only inserted by an appearance agent (then again maybe 3261 already says this?).

8) s11: Pretty please can we have one example with security!?
2012-08-15
13 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner
2012-08-13
13 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy
2012-08-13
13 Brian Haberman
[Ballot discuss]
For the most part, I found this document well-written, but there are a few areas where it can be tightened up.

1. In …
[Ballot discuss]
For the most part, I found this document well-written, but there are a few areas where it can be tightened up.

1. In section 5.4, is the "should" in "... and an immediate NOTIFY should be sent to the UA..." normative?  If so, I would suggest consistency in the capitalization of 2119 keywords.  If it is normative, in what situation(s) can the NOTIFY not be sent?

There are similar situations in sections 7 and 8.1.1...

In section 7, is "...a normal ringtone should be indicated..." a normative description?

In section 8.1.1, is "The UA should still send messages..." normative?

Also in 8.1.1, is "...should be rejected with a 486..." normative?

2. I would also like to understand what "minimal amount of configuration" means in REQ-4.  Since this requirement seems to be addressed by the use of the State Agent, I am not sure how it is a requirement for this functionality.
2012-08-13
13 Brian Haberman
[Ballot comment]
1. I agree with Stephen's DISCUSS point on the meaning of "in a secure way".

2.I assume that the lower-case 2119 keywords used …
[Ballot comment]
1. I agree with Stephen's DISCUSS point on the meaning of "in a secure way".

2.I assume that the lower-case 2119 keywords used in the requirements statements are only descriptive.  If not, I would suggest addressing the inconsistency in capitalization.
2012-08-13
13 Brian Haberman [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman
2012-08-13
13 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2012-08-12
13 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley
2012-08-12
13 Stephen Farrell
[Ballot discuss]

4.1, REQ-3: what does "in a secure way" mean? I think
that's very vague and it means its not possible to know
if …
[Ballot discuss]

4.1, REQ-3: what does "in a secure way" mean? I think
that's very vague and it means its not possible to know
if section 12 meets the requirement, since, just to take
one example "secure way" might mean that the UA
authorizes the appearance agent to be such a thing, or
it might mean that UAs will believe whoever is first to
claim to be the appearance agent. I think this needs a
bit more elucidation, and depending on the outcome, some
or no change might be needed, mainly in section 12 I
would guess, but hard to say until the meaning of REQ-3
is clear.
2012-08-12
13 Stephen Farrell
[Ballot comment]

- I can't see where (in the mail archive) the WG are ok
with the IPR declaration here. All I found so far …
[Ballot comment]

- I can't see where (in the mail archive) the WG are ok
with the IPR declaration here. All I found so far is the
announcement of the declaration and nothing else. Did
the WG in fact consider this IPR declaration and decide
they were ok with it? (It may have happened, I didn't
read the list, just searched the on-line archive for the
string "IPR.")

Some of my comments below are probably down to not
being familiar with the terminology/use-cases but then that
will be true of other RFC readers so may be worth
considering.

- 4.1: lower case "must" in the requirements confused
me, better to use MUST if you mean 2119 MUST or explain
if you don't

- 4.1, REQ-3: I also wondered how you'd setup a group
over the public Internet and whether that's addressed
here or not - the use cases don't clarify but I can
imagine home workers using this

- 4.1, REQ-5: introducing the n,N notation here seems
like wrong and isn't really needed

- 4.1, REQ-6: I wondered why I couldn't have an
appearance name, icon or avatar and why it must be a
number

- 4.1, REQ-7: I don't know what appearance contention
means exactly.

- section 5: what's the max appearance number that
MUST be supported? Can I seize line [1]? :-) That
may be caught by some generic SIP thing, I dunno.

  [1] http://primes.utm.edu/primes/page.php?id=85527

- p14, s/Increading/Increasing/

- p15, Is this not a repeated MUST about emergency
calling from some other RFC(s)? If so, is that needed
here or not? Repeating normative language is usually
not such a good plan.

- p17, s/not have/not having/

- section 7, 3rd para: I don't get what "If an
appearance number parameter is already present
(associated with another AOR or by mistake), the value
is rewritten adding the new appearance number" means.
Can't two AORs use appearance=1 via the same proxy or
something?  That's a surprise.

- section 7, I'm surprised that ring-tones need to
be mentioned here.
2012-08-12
13 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2012-08-11
13 Adrian Farrel
[Ballot comment]
A clear and well-written document. Thanks you.

---

Section 7

I think you need to add a reference to RFC 5234 when you …
[Ballot comment]
A clear and well-written document. Thanks you.

---

Section 7

I think you need to add a reference to RFC 5234 when you mention ABNF.
2012-08-11
13 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2012-08-10
13 Samuel Weiler Request for Telechat review by SECDIR is assigned to Derek Atkins
2012-08-10
13 Samuel Weiler Request for Telechat review by SECDIR is assigned to Derek Atkins
2012-08-10
13 Stewart Bryant
[Ballot comment]
I am taking a position of no objection on the basis of a quick read to determine that there were no apparent routing …
[Ballot comment]
I am taking a position of no objection on the basis of a quick read to determine that there were no apparent routing considerations and my confidence in the shepherding AD.
2012-08-10
13 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2012-08-10
13 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica
2012-08-09
13 David Black Request for Telechat review by GENART Completed: Ready. Reviewer: David Black.
2012-08-09
13 Jean Mahoney Request for Telechat review by GENART is assigned to David Black
2012-08-09
13 Jean Mahoney Request for Telechat review by GENART is assigned to David Black
2012-07-31
13 Robert Sparks State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2012-07-30
13 Robert Sparks Placed on agenda for telechat - 2012-08-16
2012-07-30
13 Robert Sparks Ballot has been issued
2012-07-30
13 Robert Sparks [Ballot Position Update] New position, Yes, has been recorded for Robert Sparks
2012-07-30
13 Robert Sparks Created "Approve" ballot
2012-07-30
13 Robert Sparks Ballot writeup was changed
2012-07-30
13 (System) Sub state has been changed to AD Followup from Revised ID Needed
2012-07-30
13 Alan Johnston New version available: draft-ietf-bliss-shared-appearances-13.txt
2012-07-19
12 Robert Sparks The secdir review comments still need a response.
2012-07-19
12 Robert Sparks State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead
2012-07-13
12 Alan Johnston New version available: draft-ietf-bliss-shared-appearances-12.txt
2012-06-28
11 David Black Request for Last Call review by GENART Completed. Reviewer: David Black.
2012-06-28
11 Pearl Liang
IANA has reviewed draft-ietf-bliss-shared-appearances-11 and has the following comments:

IANA has a question about the IANA actions requested in this document.

IANA understands that, upon …
IANA has reviewed draft-ietf-bliss-shared-appearances-11 and has the following comments:

IANA has a question about the IANA actions requested in this document.

IANA understands that, upon approval of this document, there are four
actions which IANA must complete.

First, the authors request registration of "a new event parameter 'shared' for
the Dialog Package." IANA is aware of the Event packages and Event
template-packages registry located in the Session Initiation Protocol (SIP)
Event Types Namespace registry located at:

http://www.iana.org/assignments/sip-events/sip-events.xml

However, IANA is not aware of a SIP Event Parameter registry for Event Packages.

IANA Question --> Could the authors provide a pointer to the registry in which
they would like the new event parameter 'shared' for the Dialog package
registered?

Second, in the Header Field Parameters and Parameter Values subregistry of the
Session Initiation Protocol (SIP) Parameters registry located at:

http://www.iana.org/assignments/sip-parameters

a new parameter for the 'Alert-Info' header will be added as follows:

Predefined
Header Field Parameter Name Values Reference
---------------------- --------------- --------- ---------
Alert-Info appearance No [RFC3261]

Third, in the namespaces registry of the IETF XML registry located at:

http://www.iana.org/assignments/xml-registry/ns.html

a new namespace will be registered as follows:

ID: sa-dialog-info
URI: urn:ietf:params:xml:ns:sa-dialog-info
Registration templace:
Reference: [ RFC-to-be ]

Fourth, in the schemas registry of the IETF XML registry located at:

http://www.iana.org/assignments/xml-registry/schema.html

a new schema will be registered as follows:

ID: sa-dialog-info
URI: urn:ietf:params:xml:schesa:sa-dialog-info
Filename: [ Provided at time of registration ]
Reference: [ RFC-to-be ]

IANA understands that these four actions are the only ones that need to be
completed upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.
2012-06-28
11 Samuel Weiler Request for Last Call review by SECDIR Completed: Ready. Reviewer: Derek Atkins.
2012-06-28
11 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2012-06-22
11 Jean Mahoney Request for Last Call review by GENART is assigned to David Black
2012-06-22
11 Jean Mahoney Request for Last Call review by GENART is assigned to David Black
2012-06-19
11 Samuel Weiler Request for Last Call review by SECDIR is assigned to Derek Atkins
2012-06-19
11 Samuel Weiler Request for Last Call review by SECDIR is assigned to Derek Atkins
2012-06-14
11 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Shared Appearances of a Session Initiation …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)) to Proposed Standard


The IESG has received a request from the Basic Level of Interoperability
for SIP Services WG (bliss) to consider the following document:
- 'Shared Appearances of a Session Initiation Protocol (SIP) Address of
  Record (AOR)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-06-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes the requirements and implementation of a
  group telephony feature commonly known as Bridged Line Appearance
  (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
  Appearance (SCA).  When implemented using the Session Initiation
  Protocol (SIP), it is referred to as shared appearances of an Address
  of Record (AOR) since SIP does not have the concept of lines.  This
  feature is commonly offered in IP Centrex services and IP-PBX
  offerings and is likely to be implemented on SIP IP telephones and
  SIP feature servers used in a business environment.  This feature
  allows several user agents (UAs) to share a common AOR, learn about
  calls placed and received by other UAs in the group, and pick up or
  join calls within the group.  This document discusses use cases,
  lists requirements and defines extensions to implement this feature.
  This specification updates RFC3261 and RFC4235.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-bliss-shared-appearances/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-bliss-shared-appearances/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1157/
  http://datatracker.ietf.org/ipr/1175/



2012-06-14
11 Amy Vezza State changed to In Last Call from Last Call Requested
2012-06-14
11 Robert Sparks Last call was requested
2012-06-14
11 Robert Sparks Ballot approval text was generated
2012-06-14
11 Robert Sparks State changed to Last Call Requested from Publication Requested
2012-06-14
11 Robert Sparks Last call announcement was generated
2012-06-14
11 Robert Sparks Ballot writeup was changed
2012-06-14
11 Robert Sparks Ballot writeup was generated
2012-06-11
11 Amy Vezza State changed to Publication Requested from AD Evaluation::Point Raised - writeup needed
2012-06-11
11 Amy Vezza
Document shepherd write-up for
draft-ietf-bliss-shared-appearances-11

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this …
Document shepherd write-up for
draft-ietf-bliss-shared-appearances-11

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

The document is being requested as a Standard Track RFC.

The document updates RFC3261, RFC4235 which mandates this
specification to be published as a Standard Track RFC.

The intent of the document(Standard Track) is indicated in the title
page header.

(2) 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

Docment describes the requirements and implementations of a group
telephony feature which allows serveral user agents (UAs) to share a
common AoR, learn about calls placed and received by other UAs in the
group, and pick up join calls within the group.

Working Group Summary

There were no points where consensus were rough but extending
pre-existing dialog event package rather than defining a new
event package was seen as a controversial issue for some. Also
to indicate whether a UA supports this specification, use of
option tag was suggested over the use of implicit mechanism
but WG decided to leave it as is as the server (appearance
agent) can gracefully handle the existance of non-compliant
UA.

Document Quality

There are existing implementations as far as I know. Some
vendors have indicated their plan to implement the specification.
Review by Robert Sparks (responsible AD) and Dale Worley
have fine tuned the document by clarifying some unclarified
text along with some contoversial issues mentioned above.

Personnel

Shida Schubert is the document shepherd and Robert Sparks
is the responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have reviewed the document several times and the draft is in good
shape and I believe it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The document has been reviewed extensively on the design team mailing
list, WG mailing list and post WGLC by AD and others, I believe that
sufficient reviews have been performed on the document.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Although this draft registers an XML schema with a new sub-namespace, the XML
schema defined is very simple and no need for expert review was
necessary as far as I am concerned as a document shepherd. The
reviewers who reviewed the document I believe had sufficient knowledge
to review the XML schema defined in the document.

(6) Describe any specific concerns or issues that the Document Shepherd
has 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.

No concern.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

Yes, there is an IPR statement filed against this document but
no discussions took place on the WG mailing list. The IPR statemnts
was filed by Verizon.

(9) 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 a strong consensus by the WG.

(10) 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 publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

There are no ID nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal reviews are required.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) 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 plan for their completion?

Normative reference for RFC3265bis and Alert-Info-URN are both still in
draft status but they both have either finished WGLC or are in the midst
of WGLC. Thus we can assume that these references will be ready by the
time this draft is to be published.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

None.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

They are in the title page, abstract and introduction.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The SIP Event Package Parameter, URN Sub-Namespace Registration,
XML Schema Registration and new SIP header parameter all are consistent
with the body of the document.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

This document does not create new registry.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

The XML code in the document looks good.
2012-06-08
11 Alan Johnston New version available: draft-ietf-bliss-shared-appearances-11.txt
2012-05-15
10 Robert Sparks Need an updated writeup reflecting the time that's passed leading to this update. Please use the new template.
2012-05-15
10 Robert Sparks State changed to AD Evaluation::Point Raised - writeup needed from AD Evaluation::External Party
2012-05-04
10 Alan Johnston New version available: draft-ietf-bliss-shared-appearances-10.txt
2012-01-25
09 (System) This was part of a ballot set with: draft-ietf-mpls-explicit-resource-control-bundle
2012-01-25
09 Robert Sparks
State changed to AD Evaluation::External Party from AD Evaluation::AD Followup.
The shepherd is double-checking the threads leading to this version to be sure each concluded …
State changed to AD Evaluation::External Party from AD Evaluation::AD Followup.
The shepherd is double-checking the threads leading to this version to be sure each concluded and determine if the writeup needs updating
2011-12-29
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-12-29
09 (System) New version available: draft-ietf-bliss-shared-appearances-09.txt
2011-06-14
09 Robert Sparks State changed to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup.
2011-06-03
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-06-03
08 (System) New version available: draft-ietf-bliss-shared-appearances-08.txt
2011-05-16
09 Robert Sparks State changed to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup.
The editor is preparing a revision to deal with list comments
2011-03-14
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-03-14
07 (System) New version available: draft-ietf-bliss-shared-appearances-07.txt
2010-12-06
09 Robert Sparks State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
2010-09-02
09 Robert Sparks State changed to AD Evaluation from Publication Requested by Robert Sparks
2010-08-16
09 Cindy Morgan
>  (1.a)  Who is the Document Shepherd for this document?  Has the
>      Document Shepherd personally reviewed this version of the document
>  …
>  (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?
>
> Shida Schubert is the document shepherd.  I have personally reviewed
> the document, and believe it is ready for publication as an informational RFC.
>
> Document History:
> - draft-johnston-bliss-mla-req-00 was submitted 29th August 2007.
> - draft-johnston-bliss-mla-req-01 was submitted 28th August 2008.
>  * In design team ML, the draft evolved from 01a to 01d
>  * Also there was draft-bliss-ma-00a among design team before it
>    was published as bliss-shared-appearance-00
> - draft-ietf-bliss-shared-appearances-00 was submitted 25th September 2008.
> - draft-ietf-bliss-shared-appearances-01 was submitted 03rd November 2008.
>  * In design team ML, the draft evolved from 01a to 01c before published as 01
> - draft-ietf-bliss-shared-appearances-02 was submitted 09th March 2009.
> - draft-ietf-bliss-shared-appearances-03 was submitted 13th July 2009.
> - draft-ietf-bliss-shared-appearances-04 was submitted 26th October 2009.
> - draft-ietf-bliss-shared-appearances-05 was submitted 07th March 2010.
> - draft-ietf-bliss-shared-appearances-06 was submitted 12th July 2010.
>
>  (1.b)  Has the document had adequate review both from key members of
>      the interested community and others?  Does the Document Shepherd
>      have any concerns about the depth or breadth of the reviews that
>      have been performed?
>
> The document has been discussed on BLISS mailing list and extensively on
> separate mailing list where design team for this draft shared opinions and revised the document. Major PBX vendors as well as some service-providers participated in the discussions. Furthermore we run an expert review before WGLC.
> As a result, the reviews appear to have been reasonably thorough and representative.
>
>  (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 concerns.
>
>  (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 interested community has discussed those issues and has
>      indicated that it still wishes to advance the document, detail
>      those concerns here.
>
> No concerns with the actual contents of the document but there is an
> IPR dislosure with ID #1157/#1175.
>
>  (1.e)  How solid is the consensus of the interested community behind
>      this document?  Does it represent the strong concurrence of a few
>      individuals, with others being silent, or does the interested
>      community as a whole understand and agree with it?
>
> Full consensus exists on this document.
>
>
>  (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?
>
> IDNits are clean except one of the reference which intended status
> should be standard track is currently informational causing the
> error below.
>
> idnits 2.12.04
>
> tmp/draft-ietf-bliss-shared-appearances-06.txt:
>
>  Checking boilerplate required by RFC 5378 and the IETF Trust (see
http://trustee.ietf.org/license-info):
>  ----------------------------------------------------------------------------
>
>    No issues found here.
>
>  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
>  ----------------------------------------------------------------------------
>
>    No issues found here.
>
>  Checking nits according to http://www.ietf.org/id-info/checklist :
>  ----------------------------------------------------------------------------
>
>    No issues found here.
>
>  Miscellaneous warnings:
>  ----------------------------------------------------------------------------
>
>  -- The document date (July 12, 2010) is 7 days in the past.  Is this
>    intentional?
>
>
>  Checking references for intended status: Proposed Standard
>  ----------------------------------------------------------------------------
>
>    (See RFCs 3967 and 4897 for information about using normative references
>    to lower-maturity documents in RFCs)
>
>  ** Downref: Normative reference to an Informational draft:
>    draft-ietf-sipcore-rfc3265bis (ref. 'I-D.ietf-sipcore-rfc3265bis')
>
>
>    Summary: 1 error (**), 0 warnings (==), 1 comment (--).
>
>    Run idnits with the --verbose option for more detailed information about
>    the items above.
>
> --------------------------------------------------------------------------------
>
>
>  (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.
>
> draft-ietf-sipcore-rfc3265bis which is work in progress updates rfc3265 which
> previous version of this draft referenced. As the draft which updates rfc3265
> received consensus in relevant workgroup (SIPCORE) to progress the draft as
> a workgroup item, it is only sensible to reference the updated version of rfc3265.
>
>  (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 suggested a reasonable name for the new registry?  See
>      [I-D.narten-iana-considerations-rfc2434bis].  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?
>
> The IANA Considerations section exists (section 13). 
>
> It requires IANA to register the followings.
>
> 1. SIP Event Package Parameter : shared
> 2. URN Sub-Namespace : sa-dialog-info
> 3. XML Schema (Section 6)
>
>  (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?
>
> XML schema is correctly formatted and shows no error.
>
>  (1.k)  The IESG approval announcement includes a Document
>      Announcement Write-Up.  Please provide such a Document
>      Announcement Writeup?  Recent examples can be found in the
>      "Action" announcements for approved documents.  The approval
>      announcement contains the following sections:
>      Technical Summary
>
> This document summarizes the requirements for a mechanism to enable
> registration of multiple addresses of record within SIP.  The goal
> is to produce a mechanism  suitable for deployment by SIP service
> providers on a large scale in support of small to medium sized PBXs.
>
>      Working Group Summary
>
> The WG/Design team discussed the following issues extensively and more.
> 1. Where appearance agent should reside.
> 2. Method used to reach devices in the group (NOTIFY vs forked INVITE)
> 3. Method used to deliver the appearance number.
>    BFCP/PUBLISH/INVITE
> 4. Timing of line seizures.
> 5. Impact of consultation call.
> 6. Dialog id collision when using RFC4235
> 7. Multiple approach or One approach
> 8. Terminology
> 9. Mechanism used for appearance selection and seizure.
> 10. Appearance conflict
> 11. Compatibility with non shared appearance aware UA
> 12. Call flow correction/addition
> 13. Calls without appearance number
> 14. Documenting alternative approaches (comparing different approaches)
> 15. Behavior on when no appearance agent is present
> 16. Support of Join/Replaces
> 17. Number of appearance numbers available
> 18. Authenticating to the group
> 19. Option-tag to indicate support of shared line appearance
>
>
>      Document Quality
>
> The document has been reviewed by participants within the IETF BLISS WG, including SIP
> service providers as well as representatives from the PBX vendor community.  It has gone
> through pre-WG last call reviews by experts from different area and BLISS WG last call.
>
>      Personnel
>
> Shida Schubert is the document shepherd for this document.
> Robert Spark is the responsible AD.
2010-08-16
09 Cindy Morgan Draft added in state Publication Requested by Cindy Morgan
2010-08-16
09 Cindy Morgan Removed from agenda for telechat by Cindy Morgan
2010-08-16
09 Cindy Morgan [Note]: 'Shida Schubert (shida@ntt-at.com) is the document shepherd.' added by Cindy Morgan
2010-07-12
06 (System) New version available: draft-ietf-bliss-shared-appearances-06.txt
2010-03-07
05 (System) New version available: draft-ietf-bliss-shared-appearances-05.txt
2009-10-26
04 (System) New version available: draft-ietf-bliss-shared-appearances-04.txt
2009-07-16
(System) Posted related IPR disclosure: Verizon Patent and Licensing Inc.'s Statement about IPR related to draft-ietf-bliss-shared-appearances-03
2009-07-13
03 (System) New version available: draft-ietf-bliss-shared-appearances-03.txt
2009-06-19
(System) Posted related IPR disclosure: Verizon Patent and Licensing Inc.'s Statement about IPR related to draft-ietf-bliss-shared-appearances-02
2009-03-09
02 (System) New version available: draft-ietf-bliss-shared-appearances-02.txt
2008-11-03
01 (System) New version available: draft-ietf-bliss-shared-appearances-01.txt
2008-09-25
00 (System) New version available: draft-ietf-bliss-shared-appearances-00.txt