Subject: [TICTOC] TICTOC Survey

From: Stewart Bryant <[email-masked]>
Date: Sun, 15 Jun 2008 20:55:30 +0100

Here are the results from the TICTOC survey.

I merged the responses - (individual responses not attributed
because some were sent to me rather than to the list).

They give a good view of how different sub-groups within
the TICTOC WG view the problem that we need to solve
and how they think we should approach the solution.

We will be using this material during the Interim
next week.

Stewart
This document is the collected responses to the TICTOC
questionnaire on protocol requirements.

http://www.ietf.org/mail-archive/web/tictoc/current/msg00309.html

This was compiles by Stewart Bryant ([email-masked]) 15 June 2008

The following 24 people responded, and we than them
for their time.

Ron Cohen
Dave Oran (as himself, not IAB)
Leonid Goldin
John Eidson
Stuart Venters
Doug Arnold
Antti Pietilainen
Pat Diamond
Alex Tal
Tim Frost
Greg Dowd
Al Morton
Peter Lothberg
Laurent Montini
Emmanuel Sicsik-Par
Jean-Loup Ferrant
Michel Le Pallec
Kurtis Lindqvist
Stefano Ruffini
Silvana Rodrigues
Karen O'Donoghue
Donnald Chislow 
Kuiwen Ji
ZHANGZHAN

==================================================================
==================================================================

The following general remarks were received in addition to the 
asnswers to the formally posed questions.

1) General comments:
   -In many parts of this questionnaire, the terminology refers to
    NTP or 1588; the Tictoc terminology needs to be defined asap.
   -Are any of the questions related to existing patents?
   -This questionnaire has been sent prior to the decision to develop a 
     new protocol

+++++++++++++++++++++++

2) I THINK TICTOC SHOULD NOT INVENT YET ANOTHER TIMING
   PROTOCOL, IT WOULD BE BEST IF TICTOC SELECTS 1588 AS THE BASE
   PROTOCOL, DEFINING RELEVANT PROFILES, TRANSPORT AND EXTENSIONS. TICTOC
   SHOULD DEFINE HOW TIMING SERVICE IS DELIVERED AS A WHOLE, I.E. HOW IT
   IS MANAGED, DEPLOYED AND INTEGRATED WITH THE OVERALL IP/MPLS PROTOCOL
   SUITE.

   TICTOC SHOULD FOCUS ON DELIVERY OF HIGH ACCURACY TIMING FOR SMALL SET
   OF TELECOM AND CELLULAR BACKHAUL APPLICATIONS. TOGETHER WITH ITU-T
   WORK, TICTOC SHOULD FUNCTION AS THE EXPERT GROUP DEFINING THEIR
   PROFILE OF 1588, SIMILAR TO OTHER WORK DONE IN INDUSTRIAL,
   RESIDENTIAL, AUTOMATION ETC INDUSTRIES.

+++++++++++++++++++++++

3) I would hope TICTOC takes account of:

   1. Eventually there will be far more end devices that require 
      precision timing than there will be telecom bridges. In particular 
      enterprise and home devices whether 802.1as or other, industrial, 
      T&M, power, medical who knows.  We see increasing interest in security
      applications where rf location, sensor fusion, etc all depend on 
      being able to distribute time in enterprise and public locations 
      using local Ethernet with time of day accuracy requirements 
      of 10 ns or better. Telecom may deliver this time to enterprise 
      but the local distribution is critical.

   2. Most of these will require low to zero administration to be 
      successful. Self assembly is a big advantage in these applications.

   3. There will be a lot of PHY and other low level silicon out by 
      the end of the year. Most of this appears to be fairly protocol 
      agnostic so it should be able to support 1588, NTP, 802.1as, any 
      others provided the timing packets can be distinguished (at least 
      in the designs I have seen) based on either Ethertype of UDP port. 
      This low level silicon is absolutely necessary for timing in 
      low ns or better.

   4. Time of day and frequency accuracy and precision requirements will 
      only get tighter as time goes on.

   5. In the long haul I don't hold much hope for any scheme that depends 
      on statistics to get rid of network impairments. Timing 
      requirements will get tighter and network traffic heavier all of 
      which work against statistical approaches.

      a.    It is really not necessary to replace all infrastructure-
            only the designed paths that need to support accurate 
            frequency or time of day. There are even ways to retrofit 
            a small number of ports on existing bridges and routers 
            to do this.

       b.   For time of day the really hard problems are:

       i.      Ensuring that the up and down link paths are identical and 
               symmetric. This is both a routing question and making sure 
               bridges and routers are symmetric (as is the case with 
               boundary and transparent clocks and needs to be for any new 
               protocol). This is an issue for telecom but not really in 
               enterprise or local as far as the routing part.

      ii.      Calibrating out asymmetry within the low level silicon- 
               this is in fact the major barrier to reaching ns level time 
               of day at present. It is also a very challenging problem and
               depends on the cooperation of the silicon vendors.

      Personally it appears the major issue in telecom is SyncE or some
      other layer 1 physical layer frequency transfer, and designed vs 
      self assembling timing networks. If you do decide to base 
      TICTOC on 1588 I would suggest that you formalize the use of SyncE 
      as an option for frequency transfer (it is already explicitly permitted 
      in 1588) and then write an 'alternate best master clock algorithm' 
      as already permitted in 1588 with the alternate being a scheme to 
      address telecom, and possibly other, applications where 
      they want to explicitly design the timing topology.

+++++++++++++++++++++++

4) A general consideration is that several questions are heavily 
   depending on the target requirements (sub-microsecond time sync ; 
   100 microsecond time sync , etc.) and arrangment in the network 
   (end-to-end vs. methods with support from the transport network, 
   e.g Boundary clocks in PTP or Stratum Clocks in NTP) .
   Some more thinking on relationship between application 
   requirements and how these would be reflected on the "requirements" 
   for the packet based sync methods will probably be requried.

==================================================================
==================================================================

