Subject: [salud] Fwd: draft-ietf-salud-alert-info-urns-06 : <private-name> issues

From: Laura Liess <[email-masked]>
Date: Fri, 4 May 2012 14:59:15 +0200

Hi,

I forwarded Alfred's comments, as his original message to salud is
still stuck in the moderation queue.

Kind regards
Laura

---------- Forwarded message ----------
From: Alfred HÎnes <[email-masked]>
Date: 2012/5/4
Subject: draft-ietf-salud-alert-info-urns-06 : <private-name> issues
To: [email-masked]
Cc: [email-masked]

I've been asked to review draft-ietf-salud-alert-info-urns from
a URN perspective.  To keep the message size shorter, I split my
comments into parts by the major concerns I have with the I-D.

My primary concerns regarding the chosen namespace are still
in off-list exploration stage, and so I start in this message with
the second topical area I found needing work: Alert URNs with
<private-name> components and registration requirements.

For easy reference, I quote the ABNF in Section 4 of the I-D:

|          alert-URN       = "urn:alert:" alert-identifier
|          alert-identifier= alert-category ":" alert-indication
|          alert-category  = name
|          alert-indication= name *(":" name)
|          name = standard-name / private-name
|          standard-name = label
|          private-name = label "." label *[ "." label ]
|          label = let-dig [ *let-dig-hyp let-dig ]
|          let-dig-hyp     = let-dig / "-"
|          let-dig         = ALPHA / DIGIT
|          ALPHA           = %x41-5A / %x61-7A   ; A-Z / a-z
|          DIGIT           = %x30-39 ; 0-9
|
|     Throughout this document, "<private-name>" is used as a syntactic
|     variable for any string conformant to the "private-name" ABNF
|     above.

Editorial note:
 The ABNF Standard, RFC 5234, actually *recommends* to enclose
 ABNF rule names in angle brackets ("<...>") when used in prose text.
 So the trailing clause is very redundant -- it carries some allusion
 of doing something extraordinary while actually the recommended
 style is bening used.
 This visual markup is even more important in cases where rule names
 are words in common use, with a broader meanng.
 So I strongly recommend making use of these provisions in RFC 5234
 and in particular also use "<name>" and "<label>" throughout the
 draft text.

The semantical restrictions on <private-name> are spelled out later
in Section 4 ...

|     The alert-indications are hierarchical identifiers.  The set of
|     allowable characters is the same as that for domain names
|     [RFC1123].  Labels are case-insensitive.  Comparisons MUST be
|     case-insensitive.  Registered URNs SHOULD be transmitted as
|     registered.  A new name MUST NOT be registered if it is equal by
|     case-insensitive comparison to an already registered name.

.... and in Section 7.2 of the draft, which says (1st paragraph):

|  The <private-name>" syntax is for proprietary extensions specific to
|  independent organizations.  The "<private-name>" is used in the form
|  of a "reverse FQDN" of the entity that defines the extension,
|  possibly followed by further components.  Standard URNs will never
|  contain a ".", so proprietary extensions need no further marker.
|  This gives a way of assigning unique names without the need for a new
|  registry.  The namespace for each alert category is independent.
|  Those assigning new names must ensure they are in a position to
|  assign names uniquely for the FQDN they choose.

Concern #1 :

  Defining syntax for domain name labels is a hornets' nest.
  Each time someone tries to specify precise rules, there is a storm
  of messages on the IETF main list.  Recently, even attempts started
  in ICANN to update the specification of domain name syntax from
  STD 13 and STD 3 has failed miserably.

Recommendation:

  Defer for <label> to the IDNAbis RFCs (cite RFC 5890) and use
  the terms LDH-label and A-label as defined there.

Editorial hint:
  Formatting the ABNF with columnar alignment of all "=" elements
  would improve the readability.  There's enough horizontal space
  here to do that painlessly.

Concern #2 :

  URNs need to be stable and unique, cannot be de-registered,
  and MUST NOT be re-assigned.
  Bare (fully qualified) domain names do not have these properties;
  domain names are only delegated under commercial rules and subject
  to legal challenges and reassignment.  (I have myself once suffered
  from loss of a domain name, and later gained the reassignment of a
  domain name registered by a 3rd party that collided with a
  registered trade mark owned by my company.)

