Re: [salud] Interest in implementing draft-ietf-salud-alert-info-urns

DT intends to implement  draft-ietf-salud-alert-info-urns  in its network
after this draft becomes an RFC. DT intends to use the URN
<urn:alert:service:call-waiting> to provide a Call Waiting service to the
customers.

Thank you
Laura

2014-02-19 23:25 GMT+01:00 Dale R. Worley <worley@ariadne.com>om>:

> [as an individual]
>
> Writing the draft of the Proto Writeup, I have found some items that
> should be addressed:
>
> Have any telecom vendors expressed interest in implementing this
> document?  I expect DT is interested, because two of their people have
> been involved from the beginning.  It would help if we knew that more
> vendors were interested, so we could list them in the Proto Writeup.
>
> RFCs 1123 and 5031 are listed as references, but they aren't
> referenced in the text.  I assume that the references should simply be
> deleted.
>
> Because we are including text from RFC 3261, which predates the latest
> IETF Trust arrangements, we may need to update the boilerplate.  The
> simplest update (as far as I can tell) is to change the <rfc> XML
> element to specify a "pre-5378 disclaimer".  I think the syntax is:
>
> <rfc category="std" docName="draft-ietf-salud-alert-info-urns-11"
>      updates="3261" ipr="pre5378Trust200902">
>
> A longer discussion of this issue is:
>
>       -- The document seems to lack a disclaimer for pre-RFC5378 work, but
> may
>          have content which was first submitted before 10 November 2008.
>  If you
>          have contacted all the original authors and they are all willing
> to grant
>          the BCP78 rights to the IETF Trust, then this is fine, and you
> can ignore
>          this comment.  If not, you may need to add the pre-RFC5378
> disclaimer.
>          (See the Legal Provisions document at
>          http://trustee.ietf.org/license-info for more information.)
>
>     (Section 4.2 of this document largely repeats three sentences of
>     section 20.4 of RFC 3261.  There are two possibilities:  Either all
>     eight of the authors have granted these rights, in which case
>     boilerplate "trust200902" can continue to be used, or else we can use
>     boilerplate "pre5378Trust200902".  I know of no place where we can
>     determine whether these rights have been granted, so we should edit
>     the <rfc> element of the XML to read:
>
> I suspect the simplest way to handle the changes to the references and
> to the boilerplate is to put them in a -12 version, but perhaps we can
> leave them as changes to be inserted by the RFC Editor.
>
> Do people have any comments on these?
>
> The full text of my draft of the Proto Writeup follows.  All of the
> places where Christer needs to add his opinions are identified with
> "Christer".
>
> Dale
> ----------------------------------------------------------------------
> Document:  URNs for the Alert-Info Header Field of the Session
>            Initiation Protocol (SIP)
>            draft-ietf-salud-alert-info-urns-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?
>
> Proposed Standard.
>
> The relevant parts of the definition of "Proposed Standard", given in
> RFC 2026 and reiterated in RFC 6410, are:
>
>    A Proposed Standard specification is generally stable, has resolved
>    known design choices, is believed to be well-understood, has received
>    significant community review, and appears to enjoy enough community
>    interest to be considered valuable.
>
>    Usually, neither implementation nor operational experience is
>    required for the designation of a specification as a Proposed
>    Standard.  However, such experience is highly desirable, and will
>    usually represent a strong argument in favor of a Proposed Standard
>    designation.
>
>    A Proposed Standard should have no known technical omissions with
>    respect to the requirements placed upon it.
>
> The working group believes that all known design issues have been
> resolved, and that the design satisfies all of the stated requirements
> (listed in section 5), as well as the standards for SIP and for URN
> namespaces.
>
> This document also updates RFC 3261 by permitting the Alert-Info
> header to appear in all non-100 provisional SIP responses.
>
> A number of telecommunication equipment vendors have expressed
> interest in implementing this document.  [Christer:  Check that.  At
> least DT seems to be interested.]
>
> One particular URN <urn:alert:service:normal> that is defined in this
> document is referenced in draft-ietf-bliss-shared-appearances-15,
> which is in the RFC Editor queue (and is itself Standards Track).
>
> The "Standards Track" status is indicated on 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:
>
>         Relevant content can frequently be found in the abstract
>         and/or introduction of the document. If not, this may be an
>         indication that there are deficiencies in the abstract or
>         introduction.
>
> The Session Initiation Protocol (SIP) supports the capability to
> provide a reference to a specific rendering to be used by the UA when
> the user is alerted.  This is done using the Alert-Info header field.
> However, providing a reference (typically a URL) addresses only a
> specific network resource with specific rendering properties.  This
> document defines a new namespace of URNs for use in Alert-Info header
> fields.  The URNs are defined to describe characteristics of the
> incoming call, characteristics of how the call is being handled at the
> callee, and rendering characteristics of the desired signal.  The URNs
> can be combined to provide complex descriptions of the intended
> signal.  Provisions are made for private extensions that can describe
> additional signal characteristics and additional subcategorization of
> standardized characteristics.  Detailed resolution rules are provided
> to ensure that a renderer provides the best representation that it can
> of the signaler's intention.
>
>         Working Group Summary:
>
>         Was there anything in WG process that is worth noting? For
>         example, was there controversy about particular points or were
>         there decisions where the consensus was particularly rough?
>
> There is solid consensus in the SALUD WG of the value of this work and
> the usefulness of this document.  A large set of requirements has been
> identified to ensure that the proposed URNs can be used successfully
> in converting existing telephone switches to operate using SIP.
>
>         Document Quality:
>
>         Are there existing implementations of the protocol? Have a
>         significant number of vendors indicated their plan to
>         implement the specification? Are there any reviewers that
>         merit special mention as having done a thorough review, e.g.,
>         one that resulted in important changes or a conclusion that
>         the document had no substantive issues? If there was a MIB
>         Doctor, Media Type or other expert review, what was its course
>         (briefly)? In the case of a Media Type review, on what date
>         was the request posted?
>
> A number of telecommunication equipment vendors have expressed
> interest in implementing this document.  [Christer:  Check that.  At
> least DT seems to be interested.]
>
> An important review of the proposed URN namespace was done by Alfred
> Hoenes, which identified a number of deficiencies in the original
> proposal (which have been eliminated).  After revision, the URN
> namespace definition was presented on the urn-nid mailing list, and no
> objections were raised.
>
> Many reviews have been done by the authors, and a final review by the
> Document Shepherd, which convince the WG that there are no substantive
> issues remaining.
>
>         Personnel:
>
>         Who is the Document Shepherd? Who is the Responsible Area
>         Director?
>
> The Document Shepherd is Christer Holmberg. The Responsible Area Director
> is
> Gonzalo Camarillo (who may be replaced by Richard Barnes at the end of
> Gonzalo's term as AD).
>
>         (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.
>
> [This is Christer's contribution.
>
> [Here is the text I used when I reviewed one of the Mediactrl drafts:
>
> [The Document Shepherd (Dale Worley) reviewed the document.  The
> Shepherd identified a number of possible improvements to the document,
> including:  adding definitions to the glossary for the benefit of
> people not familiar with the Media Control effort, discussing the
> additional configuration needs to obtain benefit from "IUMM mode"
> operation, removing from the examples the
> draft-boulton-mmusic-sdp-control-package-attribute extension (which
> was used in the implementation but has not progressed to
> standardization), and clarifying definition of the "gain" parameter.
> All of these issues were completely resolved.]
>
>         (4) Does the document Shepherd have any concerns about the
>         depth or breadth of the reviews that have been performed?
>
> [This is Christer's contribution.
>
> [Here is the text I used when I reviewed one of the Mediactrl drafts:
>
> [The Document Shepherd is satisfied with the review; the document
> should be easily comprehensible to a first-time reader of the relevant
> RFCs, and useful to any implementer of the RFCs.]
>
>         (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.
>
> As this document defines a new URN namespace, that namespace
> definition must be reviewed.  Early in the process, Alfred Hoenes
> provided invaluable feedback that allowed a number of important issues
> to be corrected.  The current version of the namespace definition was
> presented to the urn-nid mailing list, and no objections were made.
>
> Internationalization considerations are listed in section 15.  Since
> these URNs are not directly visible to users, internationalization
> requirements are relatively modest.
>
> The most important consideration is that a part of the
> private-extension syntax includes representation of the domain name of
> the private party defining the extension, so the private-extension
> syntax must allow internationalized domain names.  This is provided
> straightforwardly by allowing A-labels (per RFC 5890) (that is, the
> "xn--..." form output by Punycode) to appear as a "domain name" part
> of a URN.  Since this mechanism refers to the standardized handling of
> internationalized domain names, no special review was given to it.
>
> In addition, the URN system provides a way for a user agent to specify
> that a ring tone or ringback tone be used that is customary in a
> specific country.
>
>         (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.
>
> [This is Christer's contribution.
>
> [Here is the text I used when I reviewed one of the Mediactrl drafts:
>
> [The Document Shepherd has no concerns regarding technical content.
> The English usage may need some cleaning up, as all the authors are
> non-native English speakers, but the Shepherd believes those needs are
> within the capabilities of the RFC Editor.]
>
>         (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, all five authors have confirmed compliance with BCPs 78 and 79.
> The confirmations are archived on the Salud WG mailing list.
>
>         (8) Has an IPR disclosure been filed that references this
>         document? If so, summarize any WG discussion and conclusion
>         regarding the IPR disclosures.
>
> As of 19 Feb 2014, none have been filed referencing this document.
>
>         (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 solid consensus in the SALUD WG of the value of this work and
> this specific document.
>
>         (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.)
>
> [This is Christer's contribution.
>
> [Here is the text I used when I reviewed one of the Mediactrl drafts:
>
> [None that the chairs or Shepherd are aware of.]
>
>         (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.
>
> The significant warnings found by the ID-Nits tool 2.13.00  are:
>
>   Checking nits according to http://www.ietf.org/id-info/checklist :
>
> ----------------------------------------------------------------------------
>
>   -- The draft header indicates that this document updates RFC3261, but the
>      abstract doesn't seem to directly say this.  It does mention RFC3261
>      though, so this could be OK.
>
> (This warning is incorrect, as the Abstract says "This document
> normatively updates RFC 3261 ...".)
>
>   Miscellaneous warnings:
>
> ----------------------------------------------------------------------------
>
>      (Using the creation date from RFC3261, updated by this document, for
>      RFC5378 checks: 2002-02-21)
>
>   -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
>      have content which was first submitted before 10 November 2008.  If
> you
>      have contacted all the original authors and they are all willing to
> grant
>      the BCP78 rights to the IETF Trust, then this is fine, and you can
> ignore
>      this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
>      (See the Legal Provisions document at
>      http://trustee.ietf.org/license-info for more information.)
>
> (Section 4.2 of this document largely repeats three sentences of
> section 20.4 of RFC 3261.  There are two possibilities:  Either all
> eight of the authors have granted these rights, in which case
> boilerplate "trust200902" can continue to be used, or else we can use
> boilerplate "pre5378Trust200902".  I know of no place where we can
> determine whether these rights have been granted, so we should edit
> the <rfc> element of the XML to read:
>
> <rfc category="std" docName="draft-ietf-salud-alert-info-urns-11"
>      updates="3261" ipr="pre5378Trust200902">
> )
>
>   Checking references for intended status: Proposed Standard
>
> ----------------------------------------------------------------------------
>
>      (See RFCs 3967 and 4897 for information about using normative
> references
>      to lower-maturity documents in RFCs)
>
>   == Missing Reference: 'RFCXXXX' is mentioned on line 1071, but not
>      defined
>
> (All instances of 'RFCXXXX' are to be replaced with the RFC number of
> this document.)
>
>   == Unused Reference: 'RFC1123' is defined on line 1854, but no explicit
>      reference was found in the text
>      '[RFC1123]  Braden, R., "Requirements for Internet Hosts -
> Applicatio...'
>
> (This reference should be deleted, as it is not used.)
>
>   == Unused Reference: 'RFC5031' is defined on line 1923, but no explicit
>      reference was found in the text
>      '[RFC5031]  Schulzrinne, H., "A Uniform Resource Name (URN) for
> Emerg...'
>
> (This reference should be deleted, as it is not used.)
>
> (There is an informative reference to
> draft-ietf-bliss-shared-appearances.  We expect the RFC Editor to
> replace the draft name with its RFC number.
> draft-ietf-bliss-shared-appearances is being held in the RFC Editor
> queue solely because it references this document; the two documents
> form a cluster.)
>
>         (12) Describe how the document meets any required formal
>         review criteria, such as the MIB Doctor, media type, and URI
>         type reviews.
>
> An important review of the proposed URN namespace was done by Alfred
> Hoenes, which identified a number of deficiencies in the original
> proposal (which have been eliminated).  After revision, the URN
> namespace definition was presented on the urn-nid mailing list, and no
> objections were raised.
>
>         (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?
>
> All normative references are RFCs.
>
>         (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.
>
> No.
>
>         (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.
>
> This document normatively updates RFC 3261.  RFC 3261 is listed on the
> title page header, and the update is outlined in the Abstract.  The
> specifics of the update are provided in section 4.
>
>         (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).
>
> [This is Christer's contribution.  All of the IANA considerations are
> in section 9.]
>
>         (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.
>
> None of the new IANA registries specified by this document use Expert
> Review for future allocations.
>
>         (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 only section of the document that could be checked by automation
> is the ABNF in section 7.  The ABNF was processed with the IETF ABNF
> validator
> (http://www.apps.ietf.org/content/chris-newmans-abnf-validator), which
> found no problems.
> ----------------------------------------------------------------------
> [EOF]
>
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>