NTPWG INTERIM MEETING
Karen, Dieter, Aanchal, Danny, Denis, fmkacher, Harlan, Jeff Prillman,
Kristof, Kyle, Ragnar Sunblad, Robert Annessi, Rodney, Miroslav, Rob
Nagy, someone at Akamai, Dave Mills
1. IEEE 1588 Enterprise Profile
- WGLC several month ago.
- Doug want to make an additional change.
- After that, it will be ready to be forwarded
2. YANG Data Model for IEEE 1588v2
Rodney: WGLC two weeks ago. There have been very good feedback from the
1588 and YANG grous. One final issue about port identity has to be
resolved yet. After that the next version of the draft will hopefully be
released next week.
3. Network Time Protocol Best Current Practices
BCP is ready for IESG
4. Guidelines for Defining Packet Timestamps
- Was presented in Prag (IETF99) at NTPWG
- Suggestion to adopt this as a working group draft
- Danny ask if the content of this draft is in line with different
5. Control Messages Protocol for Use with Network Time Protocol Version 4
- Brain just published version -03
- Two issues
1. version number per mode 6 commands
2. Should there be a version 6 command to query the version of the
- Dave points out that this was originally intended to be a simple
6. Message Authentication Code for the Network Time Protocol
Aanchal: WGLC after IETF 99.
- Most of the comments are resolved.
- A security consideration section has to be added
- An IANA consideration section has to be added although empty
- References have to be modified
The new version of the draft will be ready for IESG submission.
7. NTP Client Data Minimization
- There are no further comments
- Will be sent to WGLC
8. Network Time Protocol Version 4 (NTPv4) Extension Fields
- RFC7822 was published to clarify EF usage
- This draft shall clarify remaining ambiguities
- There is currently no consensus on this draft
9. Network Time Security for the Network Time Protocol
WGLC for NTS: Goal of this session is to identify the blocking issues:
- Danny has some comments he want to send
- Transport schemes:
- The draft has two schemes to transport time requests and
responses. DTLS for symmetric mode and EF approach for the
client server mode. Miroslav suggest to utilize the EF approach
for the symmetric mode also.
- Daniel and Kristof propose to separate the symmetric mode into
an further document in order to go forward with this document.
- Discussion on how to go forward with the document with regard to
the symmetric mode.
- At the face-to-face meeting in Boston we had consensus to first
specify the client-server mode.
- Daniel points out that he included the DTLS approach because it
was easy to specify as the DTLS tunnel was introduced anyway for
the sake of mode 6 packet protection.
- Harlan propose to have the document 'experimental'
Proposed way forward
1. The NTS shall be finalized as a standards track document specifying
only the client-server mode.
2. The modes requiring DTLS tunneling (symmetric modes and control
packets) shall be specified in an additional experimental RFC.
Further blocking issues
- Aanchal points out that the current language is not implementation
friendly. Daniel points out that this can be proved by how well his
and Martin's implementation cooperate.
Next interim: Karen will do a Doodle poll for the week 16th and 23rd