1) Relevant applications that interest you -

  cellular backhauling               
      * YES  = 16
      * Yes, both cdma with the TOD requirement 
        and just plain T1 transport with only the frequency requirement
      * not directly

  instrumentation / measurement    
     * YES = 7
     * Yes, particularly for media applications with short term accuracy in 
       the 100s of microseconds or better and very low long-term drift. (times2)
       By short term, I would say T ~= 900 seconds.
       By very low long-term, I would say delta-t ~= 0.002 sec and T ~= 86400 
       seconds.
       My highest priority case
       No = 2
       Yes - for test & verification purposes

  industrial                                
     * YES = 3
     * Example? otherwise IEEE1588 is available 
     * No = 3
     * Military

  networking (e.g. instrumenting the net, or making
  it work better/different)             
      * YES = 12
      * Yes, particularly in the ability to timestamp packet 
        generation/arrival/departure to accuracies in the 10's of nanoseconds.
      * As above, but think 1's of microseconds OK
      * Yes, TOD support for Ethernet OAM.
        (If having precision TOD helps making QOS work on the Internet, that would 
        be interesting as well.) 
      * No

  time of day over the general purpose Internet            
      * NO = 2
      * Yes. This is in fact my highest priority usage. Related to this 
        is to have one time standard that can scale to different accuracies 
        in frequency, phase, and ToD over different physical networks, 
        sub-nets, and links without needing different protocols, APIs, etc., 
        and only requiring on-path support in order to increase accuracy 
        to the needs of particular applications.
      * Yes = 8
      * Potentially we can either maintain NTP (distinct protocols) or 
        define same standard we should target the solution to support such 
        application 

  legal time                    
      * NO = 4
      * Yes = 2
      * Potentially if security is required then we can define one standard
        we should target the solution to support such application
      * maybe, according to security considerations which could be taken 
        in account within the group
      * possibly - may become important w.r.t. security concerns

  other
      * Yes, timing of remote telco network elements which are fed by an 
        Ethernet. (Historically a frequency transport application, but 
        these days it's probably a TOD app.)
      * A format to describe a date while communication over the Internet
      
  General comments on the question
      * Note: for each relevant application, we may distinguish different levels
        (e.g. in wireless area).
      * Does that matter? I believe we need a better protocol for all the 
        above applications, and we need to be able to run it over an IP network that 
        we don't know the topology of. What we should do is gather the requirements 
        from those applications in numbers and work on the best possible 
        protocol from that....

+++++++++++++++++++++++

2) Which of the following best describes what you feel
   TICTOC should do ?

    1) define minor extensions to NTPv4
       * NO. ONLY IF REQUIRED FOR 1588/NTP INTEROPERABILITY = 2
       * Probably = 3
       * Yes - using improvements from PTP (1588)
       * Priority 2
       * No = 2
       * YES (this is the most deployed protocol in telecom , any
         application that can work with NTP or backward compatible 
         modifications would certainly take advantage of NTP 
         extensions).
       * this could be done within TICTOC
       * do not favor developing new protocols

    2) define 1588 profiles
       * YES. DEFINE POSSIBLE EXTENSIONS & TRANSPORTS TO 1588 IF REQUIRED.
       * Probably
       * Yes = 4
       * YES, for relevant applications  (don't duplicate what is happening 
         in ITU) (times 2)
       * Yes - to be considered priority 1 = 2
       * Yes in collaboration with other SDOs (ITU-T...)
       * No
       * cooperation with ITU-T is beneficial
       * this should be addressed at TICTOC in conjunction with the work 
         in ITU. Coordinate the work with ITU to make sure we get the 
         best out of the two groups.
       * I think this is ITU-T SG15 charter - perhaps liaison?

    3) define a new TLV-based protocol                                
       * NO = 4
       * definately not
       * Last choise
       * priority 3
       * Yes
       * NO, we really do not need another protocol

   4) define a new protocol with backwards compatibility to NTP
       * NO = 5
       * marginally possibly
       * Yes and TLV encode the new stuff
       * Last priority using improvments from PTP
       * priority 3
       * first analyse performance of 1588/NTP with on-path support
       * NO, we really do not need another protocol

  General comments on the question
       * Between (1) and (4) I have a preference for (1).
         I support (2) as long as it interoperates seamlessly with NTP. 
         My preference is to do (2) in the context of a protocol running 
         over a single NTP "hop" as a way to improve the accuracy of NTP.
       * Find the optimal from all of the above
       * We need a timing transport method which is competitive with GPS.
         Until vanilla packet switches provide on-path support,
         expecting such support seems a pipe dream except in special 
         circumstances. That says we need to run without such support 
         and there's little need to negotiate for it. (Of course this 
         could change if an Ethernet switch chip vendor decided to do something.)

         TICTOC needs to sort out the situation with 2 protocols.
         Making yet another seems like the wrong direction.  
         Aside from negotiating on-path support, I don't see a new 
         feature desire which would justify anything aside from refining 
         what is already there. (Of course one example could change that.)
      *  As the only existing precision time standard, I see 1588 as the 
         right starting point. IEEE 802.1AS did that selection too instead 
         of defining a new method or trying to tweak NTP. (Times 2)

      * NEW  5) define what is needed to make time distribution over the network
        work properly, 
        e.g. discovery,
            routing protocol extensions, 
            protection, 
            redundancy architectures, 
            QoS techniques that don't destroy time accuracy, etc (times 2)
      * YES, but we shouldn't be developing new protocols. We should 
        be working out how to use the ones we already have. (times 2)
        (coppied here)
      * I can live with any of these, but with a preference for NTPv4 
        compatibility.
      * Better to leverage what already exists. However I would not like 
        defining TICTOC protocol by twisting another protocol for the 
        only reason it exists.
      * IEEE1588 (or even NTP) profile would be P1 for frequency only,
        but then it can be done as an ITU-T profile based on PTP profile 
        - a PTP profile description (IEEE1588 parameters only) would 
        not be sufficient for telecom.
        However for time, I'd like first assessing the requirements (not only
        from apps perspective only but from architecture viewpoint) against PTP
        protocol and not try making use of shoehorn to define a PTP profile(s)
        for telecom time delivery. If PTP and possibly PTP improvement can be
        done without breaking PTP, then 1588 profile can become suitable. 
        At least options 4 & 3 would demand defining properly the telecom
        requirements (not apps reqts which are rather known).
      * Note that "sub-microsecond applications" will involve 
        special studies for instance related to IEEE1588 BC/TC  
        or similar NTP functions.
      * First 2 (1588), then 1 (NTP) - but I understand Kurt's comment... 
        there are two possible approaches... 
        1. The clean slate approach
           Define the requirements then engineer the solution. 
           This is the perfect world right answer, but I'm not sure we are in a
           perfect world. 
        2. Leverage existing solutions
           Identify incremental improvements and additions...
           Given the marketplace reality and the capabilities of the group,
           this may be the way we need to go. 
        I don't think we have enough consensus in the IETF to take the first
        approach.
      * Re: 1, 3, 4 you need to know what you can expect to get from the current 
        protocols 1588, NTP, including h/w enhancemen

+++++++++++++++++++++