Recommendation:

  Other protocols in similar circumstances have observed that
  valid fully qualified domain names actually have a precisely
  defined valid owner at each instant in time, and so escaped to
  combining domain names for use in a persistent identifier system
  with a mandatory time stamp.  Since domain name ownership changes
  do not happen frequently and need significant time (due to
  registration / authority propagation delays and the persistence
  of cached DNS data until their TTL expires), it suffices to
  provide such time stamps at date granularity, e.g. with the
  semantics that the {FQDN,date} combination uniquely identifies
  the owner of the FQDN at 00:00 UTC of the specified date

  So if you want to retain the basic scheme, but make the assigned
  identifiers actually suitable for URNs, the reversed domain
  names should be followed by a date, for example:
       com.example.foo-bar-products.2012-05-03
  might become a valid <private-name> component for an Alert URN
  to be registered.

Concern #3 :

  The 2nd paragraph of Section 7.2 contains two examples that
  contradict the specification from the 1st paragraph (quoted above).

                                  vvvv
|   urn:alert:service:call-waiting:abc.org.example.somecompany  and
|   urn:alert:service:call-waiting:def.org.example.somecompany [...]
                                  ^^^^
  The company-specific labels within a <private-name> must not
  precede the reversed domain name.

Recommendation:

  Such <private-name> components could take the form of a subordinate
  domain name label:
                                                         vvvv
   urn:alert:service:call-waiting:org.example.somecompany.abc

  or be specified in a subordinate <name>, as already shown in the
  draft:
                                                         v
   urn:alert:service:call-waiting:org.example.somecompany:abc

Concern #4 :

  The registration rules for <alert-identifier>s, in particular for
  Alert URNs containing a <private-name> component, are not
  specified clearly and unambiguously in the draft.

  At various places, the draft uses vague phrases like
  the last paragraph of Section 7.1:

|  The process for defining new Alert-Info URNs is described in
!  Section 6.1.  Adding new categories and adding alert-indication
!  values other than via the "private" mechanism described in
         ^^^^^^^^^^
!  Section 7.2 is standards action.
              ^^^^^^^^^^^^^^^^^^^

  ... and the last paragraph of Section 7.2:

|  Adding new categories and adding alert-indication values via the
|  "private" mechanism is not a standards action.
                         ^^^^^^^^^^^^^^^^^^^^^^

  Yet, Section 6.1 also doesn't give the specification needed:

|  Alert URN identifiers are identified by labels managed by IANA,
|  according to the processes outlined in [RFC5226] in a new registry
|  called "Alert URN Labels".  Thus, creating a new Alert-Info URN
|  identifier requires IANA action.  The policy for adding a new alert
|  category is 'Standards Action'.  (This document defines the alert
|  categories 'service', 'source', 'priority', 'duration', 'delay' and
|  'locale'. ) The policy for assigning labels to alert-indications and
!  the rules to combine them may differ for each alert-category and MUST
!  be defined by the document describing the corresponding alert
!  category.  [...]

  So, fine for <alert-category>s, but not for <alert-indication>s:
  none of the Sections 6.2.* contains such text.

Recommendation:

  Clearly specify which of the RFC 5226 registration policies shall
  apply to Alert URNs with <private-name> component (or define a
  custom IANA policy if you really feel the need to undergo such
  pain).

  Keep in mind that the persistence and uniqueness requirements
  for URNs need to be satisfied, so maybe "Specification Required"
  might be a candidate policy with minimal requirements.
  Other possibilities would be "Expert Review" -- which includes
  "Specification Required" but requires the IESG appointment of
  designated expert(s) -- or "RFC required".
  But in the former case, when the registration document is not
  readily available at a permanent, stable URI, you would need to
  require IANA to archive the registration document and link to that
  'escrow' copy from the publicly available Alert URN registry on
  the IANA web/ftp site -- but beware that past experience has shown
  that IANA did not like such escrow requirements very much.

  Either add _common_ text to section 6.1 that specifies the IANA
  policy for <alert-indication> assignment in all <alert-category>s
  specified in the draft, or actually do add such text to each
  Section 6.2.*, as promised in the current text of Section 6.1.

