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 |