3)  What type of time do we need to distribute (multiple
    answers are possible) ?

    UTC?  Local time ?   TAI ?  arbitrary phase ?  others ?       
       * TAI - WITH INFORMATION REQUIRED TO CONVERT TO UTC - SEE 1588
       * TAI = 2
       * I think UTC and TAI are mandatory. Others can/should be accommodated if 
         it does not unduly complicate the protocol or the overall 
         system. (times 2)
       * The kind I get from GPS, sometimes just the frequency.
         Either NTP or 1588 format is fine.
         If GPS leaps, we need to follow suite.
       * All of the above
       * UTC and Local time
       * ANY or ALL depending on application (times2)
       * We need to distribute any Time or Phase, and identify what the source
         is to be a general protocol.
         To do time over the Internet we need UTC(k)
       * UTC yes, Local time needs a definition (Assuming independent
         timescale and epoch, yes), TAI yes, arbitary phase needs
         definition - assuming PPS - yes. 
       * UTC and local time. I don't see the need for arbitrary phase, 
         but see a risk in terms of protocol complexity
       * UTC? Yes     Local time ?   TAI ?  arbitrary phase ? May be   others ?
       * See draft-kurtis-tictoc-itp-req-00.txt section 9, 9.1, 10
       * It depends on the application
       * Unless we redefine NTP or PTP this is already determined.
         Additionally, I'm not sure that it matters that much as long as
         the appropriate conversion algorithms are implemented. 
         It should be either TAI or UTC with a perfect world preference for TAI.
       * suggest define a minimum set to include UTC, others can be 
         derived or optional

+++++++++++++++++++++

4) What is the best format ?                                                 
       * TAI
       * No opinion = 3
       * Depends on application, but at least TAI. (times 2)
       * Depends on application = 3
       * Decide later
       * The Time format should be flexibile.
         It shall be noted that some application require continuous 
         time scale (this means that leap second can be a problem: 
         either easily accessible information on the leap seconds 
         number or a protocol without leap seconds ) .
       * It depends on the application
       * Again... not an issue unless we are redefining one of the 
         existing protocols. If we are, I would defer to the hardware 
         engineers to answer this one. 
       * TBD

+++++++++++++++++++++

5) Please address how other needed types of time are to be   
   derived (e.g. local time from UTC, leap-seconds, etc)

      * STICK TO WHATEVER AGREED UPON IN 1588. DON"T SEE REASON TO REINVENT
      * Although I don't have a strong opinion here  I would not be 
        disappointed if TICTOC decided to punt the local time issue entirely. 
        since leap-seconds are a global variable, I don't see any technical
        barrier to handling this in the protocol as the means to represent 
        both TAI and UTC. (times 2)
      * In my opinion the format should allow maximum application like UTC
        with leap seconds. The rest will be as a subset of it.
      * TAI with UTC offset information in another field (default for PTP)
        Slaves or clients should make the UTC correction, and if needed, local
        time correction
      * The question is TAI/GNSS or UTC timescales. (with or without
        leap-second jumps)  Local time rules/notification is not a
        time-protocol problem. (how about DHCP...)
      * No opinion
      * The server MUST be capable of setting a flag telling 
        the client that there is more information for the client
        about an event.  The client will then start an exchange 
        to follow up what the event is.
      * My applications require UTC for policy reasons and monotonicity
        for application requirements. Maybe someday UTC will be monotonic. 
      * TBD

+++++++++++++++++++++

6) Should a separate "frequency-only" service be defined ?    
      * NO. A PROFILE FOR SUCH APPLICATIONS MAY BE NEEDED, BUT I"M NOT SURE. 
        A NEW PROTOCOL IS NOT NEEDED.
      * No Opinion = 2
      * This is worth discussing as such ideas were proposed already in ITU
      * If would be useful if a server could say it knows the frequency, 
        but not the time. This doesn't seem like a separate service, just a 
        status of the existing ones.
      * No
      * Frequency sync can typically work out well without intermediate 
        node support. Time sync at mobile network precision requires 
        intermediate node support in almost all cases. Therefore, one needs 
        to consider the two problems. (Times 2)
      * Yes = 3
      * Yes if required by the application (times2)
      * Not the most critical concern. This can be handled by a 
        TP profile at ITU-T. However if specific protocol requirements 
        as such as O&M, security are listed for frequency, it would be 
        worth working on unique solution.
      *
      * Don't see the need for a frequency-only service - as far as a 
        frequency service, along with time, can be supported.
      * As "Frequency only service" addresses the main needs of the 
        mobile market: yes,  but emerging wireless technologies are TDD 
        oriented with stringent time requirements
      * Do you mean a separate protocol? If so no.
      * The main scope should be time and phase . 
        For the relevant applications, Frequency can either be 
        distibuted via non-packet based methods, or in case packet based 
        methods are used, no specific work on the protocol 
        should be required.
      * I don't currently have a need for this in the applications I 
        represent, but I understand that others do. 
      * need to define the user space. Such an option will work for 
        current needs, but need to address time delivery as well

+++++++++++++++++++++

7)  What about a special "time when frequency is locked" service ?    
      * NO. A PROFILE FOR WORKING WITH SYNC-ETH AND THE LIKE IS NEEDED FOR 
        SURE. EXTENSION TO THE 1588 PROTOCOL / PROFILE MAY BE CONSIDERED.
      * No Opinion = 2
      * If a client has frequency, but the time is coming over a poor packet path,
         then sure, it can get the "time when frequency is locked".  Again, this 
         doesn't seem like a special service.
      * Don't understand = 2
      * Yes = 3
      * Depending on the frequency stability target when frequency locked, 
        but basically, yes.
      * Should be In the Profiling space (with syntonization support)
      * not clear what you are trying to do with this?

+++++++++++++++++++++

8)  Should we divide the application space into categories
    from stringent to undemanding ?
      * WITHIN A SOLUTION SCOPE. SEE WORK DONE IN 802.1AS: WITHIN THE HOME,
        LIST ALL  MULTIMEDIA APPLICATION REQUIREMENTS AND VERIFY
        PROFILE/SOLUTION IS APPLICABLE. SIMILARLY, REQUIREMENTS SHOULD BE
        SPECIFIED FOR TELECOM SYNC AND SEPARATE REQUIREMENTS FOR CELLULAR
        BACKHAUL, ETC.
      * No strong opinion, but I am somewhat queasy about binning because 
        it causes arguments at the edges of the bins and may lead to 
        interoperability problems, especially if derivative standards
        choose poorly or in an incompatible fashion. We've seen this in 
        other domains, e.g. IEEE 802.1 QoS classes versus IETF PHBs.
      * So, looking at the continuum of well-formed numerical requirements
        from many applications, if the fairly clear categories emerge, then
        the categorization makes sense.  If not, then not.
      * I personally pursue max. 200-300 ns accuracy loss over the 
        network (for WiMAX). If others tell their requirements, then 
        we would see the spread of requirements.
      * Yes = 2
      * YES, ITU is also taking this approach, see attached slide from 
        Miami Q13 meeting (WD19) (times 2)
      * Definition of consumer profiles may be interesting but may drive to too
        many options.
        If too many options, this could increase operation cost.
        If targetting only most stringent category support for all apps, this
        could increase CapEx.
        It may be up to operator to choose either supporting multiple categories
        or a subset and using the most stringent category for different (not
        all) apps.
      * Yes, but limit to 3 categories (at least at this step of the 
        analysis) to avoid too long discussions related to the criticity of 
        some requirements
      * Yes, but this is not in the Tictoc charter which is focusing on 
        highly accurate time and frequency distribution
      * Good to know the user space/needs, but what is the overall 
        objective?

