[dnssd] Feedback on draft-ietf-dnssd-requirements-03

[RJ Atkinson <[e-mail]>]

  I apologise for the tardiness of this note.  I have tried 
to organise this note following the sequence (e.g. pages, sections)
of the I-D.  

  Many of my comments are informed from Toronto WG time, numerous
Toronto hallway discussions, and WG list discussions.  I apologise 
that I often don't recall precisely who suggested which idea.  Many 
of the ideas below arose from others and the note below is merely 
my formulation of an idea that originated in someone else's head.

Yours,

Ran Atkinson



Section 1, paragraph 3:
    The 2nd sentence, which begins "Wireless networks...", 
    is misleading at present.  It could cause someone to erroneously 
    believe that most types of wireless links and networks do not 
    support multicasting efficiently. 

    In fact, for most wireless link technologies, the link is 
    natively broadcast (not only at the physical layer,	but 
    also at the link layer) making broadcast/multicast traffic 
    much more efficient than unicast traffic.

    For MANET networking, the IETF has actually already defined
    mechanisms for handling IP multicasting well (e.g. RFC-6621).

    The paragraph could be edited a bit to make it clear that while
    there are wireless links with these issues, there are also many
    other wireless link technologies that work most efficiently with
    multicast/broadcast traffic.  

    So, I propose to edit this paragraph to read instead:

         "mDNS in its present form is also not optimized for 
         network technologies where multicast transmissions are 
         relatively expensive.  For most wireless link technologies,
         multicast and broadcast traffic is much more efficient
         than unicast traffic.  However, some wireless networks,
         for example [IEEE.802.11], have a higher network overhead
         for multicast transmissions.  For IEEE 802.11, this is a
         result of design choices made in the design of that
         MAC layer.  Some wireless mesh networks, for example 6LoWPAN
         [RFC4944] are effectively multi-link subnets [RFC4903] 
         where multicasts must be forwarded by intermediate nodes."

Section 1.2:
     Consistent with Tim Chown's note from 29th July to the dnssd
     mailing list, please define these additional terms and also
     examine the whole I-D to use the newly defined terms to clarify 
     intended meanings:
         - "discoverable service"
         - "reachable service"
         - "usable service"

Section 2.1, paragraph 1:
      It would be helpful if the text more clearly indicated that
      the issues being summarised here are those from the Educause
      petition (as different from being generated within the IETF).
      We should give credit where due, and also differentiate them
      crisply from the Section 3 IETF requirements.

      Proposed Edit:
         s/The following is a summary of the technical issues/
           The following is a summary of their technical issues/

Section 2.1, page 4:
       Another edit of the same type, for the same reason, as the
       above.

       Proposed Edit:
          s/The following is a summary of the technical requirements/
            The following is a summary of their technical requirements/

Section 2.2, paragraph 1:

       As was true in Section 1, this section is unclear and seems to
       imply that non-efficient multicasting is typically true for a
       wireless technology, when actually the opposite is true for most
       wireless technologies.

       I propose to make slight edits to clarify this.

       Proposed Edit:

       s/In IEEE 802.11 networks however,/
         However, unlike many other wireless link technologies, 
         in IEEE 802.11 networks,/


Section 2.2, paragraph 2:
       All this talk of reliability might lead one to believe that
       wired Ethernet, wireless Ethernet, and IP are reliable.  
       However, each is defined to provide an unreliable datagram service.
     
       Proposed new text to be appended to the end of this paragraph:

       "Of course, wired Ethernet, wireless Ethernet [IEEE 802.11],
        and the Internet Protocol (IP) are all defined to provide an
        unreliable datagram service."

Section 3, Use case (C):
        For clarity and consistency, this should be edited:

        s/small business network/Small enterprise network/.

Section 3, Use case (D):
        For clarity and consistency, this should be edited:

        s/Enterprise networks/Large enterprise networks/
        
Section 4, REQ3:
        Minor proposed edit to add clarifying examples:

        s/physical proximity/physical proximity (e.g. building)/

        s/organisational structure/organisational structure
        (e.g. marketing, engineering)/

Section 4, REQ9:
        Optimising DNS-SD for any specific link-layer is objectionable,
        as I noted previously on the dnssd list.  If optimisations
        are useful for particular link types (e.g. 802.11), then
        those optimisations ought to be confined to devices that
        implement 802.11 rather than impacting all deployed link types.

        Proposed Replacement Text:
        "SSD should operate efficiently in all networks."

Section 4, REQ10:
        I don't know what this means and don't understand how
        it is trying to impact the WG's future engineering efforts.

Section 4, Proposed New Requirement:
        I would like to make more explicit that any link-specific
        optimisations ought to be confined to devices that implement
        that type of link.  Accordingly, I propose REQ15 below.

        Proposed New Text:
        "REQ15:  Any link-specific optimisations for DNS-SD should be
         defined in separate specification documents and should be
         applicable only to devices that implement that specific link type."

Section 6.3, paragraph 1:
	I find the first sentence of this paragraph awkward and
        its (very precise) meaning hard to understand.  I think that
        many non-native readers of English will find this confusing.

        Please try to rephrase this, possibly making more clear the
        difference -- in a DNS context -- between "validity" and
        "veracity".  It might be sufficient to add an example or two
        immediately after this first sentence.

Section 6, page 9:
        Based on list discussion, I would suggest adding a new subsection
        immediately after sub-section 6.4 that discusses "Access Control".
        Some rapid candidate text follows; please edit to taste:

        "6.5 Access Control

           Access Control refers to the ability to restrict which users
         are able to use a particular service that might be advertised
         via DNS-SD.  In this case, "use" of a service is different from
         the ability to "discover" or "reach" a service. [Ed: please recall
         to my suggested edit to Section 1.2]

            While access control to an advertised service is outside the 
         scope of DNS-SD, we note that access control today often is
         provided by existing site infrastructure (e.g. router access
         control lists, firewalls) and/or by service-specific mechanisms
         (e.g. user authentication to the service).  For example, many
         networked printers already support access controls via a user-id
         and password.  At least one widely deployed DNS-SD + mDNS 
         implementation supports such access controls for printers.  So
         the reliance on existing service-specific security mechanisms 
         (i.e. outside the scope of DNS-SD) does not create new security 
         considerations."

Section 6.5:
         The existing discussion is good, but the exact same issue arises
         with laptop computers, tablets, and so forth.  Purely as an 
         example, at the Toronto IETF a number of laptops were advertising
         on-link sharing of their music libraries via existing DNS-SD + mDNS.



EOF