Concern #5 :

  The rules in Section 8.1 are not properly thought out, especially
  for the case of <private-name> components.

  In particular, the draft specifies:

!  The implementation is free to ignore any or all parts of the received
!  Alert-Info URNs.  The exact way in which a UA renders a received
|  combination of Alert-Info URNs is left as an implementation issue.
|  However, the implementation MUST comply to following rules:
|
|     a.  Each alert-info URN has precedence over all URNs that follow
|     it, and its interpretation is subordinate to all URNs that precede
|     it.
|
|     b.  If the UA cannot implement the effect of a URN (because it
|     does not recognize the URN or the URN's effect is precluded by
!     preceding URNs), the UA repeatedly removes either
!
!        (1) the final name of the URN, or
!
!        (2) if the final name is a private-name with three or more
!        labels, the final label

  First, I strongly suspect that by removal of a component you
  also mean removal of the separator character that precedes the
  component being removed (a colon or period), but the draft does
  not say so precisely, and the separator characters (by the ABNF)
  are not part of the components being removed per these rules.

  Second, under the rules presently in the draft, removing a <name>
  is not guaranteed to lead to a valid (registered) Alert URN:

  o  according to the ABNF in Section 4, the <alert-indication>
     is not optional, so removal of the last remaining <name> of
     an <alert-indication> (and the separator character ":")
     would not yield a valid Alert URN;
     (btw: the draft provides a "default" <alert-indication> per
     <alert-category>, which is to be assumed if no Alert URN for
     a particular <alert-category> is indicated, but that's not the
     same as an "Alert URN" without an <alert-indication> component;)

  o  as far as I understand, the draft does not require to register
     'truncated' versions of hierarchically subdivided
     <alert-indication>s -- for instance, it can be imagined that
     for a particular <alert-category>, <alert-indication>s
           abc:variant1 ,
           abc:variant2 , and
           abc:variant3
     get registered, but bare
           abc
     is not registered as a valid <alert-indication>.

  Examples:
  -  s6.2.1 does _not_ define "service:recall" (without an additional
     <name> to qualify "service:recall";
  -  s6.2.6 intentionally does _not_ define "locale:country" (without
     an additional <name> in the form of an ISO 3166-1 country code).

  Similarly, there is no requirement in the draft that partially
  truncated forms of "private" Alert URNs be registered and valid.

  Third, regarding sub-rule (2) above: browser implementers are
  struggling with dealing with recognizing "registry type" domains
  for the purpose of defining sensical scope boundary rules for
  HTTP state (cookies), but all these efforts are doomed due to the
  creative forces at work in domain registries.
  Attaching important semantics to the bare number of domain labels
  in an FQDN does not make sense. This will become even more critical
  with ICANN's new sponsored TLD program, where anybody (with enough
  $$$) can start registering an own TLD and sell sub-domains -- or
  use the TLD only company-internally. On the other hand, a URN
  sub-namespace also cannot be made to depend on some volatile list
  of "registry-like" domains in use on the Internet to distinguish
  "cut points" beyond which no organizational affiliation can be
  inferred.

  Further, in the DNS, there can be "empty non-terminals" :
  similarly as shown above for <alert-indication>s, in the DNS,
  subordinate domains/zones can be registered without the need to
  also register/populate "intermediate" domains -- for instance
  there might be the following, regularly delegated domains:
      jp.pacific.world-company.example.com
      kr.pacific.world-company.example.com
      de.emea.world-company.example.com
      it.emea.world-company.example.com
      il.emea.world-company.example.com
      eg.emea.world-company.example.com
  without the need to have delegated the domains:
      pacific.world-company.example.com
      emea.world-company.example.com
  from world-company.example.com -- any domain can contain
  delegations at any level of subordiante labels they seem fit
  to need.
  So by removing the "least significant" domain label, you might
  arrive at a domain name without an owner, which could not be
  used to construct a valid Alert URN for registration.