+++++++++++++++++++++

9) If so, how may categories and where are the dividing lines ?
   Please consider
     accuracy
     resolution
     aquisition time
     Jitter
     Wander

      * THIS WORK SHOULD BE DONE WITH THE RELEVANT STANDARD BODIES RESPONSIBLE
        FOR APPLICATION SPACE. E.G. WITH ITU ON TELECOM INFRASTRUCTURE ETC.
        THE PROBLEM IS USUALLY IN APPLICATION SPACES WHERE TRADE-OFF BETWEEN
        PERFORMANCE AND COST IS ALLOWED.
      * I'm not sure that Jitter is needed as a part of a protocol spec 
        since it can be filtered out outside the spec. I think accuracy and 
        resolution are covered in closeness to GPS and the wander limit.
        If an application needs wander from an unknown but fixed offset to GPS, 
        then that seems like frequency which is also covered.
      * We should divide into time accuracy/frequency stability categories
      * Limit discussion about these topics if possible. Accuracy and 
        resolution are included in existing time protocols, ITU-T Q13/SG15 
        covers jitter and wander specs. (Times 2)
      * No opinion - Should category include other functions (e.g., 
        security, management)?
      * Possibly : network topology/characteristics sensitivity (althought
         hardly measurable...)
      * Definitely different considerations apply deopending on the 
        application and related requirements. The submicrosecond 
        time-phase and 10-100 microseconds time-phase type of requirements 
        shall be the focus.
      * Please note that some of these are covered by ITU work.
      * if the group is serious about delivering quality time then it
        "has" to include all salient parameters/metrics
      * accuracy is better.because in many use case,the accuracy is 
        the most important guideline

+++++++++++++++++++++

 10)  Are there other characteristics that would cause us to
      consider the creation of an unique timing class?
      * I think the metrics to define an application class are:
	Does it need TOD? If so, how close to GPS does it need to stay. 
        (maybe in RMS and peak seconds)
        Does it need frequency? If so, what is the wander limit. 
        (maybe in MTIE and TDEV)
        What acquisition time is required.  (maybe max time in seconds)>
      * I don't fully understand the question.
      * All of the above is algorithm dependent, you can send packets, 
        and you can have "out-of-packet" time distribution ala 1588, but how
        the packet looks, is kindof not the issue, as long as it carries 
        enough information at a rate needed for the chosen algorithm. (not sure
        if this is in the right place in the file - SB)
      * Yes, However algorithm shall be considered along with metrics.
      * no opinion
      * It may or may not be necessary depending on the application
      * I do not know
      * the kind of timing source.or the routing map.

+++++++++++++++++++++

11) It is proposed to separate protocols (standards-track)
    from algorithms (informational). Do you agree ?         
      * NOT NECESSARILY. FOR SUCCESSFUL ADOPTION OF THE SOLUTION AN 
        ALGORITHM THAT ANSWERS THE REQUIREMENTS MUST BE SPECIFIED. OTHERWISE 
        IT REMAINS A WOODOO. THE APPROACH TAKEN BY 802.1AS WHERE THE 
        ALGORITHM IS FULLY SPECIFIED IS THE BEST.

        THE ALGORITHM SPECIFICATION DOES NOT HAVE TO DELAY ALL WORK. DEFINING
        HOW 1588 RUNS OVER MPLS, ETC. CAN BE ADVANCED REGARDLESS.

      * Agree, with the proviso that it is OK to have things in the 
        standards track protocol documents which put cnstraints on the 
        classes of algorithms and their externally-measurable properties. (times 2)
      * Yes = 7
      * In the Telco space, to make a stable chain for timing transfer, 
        it's necessary/customary to constrain the PLL response at each link 
        in the chain.  This seems likely with packet timing as well, and so 
        should be part of the protocol.  Where the current spec goes way 
        past this, it could be a separate informational RFC or just a 
        'may' in the standards-track one.
      * Any attempt to deviate from this proposal will never succeed!
      * Agree. I propose to leave algorithms out of scope altogether. 
        Of course, one has to have algorithms in mind to decide upon 
        packet rates, etc. (Times 2)
      * YES, but we shouldn't be developing new protocols. We should 
        be working out how to use the ones we already have. (times 2)
      * If you want to do "time of day" over the internet, the algorithm
        has to be standards track, it can still be separate from the protocol.

        There are only two ways we can improve what's already avaliable;
        - Better algorithms
        - Media dependent HW support
      * Why not, particularly if algorithms are already  developed 
        (NTPV4 algorithms)
      * Yes. Not sure why algorithms would have to be informational though.
      * Yes,we should work with the current protocols available and the 
        algorithm should be out of scope.
      * No,I don't agree

12) It is proposed that TICTOC exploit on-path support when
    available, but be able to function (with reduced
    performance) when it is not. Do you agree ?

      * YES. HOWEVER TO ACHIEVE PERFORMANCE ASSURANCE ON-PATH SUPPORT MAY 
        NEED TO BE GUARANTEED.
      * Yes, except I would put it the other way around. "TICTOC 
        must be a fully functional internet timing protocol without 
        requiring on-path support for any of its functions, but may 
        exploit on-path support when available for improved accuracy and 
        performance." There is a subtle mind-set difference between 
        the two formulations which I think matters. (times 2)
      * Yes = 7
      *  On-path support is-great/should-be-used if you can get it,
         but so far, it doesn't seem to be getting much market traction 
         (see above).
         Unfortunately, some applications won't work on some packet paths 
         without it.  I think we need to figure out how to support the 
         target apps with as little on-path support as possible,
         but provide a way to use it if it is available.

         If an application requires on-path support, but TICTOC doesn't 
         have it, then TICTOC (as always) should deliver the best time it 
         can but also provide the application with an approiate status.  
         Whether the app decides to continue to function or give up under 
         these circumstances should be outside the TICTOC scope.

         Almost more importantly, we need to document when and where it is 
         required for the target apps.

      * If the router companies are committed to support this, then 
        TICTOC should take advantage, otherwise no.
      * That's should be pursued (and 1588 does it). (Times 2)
      * The Internet is based on IP, ip runs over any meadia that has a
        mapping for how to transfer IP packets. The timing protocol has to
        work over the Internet.
      * YES
        On-path support shall not be mandatory.
        On-path support should be used to improve the performance.
        On-path support functions shall be defined distinctively.
        On-path support improvement shall be bounded (min) and measurable.
        Client should be able to know (at setup or later) if any on-path support
        is available.
      * Yes, with on-path support characteristics being defined separately
        and well characterized : on-path support characteristics and on-path 
        measured improvements should be correlated through possible on-path 
        support improvements measurements.
      *  On path support  has to be clarified as well but be able to function 
         (with reduced performance) when it is not. Do you agree ?
      *  No. Tictoc  focuses on highly accurate timing  Thus reduced 
         performance  should not be acceptable in case of problem inside 
         the on-path support (ex mobile networks).
         Alternately, it might be possible to define classes of performance.
      * On-path support definition should be better clarified ; it 
        currently involves too much different concepts. The general 
        understanding is that for some application/requirement 
        (e.g. sub-microseconds phase-time sync), some "on path support " 
        is required (excluding very special cases).
     *  Yes, I think there are some issues with Transparent clock, 
        so TICTOC may work on that.
     * NO I would not support what I'd refer to as another "best-effort" 
       time service. Again if serious about timekeeping then I think 
       you revert to a more deterministic model for distribution

+++++++++++++++++++++

13) It is proposed that TICTOC exploit special hardware in
    server and clients, but be able to function (with
    reduced performance) when it is not.  Do you agree ?
      * YES = 11
      * Yes, with the same sense reversal above: "TICTOC must be a fully 
        functional internet timing protocol without requiring hardware 
        support in servers and /or clients for any of its functions, but 
        may exploit such hardware when available for improved accuracy 
        and performance." (times 2)
      * I'm not sure I understand why if someone implements a part of an 
        endpoint in software of special hardware should affect the spec.  
        It seems like what is important is what the implementation does, 
        not how it does it.
      * It has to work over the Internet, over any existing or new media. 
        If you have special requirements, it';s a media specific optimization
        with or without hardware support.
        TICTOC should have the "interface/api" to allow such support for
        applications that require it.
      * I'm not sure this is relevant. This should be an 
        implementation decision. However a client may want to know if 
        server (and intermediate nodes) have specific hardware assistance.
        So it shall work without special HW, the impact being the performance
        and hence the adequation of the implementation wrt the category.
        However if the definition of the hardware has an impact on the protocol
        (not the reverse) thus I would revise my opinion.
      * OK, but the protocol should only specify performances related to 
        subsystems ; the way to reach these performances is more implementation
        related. 
      * Unclear.  Special hardware in server/client has been understood 
        as "source of timing" and applications requirements/specifications. 
        Thus,  this topic should be  an input of Tictoc
      * Server and client contribution to the overall perfomance is 
        probably most significant when the network provides some "on path 
        support" and the target is sub-microsend phase-time .
        In the end to end solutions (packets carried trasparently over 
        the packet network) , the contribution from the server is 
        less significant (packet jitter in the network is the major 
        contributor to the total "noise").
        In any case the Client functions are fundamental (e.g. 
        oscillator quality) .
      * NO - for similar reasons to above - not clear what 
        "when it is not" refers to? Use of the special h/w?

+++++++++++++++++++++
14) What scalability constraints do you envisage ?

  14a) Number of clients per server -
      * POSSIBLE IN SOME ENVIRONMENTS. CAN BE SOLVED USING TCS/BCS.
      * No Opinion
      * Perhaps hundreds to a thousand at the edge.
      * A few thousand = 3
      * 1000s (times 2)
      * ~ 1000
      * This is a traffic engineering problem, how much traffic per client
        and how many clients.
        I envision the protocol to allow the servers (or peers) to flow
        control, admission control, resource control based on some policy
        implemented by the user
      * from multiple 10's to 1000's
      * Not sure I understand what you mean by scalability here ?
      * Total number as per general Internet today
      * mobile: 100s-1000s, wireline: probably <100?
      * 100 - 1000

  14b) Number of servers on network -                                  
      * NOT IN THE TIMING PROTOCOL SENSE.
      * No Opinion = 2
      * Perhaps only 2 at the edge, use more if they are available.
      * A few per mobile network (Times 2) 
      * A ecconomic's problem
      * Not sure this is relevant except if considered from a specific 
        angle, e.g., from client viewpoint (how many servers the client 
        can see/handle), i.e., if there is a relationship with a service
      * depends on network topology
      * this will differ for each carrier depending on their network 
        engineering philosophy, i.e., flatter vs. more hierarchical

  14c) Number of hops / maximum propagation time -            
      * NO. THE AVAILABILITY OF GPS IN MOST ENVIRONMENT ENSURES THE NUMBER 
        OF HOPS IS NOT TOO LARGE.
      * I'm not sure this is a first-order scaling property. It has two 
        visible effects (possibly more)
        a) settling time
        b) transitive trust weak-link problems.
        I'd like to see more discussion on these. (times 2)
      * Perhaps a few (3-6) switches, RTT is often bigger than accuracy 
        requirement.
      * All of the above
      * Propagation time depends on the speed of light and required 
        service etc. Let's say 50 ms max, < 5 ms preferred. (Times 2)
      * < 10 - don't know (times 2)
      * Any/Any
      * Description/characterization of the hops functions & performance
        is critical; no opinion on propagation time. Max hops numbers will 
        surelly depend on the category (apps reqt) and on hops capabilities.
      * application related requirement. No opinion
      * this will be dictated by the performance metrics the applications 
        require
      * 10 hops
      * Yes (only said yes to this)

  General comments on the question
      * Time distribution and Frequency distribution have to be 
        considered separately  for scalability issues.
      * Architectural aspects shall be investigated . These may depends
        on several factors  and on the application.
      * It will depend on the application, for instance for 
        femtobasestations the number I have heard is 1000s of slaves, 
        and it is different for other applications.
      * this will depend on application

+++++++++++++++++++++

15) Is it acceptable for the time server to save state
    of clients ?
      * YES = 5
      * I think this question is not well formulated. Use of per-client 
        state is a tricky protocol design issue and needs to be traded off 
        against all sorts of other properties. I'd rather (NOT???) go down the 
        design path having decided this too soon. (times 2)
      * Would rather not
      * The desire to do this is going to be application specific.  
        We need to be flexible.
      * No
      * YES, make the servers do the heavy lifting where possible.
        Also useful for OAM and fault monitoring. (times 2)
      * No opinion for server but would prefer not. To be considered 
        separately but not acceptable for (some form of) on-path support 
        (when applicable)
      * If related to on-path support functions, should be rather implemented 
        at the client level
      * Many applications - many answers (note this is NTP terminology)
      * I don't think it can be assumed they could (DoS).
      * yes -  may need for OA&M