Recommendations:

  In concert with Concern #2 above, rule b.(2) does not make sense
  any more.  I very strongly recommend to drop it entirely.

  The other corner cases explained above need to be considered and
  properly taken care of in the I-D.

  Given the definition of the Alert URNs in Section 4, specific
  semantics are only defined for actual, registers Alert URNs,
  not for arbitrarily truncated Alert URNs.  Therefore, I believe
  that the sentence,

!  The implementation is free to ignore any or all parts of the received
!  Alert-Info URNs.  [...]

  should perhaps better say:

!  The implementation is free to ignore any or all of the received
!  Alert-Info URNs.  [...]

  If by that revised rule, all Alert URNs for a particular
  <alert-category> are dropped, according to other parts of the
  draft, the recipient has to assume the "default" Alert URN for
  that <alert-category>.  From my point of view, that would just
  be fine and match the requirements.  This seems to be confirmed
  by the additional text above item c. of the draft (not quoted
  above).

  So it eventually looks like the draft could easily drop the entire
  component stripping rules in favor of dropping unknown Alert URNs
  and letting the defaults step in.

  Further, the text in Section 9 seems to indicate that the actual
  intent is to always have a default for each 'dimension' (i.e.
  category) of alert information.  If that's correct, it would
  IMHO be wise to request (in s6.1) that any new registration of an
  <alert-category> also specifies at least one <alert-information>
  to be used with that category and designates one of these as the
  default for that category.

Finally, a few editorial nits:

*  Please clean up dangling hyphens (with spurious space), e.g.:
  "Alert -Info URNs" , "call- waiting:"
        ^                    ^

*  Please fix various typos (some of these recurring):
  -  s/adidition/addition/
  -  s/calback/callback/g
  -  s/rinback/ringback/g
  (and maybe you better use "ring/ringback" without a single
  space on one side of the slash character)

*  In the table in s6.2.3, the 3rd table column is partially
  misaligned by one character position for the 1st table entry row.

*  In s9, I doubt that "requirements in section 7" is the proper
  pointer -- did you mean "... in section 2" ?

*  In s 1.3, 1st para, s8.1, 3rd para, and s9.1, 5th para,
  please use the precise terminology (as anywhere else in the memo):
      s/Alert-Info header/Alert-Info header field/
  Similarly, in the last line of item c. in s8.1, pleas adjust:
      s/header "Priority: urgent"/header field "Priority: urgent"/

*  In s9.2.2, in one instance white space is missing after a dash:
      s/-internal high/- internal high/

*  As a matter of taste: IMO the readability would be improved
  if in Section 9.2.* the presentation were a bit more compact,
  with less vertical white space.
  For instance, you might consider dropping the single blank line
  that precedes all item lines starting with "- "
  (using the  <?rfc subcompact="yes"?>  PI and, where needed,
  <vspace blankLines='1' /> in xml2rfc).
  Ex.:

|  Signal 4
|
|     Meaning: low
|
|     Locations:
!     - source
!     - priority:low

Kind regards,
 Alfred HÎnes.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 May 2012 12:36:52 -0400

Hmm. I had content in this message when I sent it, but it seems to have 
been lost. :-(

I'll send again when I can reconstruct it.

	Sorry,
	Paul

On 5/4/12 11:00 AM, Paul Kyzivat wrote:
>
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Sun, 6 May 2012 20:28:18 -0400

> From: Laura Liess [[email-masked]]
> 

I am (supposed to be) the moderator of the salud mailing list, but I
have received no notification that Alfred's message has been held.
Unfortunately, I don't have any instructions for logging in as
moderator, so I have no other way to check.  I will have to inquire on
Monday.

Dale

---

From: Laura Liess <[email-masked]>
Date: Mon, 7 May 2012 12:46:35 +0200

Alfred,

Thank you for the very elaborate comments and for the recommendation
on how to solve the problems. We will come back to you with proposals
for the new text and, in cases where we need more guidance from you,
with additional questions.

Thanks a lot
Laura