+++++++++++++++++++++

16)  How much memory and for how long ? 
      * QUESTION UNCLEAR.
      * No opinion (times 2)
      * Don't know = 2
      * State might be required by authenthication shemes, again, 
        it should be a resource management issue controled by the user, 
        supported by the protocol. We are not building products.
      * I think it is easier to define scalable solutions if 
        you don't do this. As for how much memory and for how long, 
        I defer to chip designers.

+++++++++++++++++++++

17)  Which modes are required ?

  17a) broadcast
       * NO = 3
       * I see no need for broadcast given all interesting networks 
         support multicast over a broadcast infrastructure. (times 2)
       * Yes
  17b) multicast
       * PROBABLY YES. DEPENDS ON THE PROFILE.
       * Yes = 10
       * maybe
       * Probably Yes, but utilization to be clearly bounded (e.g. link only)
       * In certain cases
       * Yes (only said yes to this)
  17c) unicast
       * PROBABLY YES. DEPENDS ON THE PROFILE
       * Yes = 13
  17d)anycast
      * DON'T KNOW
      * Yes = 4
      * what do we mean here
      * Probably yes

  General comments on the question
      * Probably last one. However another topic needs to be discussed is
        delivery over different physical interfaces. For example, how MLPPP
        would affect the timing when it runs over multiple E1s? How SONET/SDH
        carrier affects timing distribution? And so on
      * For highly accurate time distribution, unicast mode should be the 
        first to consider. Frequency distribution modes are  more questionable 
        considering the expected level of performance
      * As in client/server communication? Well, unicast seems straightforward 
        and anycast is normally simply leaving the server selection to the 
        routing system. I guess there could be applications in 
        multicast for this, but I am not sure
      * Modes to be investigated
      * This question seems a bit premature to me. I'm not sure how to answer 
        it.
      * I have to believe "unicast" is the mode of choice for performance 
        stability? - need to define why we need the others and what the 
        attendant performance expectations would be? 

+++++++++++++++++++++

18)  We need to support transport over (multiple answers
     are possible) -

  TCP/IP
      * DON"T SEE WHY IT NEEDED
      * Seems awfully tricky - I'd give this low priority (times 2)
      * No, the extra services it provides don't seem helpful to the problem 
        at hand
      * Yes
      * not for the freq/time transfer, possibly for O&M
      * possibly
      * why not, what is the main interest? Messages are sent periodically
      * maybe
  UDP/IP
      * YES = 12
      * For backward compatibility. does not need to be a "first class citizen"
        (times 2)
      * For IPv4 and IPv6
      * Especially over Ethernet (times 2)
      * Maybe - P2
      * Posibly
  RTP/UDP/IP
      * DON"T SEE WHY IT NEEDED
      * Yes = 7
      * No, we have enough time stamps already
      * Possibly (times 2)
      * No, NTP is already addressed = 2
  DCCP/IP
      * DON"T SEE WHY IT NEEDED
      * Yes = 5
  Ethernet
      * YES = 5
      * No (as long as you mean without IP) = 2
      * Probably for 1588
      * Yes (1GE)
      * YES, but this isn't IETF domain (times 2)
      * is that under IETF scope? yes if this is IPoEth (obviously)
      * Not sure
      * Not in TICTOC WG
  MPLS 
      * YES = 9
      * No (as long as you mean without IP). = 2
      * No
      * UDP/IP/(Ethernet) over MPLS (times 2)
      * maybe - P2; need to consider the T/S function
  other

  General comments on the question
      * In short - more is less
      * Typical stacks expected for leased lines  multiple domains with 
        multiple protocols X The stack could grow by two MPLS headers and 
        decrease back before reaching destination. VLAN tags could come and 
        go on the way. (Times 2)
      * Yes
      * ***** IP *****
      * UDP over IP seems the most reasonable.
      * IP , MPLS, Ethernet, UDP/IP , RTP/UDP/IP  are the main 
        cases. Others may apply.
      * One of the first four then MPLS
      * All of them

+++++++++++++++++++++

19) multiple domains with multiple protocols       
      * GATEWAY BETWEEN TELECOM/802.1AS PROFILES AND SIMILAR IS NEEDED
      * Define "domain" in the context of TICTOC. Can't answer until you do.
      * multiple domains: yes (i.e. crossing distinct operators and/or 
        time domain),  multiple protocols: i.e. time protocol IWF?
      * Yes = 3
      * naaa

+++++++++++++++++++++

20) How should client time be updated by TICTOC ?

    by setting time to best estimate
    by setting time but maintaining monotonicity
    by slewing frequency

      * It really depends on application. Any approach can be used.
      * For the time delivered by TICTOC to the application, I'm 
        not sure why a protocol spec should care.
        For the time passed from node to node inside TICTOC, best estimate.
      * This needs to be application specific, the standard should be flexible.
      * Implementation specific, i.e. out of scope (times 2)
      * Not sure I understand the defitions above ...
      * TBD (times2)
      * By any of those depending on client configuration (times 2)
      * Now we are confuced again, you have to decide if your client is to
        recover time or frequency. 
        If we recover time we need to generate a frequency that we use to
        control the phase.
      * No opinion; may depends on application or category
      * By slewing frequency - yes
        Choice of method depends on application requirements
      * By setting time to best estimate - Not enough deterministic
        By setting time but maintaining monotonicity - Yes, but depends on 
        level of  time correction land clock update rate
        By slewing frequency: may depend on On-path Support relationship
      * This will depend on applications and related requireemnts 
        during failures in the sync distribution (e.g. "Time Holdover"
        aspects need some investigation)
      * It depends on the application and implementation of the client.
      * Wouldn't this be part of the local clock algorithm. 
        How the correction gets applied may not be a protocol or
        interoperability issue. For my applications, I believe
        the answer is setting time if the error is greater than
        a TBD threshold and slewing frequency when the error is
        less than that threshold.
      * TBD - likely a combination 
      * by setting time to best estimate and by slewing frequency

+++++++++++++++++++++

21)  How are multiple sources of clock to be handled ?

      Best clock selected by rating in packet
      Best clock determined by calculation
      combination of information from multiple clocks
      completely distributed method

      * No opinion = 2
      * combination of information from multiple clocks
      * For the time delivered by TICTOC to the application, I'm not 
        sure why a protocol spec should care.
        For the time passed from node to node inside TICTOC, best estimate.
      * This needs to be application specific, the standard should be flexible.
      * Use best master clock algorithm or select by management. (times 2)
      * TBD (times 2)
      * This is Algorithm specific, and I guess each special application
        will have it's set of algorithms, in addition to the standardized
        time of day algorithm
      * No opinion; may depends on application or category
      * Best clock selected by rating in packet : yes
        Best clock determined by calculation : yes, but accuracy ?
        combination of information from multiple clocks, including weighting 
        of different "best clocks" time according to clock rating
        completely distributed method
      * Best clock selected by rating in packet - metric? Some are under definition in ITU
        combination of information from multiple clocks - No
      * Best clock selected by rating in packet, but if you have that 
        I am not sure what the difference between that and your 
        other alternatives?
      * To be investigated
      * It depends on the application. For instance Industrial Automation 
        will use best clock algorithm, but other applications may use a 
        different method.
      * This depends on so many factors that I'm not sure how to answer.
        The protocol needs to be able to automatically select from multiple
        sources of clock based on a algorithm that determines the best 
        source taking into account scalabity and stability. I think what 
        I am saying is a combination of items 2 and 3 above. 
      * Best clock selected by rating in packet <NO>
      * Best clock determined by calculation <Yes - prefer computation 
        based on Rx'd metric(s) ITU? >
      * Combination of information from multiple clocks <NO>
      * Completely distributed method <NO>
      * combination of information from multiple clocks
+++++++++++++++++++++

22) PROTCOL DETAILS (those who do not feel we should develop a
new protocol may skip)    
      * SKIPPED - THE INDUSTRY DOES NOT NEED YET ANOTHER PROTOCOL
      * Skipping for now but if we need to visit any of these you should 
        re-ask these questions = 2
      * Skipped = 4
      * STOP. DON'T DO IT. WE HAVE PROTOCOLS ALREADY!! (note plural) (times 2)
      * Even if I didn't feel that we should leverage the two existing
        protocols, I think these questions are a really premature. 
        Having said that I did a quick cut at preliminary answers

+++++++++++++++++++++

23)  What needs to be present in timing distribution packets ?

  Only timestamp(s) ?
      * Depends if separate O&M or control plane.
      * Timestamps are mandatory
      * Required

  Internal algorithm parameters to improve accuracy ?
      * Don't understand
      * Why not
      * Possibly

  Events (leap seconds, etc)
      * Yes = 2
      * All 3. But statement "Internal algorithm parameters to improve
        accuracy" is very vague. There is a lot which can be addressed by this. 
       * - A TLV encoded protocol, if new algorithms want's to define new
           information. 
         - An event noticication method is needed
       * I don't know

  General comments on the question
       * All three = 2
       * leap seconds should be suppressed shortly by ITU-R
       * See See draft-kurtis-tictoc-itp-req-00.txt section 10

+++++++++++++++++++++

24) It is proposed that time resolution of TICTOC
    protocols be 1 picosecond.

  Do you agree ?  If not - what resolution do you propose ?

      * While I have no objections against 1ps, the question is how can it
        be possibly supported? Which kind of equipment can run at such
        resolution?
      * Yes, this is good
      * If we fix the packet format for time-of-day mode, 1 PS seems 
        logical.
        Some applications might require even better resolution in the
        speccific application, TLV.....
      * No opinion. If new protocol, I have no objection.
      * Quite agressive target - Targetting a nanosecond resolution seems 
        fine for most applications
      * Is it realistic considering hardware features?
        Study application requirements to define resolution.
      * Yes. Packet resolution does not cost anything in this case.
      * At least 1ps
      * Does the group think they can squeeze that level out? - I think most 
        applications would need something of the order of "nano-seconds" - 
        must evaluate the application need to establish this
      * No, 100ns

+++++++++++++++++++++

25) It is proposed that the time be divided into two parts,
     with 1 second being the dividing line.

      * No Opinion = 2

     The higher part is to be treated as data to be transported.

     25a) The dividing line is constrained by the ambiguity introduced by
          network propagation times.
      * I don't understand. The propagation delay is irrelevant as 
        long as it could either be estimated, or stays constant.
      * This ambiguity risk should be mitigated by a more robust mechanism 
        than "time dividing" 

      25b) Do you agree to the division ?  Do you agree to the
           dividing line ?
      * The best way of doing this is to define a datum format, 
        for example MJD, and then you say MJD,,fraction of day 
        since midnight. Now the resolution and precition can be arbritary.
        So I disagree with 1S...
      * NO I need to understand the thinking behind this

+++++++++++++++++++++

 26) What format should the fine granularity part be
     (1/10, 1/2, other), and why?
      * No opinion
      * Well, if what you are saying is should time be seconds and 
        "something" smaller as both NTP and PTP do, then I guess I 
        agree. As for the granularity, that depends on the format and 
        resolution above.
      * NO I need to understand the thinking behind this

+++++++++++++++++++++

27) What are the maximum and minimum update rates needed
    to be supported ?
      * If there are few clients, then on a Gig link 100 or 1000 packets 
        per sec is not a significant load. This may permit operation on 
        paths which are otherwise hopeless. I think this needs to be 
        supported between consenting units on a path engineered to handle it.
      * Algorithm, Hardware, Resouce management deendent
      * TBD
      * minimum : depending on the client app requirements (around 10s ?), 
        max 1/day
      * Depends on clock hardware (stability...) and applications
      * This should be controllable by the server.
      * should support a really wide range with possible BCP 
        information to limit damage from high rates on general 
        infrastructure
      * depends on various factors: processor, local OSC, network 
        conditions, etc.
      * 1- 1000

+++++++++++++++++++++

28) Is a profiling mechanism required ?
      * Combination of both. Profile can define a range which will be
        adjusted by follow-up
      * Depends on definition - don't understand
      * Profile/profiling has to be defined in the Tictoc context (different from the IEEE1588V2 context)
      * Yes = 2
      * Very likely

+++++++++++++++++++++

29) Are "follow-up" messages required ?
      * Combination of both. Profile can define a range which will be
        adjusted by follow-up
      * For the 4 timestamp NTP client/server handshake, I think not for 
        T1 because what the client puts in the request packet for T1 
        doesn't matter.  
        For the server T3 stamp, although it is not absolutely necessary, 
        it might be nice, especially with crypto. It's also handy for some 
        modes of on-path support.
      * They are a bad idea, as we do not have reliable transport at the IP level.
      * Yes = 3
      * Not relevant at the requirements step, we are at the requirements stage not at the solution stage
      * If the client decide it needs them.
      * Very likely
      * No

+++++++++++++++++++++

NETWORKING ISSUES

30)  How should potential clients determine where to find
     a time server ?

   DNS ? DHCP ? new protocol ?                      
      * DEPENDS ON THE PROFILE. SEE ALSO 1588 ANNOUNCE MESSAGES.
      * Yes, Yes, plus anycast. Possibly SRVLOC. Possibly ZeroConf/Bonjour. 
        Definitely not a new protocol if TICTOC is the only user. = 2
      * DNS ? <Maybe> DHCP ? <Yes> new protocol ? <NO>
      * New protocol or extension to PTP (1588)
      * Configured through management or use best master clock 
        algrorithm (if multicast) (times 2)
      * TBD (times 2)
      * Any of the above, and you forgot that it's a well known multicast
        group that can be used for discovering the time servers today. 
      * TBD; Probably dependent on application, category, domain/management
        (i.e., sync service from provider). Thus can be both. Maybe ESMC.
      * Both DNS / DHCP, profile depending
      * Exitign configuration methods are enough and out of scope for tictoc.
      * This is an open issue that needs to be addressed.
      * Either DNS or DHCP 
      * Please no new protocols
      * Automatic base on GMPLS

+++++++++++++++++++++

31)  How are on-path support elements discovered ?          
      * OAM, P-DELAY OR COMBINATION
      * No strong opinion, but either the discovery protocol or a 
        query/initialization capability in TICTOC itself should explicitly 
        communicate the capabilities of the server. It may be useful to 
        communicate client configuration/capabilities to the server as well. = 2
      * I think for now, until we can support the target apps with 
        manual configuration and there is a reasonable likelihood of 
        having on-path support, then on-path discovery should be tabled.
      * TBD = 3
      * TBD. By O&M incl. maybe ESMC.
      * This requires probably a specifical mechanism in the protocol,
        (to be defined), with exchange of on-path support capability 
        information between client and server
      * Elements/parameters to be discovered has to be defined/clarified
      * This is an open issue that needs to be addressed.
      * Automatic base on GMPLS.

+++++++++++++++++++++

32)  How is an optimal path that exploits these elements        
     to be determined ?
      *  TBD. BMC OR VERSION THEREOF SHOULD BE CONSIDERED.
      * Need a clear definition of "optimal". There are multiple dimension to 
        the optimality:
        - best long term accuracy
        - best short term frequency
        - lowest communication overhead
        - most trustworthy.
      * A consistent and symmetrical path is the most important 
        characteristic. Perhaps this can be accomplished through MPLS?
      * Best master clock algorithm if multicast, otherwise maybe by management.
        (times 2)
      * General Internet problem, not specific to TICTOC
      * Can include on-path support element function and performance (as when
        describing source clock quality, other parameters or criterias may be
        defined for on-path support).
      * The optimality is related to apps requirements (short / mid / 
        long term stability requirement) and its determination should be 
        part of the on-path support mechanism. 
      * depends on  Network specification
      * Not sure what you mean with optimal path. If there is support 
        on a link that should be used on that hop. This is IP, we 
        route per hop not on connections...
      * It depends on the application
      * by some sort of TBD discovery protocol 
      * TBD - network guidelines ?

+++++++++++++++++++++

33)  Should we distinguish between time delivered within an
    AS and time delivered outside it?
      * YES. GATEWAY FUNCTION BETWEEN THE TWO.
      * No. AS is a routing concept. = 2
      * Clients/slaves should be able to tell
      * No opinion = 4
      * YES, since no control outside (times 2)
      * No = 2
      * If AS means an operator (what AS does not mean), yes.
      * Yes 
      * First of all I don't think an AS is necessarily the 
        boundary here, organizational boundaries might be, but 
        I don't think we should be making topological 
        requirements or assumptions.
      * what are you driving at here? The job is to deliver quality 
        time, so I'm thinking that you deliver it based on a 
        budgeting methodology, i.e., it covers so many hops, 
        the timing perf at some network interface is then guaranteed 
        to be w/in +/- "x" ppm or "y" us, etc. A carrier handing off 
        time out of the AS has to be able to ensure it is w/in the 
        limits.

+++++++++++++++++++++

SECURITY

34) Which of the following authentication mechanisms is required ?

  34a) of server by client
      * YES = 14
      * Yes, optionally
      * No opinion at this stage. (times2) 
      * As proposed in the ITP draft,

  34b) of client by server 
      * POSSIBLY = 2 (e.g. for O&M)
      * Both server an mutual seem necessary. Unidirectional client by 
        server does not seem necessary unless somebody believes time is 
        a sensitive quantity from a privacy perspective :-) = 2
      * No, unless someone has an example where it seems reasonable to have.
      * No opinion at this stage. (times2)
      * Yes = 6
      * TBD (times 2)
      * protocol support for secure identification (authentication?) of clocks.
      * As proposed in the ITP draft
      * Not really
 
   34c) of middleboxes                        
      * NOT CLEAR WHAT MIDDLEBOX MEANS HERE
      * If we design a protocol that needs middleboxes, I'll scream. 
        If we think we need to support "trivial server/client" implementations 
        I can support that, especially if it's an alternative to middleboxes. = 2
      * If you mean the boxes in the middle providing the on-path support, 
        then Yes if the client is authenticating the server, it have to get 
        the on-path boxes as well.
      * Yes, if they alter timestamps
      * No opinion at this stage. (times2)
      * Yes = 2
      * TBD (times 2)
      * Probably if middleboxes mean on-path support elements.
      * maybe, depending on network topology and on what is meant by middleboxes
      * To be clarified
      * As proposed in the ITP draft,
      * Not sure
      * aaah! No middle stuff please
      * 7.  Secure identification of time source
        ITP MUST be able to support secure identification of a 
        time source, such as a UTC(k).  The ITP protocol must 
        also be able to authenticate the reference time.  The 
        authentication certificate will be sent upon client 
        request or by the server to client.
        Secure transfer client-server-client without 
        (too much) server state.

+++++++++++++++++++++

35) What time source traceability is needed?               
      * NOT CLEAR = 2
      * The best we can obtain within reason and without seriously compromising 
        accuracy or robustness. = 2
      * Probably depends on the app, but if the app expects to be locked to 
        GPS, then it needs to know if the timing path traces back to GPS or not.
      * I suppose most applications require the same time as available 
        through GPS. (times 2)
      * Full (times 2)
      * You want to knew where it came from, and how it was transfered 
        from the real clock to the TICTOC protocol
      * No opinion
      * First define time source traceability, is a quality level needed?
      * It should be noted what????
      * It depends on the application
      * So level of traceability would be desirable, but I'm not sure 
        about the full implications of this that some would support. 

+++++++++++++++++++++

36) Is encryption of timing packets needed ?               
      * NO = 9
      * I can't think of a good reason. On the other hand, I can't think of a 
        reason to not allow it. = 2
      * No, unless someone has an example where it seems reasonable to have.
      * Optional
      * It's an IP protocol, don't we already have generic encryption
        protocols that can be used?
      * Don't think so
      * Can be allowed, as far as it does not threaten the expected accuracy. 
        But probably not useful for most of apps.
      * What time source traceability is needed?
      * TBD
      * Yes

  General comments on the question
      * TICTOC needs to be resilient to attack

==================================================================
==================================================================
_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc