Subject: Re: [ntpwg] New Version Notification for draft-stenn-ntp-extension-fields-00.txt

From: Tal Mizrahi <[email-masked]>
Date: Mon, 16 Jan 2017 13:11:34 +0000

Hi Harlan, All,

One of the main issues that is proposed in this draft is to redefine the <Field Type> field in the extension field header.
In RFC5905 and in RFC7822, the <Field Type> is defined as a 16-bit value that defines the extension field type. An IANA registry is defined for this field, allowing values in the range 0-65535.

Draft-stenn-ntp-extension-fields proposes to redefine the <Field Type>, as follows:
       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R|E|O|M| Code  | Primary Type  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I believe there are two possible options with respect to the proposal:
(1) Adopt this proposal. That would mean that a new draft cannot ask IANA to assign an arbitrary Field Type value in the range 0-65535. I believe that would mean we would have to update the IANA registry, and only allow IANA to allocate values for the <Primary Type>, i.e., in the ranges 0-255.
Or
(2) Continue working as defined so far: the Field Type is 16-bits long, and an RFC can request any set of values in the range 0-65535. Thus, every RFC can define sub-fields in a way that is consistent with its IANA-assigned values. I believe that is how it worked in RFC5906 and in RFC7821.

Personally, I would recommend to go with option (2).

I would be happy to hear people's opinion about this.

Cheers,
Tal.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Sunday, November 13, 2016 11:55 PM
>To: Tal Mizrahi; Harlan Stenn; Danny Mayer
>Subject: New Version Notification for draft-stenn-ntp-extension-fields-00.txt
>
>
>A new version of I-D, draft-stenn-ntp-extension-fields-00.txt
>has been successfully submitted by Harlan Stenn and posted to the IETF
>repository.
>
>Name:		draft-stenn-ntp-extension-fields
>Revision:	00
>Title:		Network Time Protocol Version 4 (NTPv4) Extension Fields
>Document date:	2016-11-13
>Group:		Individual Submission
>Pages:		8
>URL:            https://www.ietf.org/internet-drafts/draft-stenn-ntp-extension-fields-
>00.txt
>Status:         https://datatracker.ietf.org/doc/draft-stenn-ntp-extension-fields/
>Htmlized:       https://tools.ietf.org/html/draft-stenn-ntp-extension-fields-00
>
>
>Abstract:
>   Network Time Protocol version 4 (NTPv4) defines the optional usage of
>   extension fields.  An extension field, as defined in RFC 5905
>   [RFC5905], resides after the end of the NTP header, and supplies
>   optional capabilities or information that is not conveyed in the
>   standard NTP header.  This document updates RFC 5905 [RFC5905] by
>   clarifying some points regarding NTP extension fields and their usage
>   with legacy Message Authentication Codes (MACs).
>
>   With the adoption of this update, the authors recommend rescinding
>   [Err3627].
>
>
>
>
>Please note that it may take a couple of minutes from the time of submission until
>the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 16 Jan 2017 13:32:29 +0000

Tal Mizrahi writes:
> Hi Harlan, All,
> 
> One of the main issues that is proposed in this draft is to redefine the <Fie
> ld Type> field in the extension field header.
> In RFC5905 and in RFC7822, the <Field Type> is defined as a 16-bit value that
>  defines the extension field type. An IANA registry is defined for this field
> , allowing values in the range 0-65535.
> 
> (1) Adopt this proposal. That would mean that a new draft cannot ask IANA to 
> assign an arbitrary Field Type value in the range 0-65535. I believe that wou
> ld mean we would have to update the IANA registry, and only allow IANA to all
> ocate values for the <Primary Type>, i.e., in the ranges 0-255.
> Or
> (2) Continue working as defined so far: the Field Type is 16-bits long, and a
> n RFC can request any set of values in the range 0-65535. Thus, every RFC can
>  define sub-fields in a way that is consistent with its IANA-assigned values.
>  I believe that is how it worked in RFC5906 and in RFC7821.
> 

Tal,

What you propose breaks autokey.

Is there some reason to believe that IANA doesn't like it when we
recommend a number for this field?

Where is the benefit to IANA saying in a document that an EF will be
assigne some number between 0-255, and then people will have to look
somewhere else to see, for example, the needed values for the "code" and
"flag bits"?

If IANA doesn't object to our offering recommended assignments (I've
been doing this for my proposals and I haven't received any feedback at
all.

If IANA wants to be able to assign numbers for EF types, they must limit
themselves to the 3-255 range.  This will also cause problem down the
road, as we need to test these things out and it's a PITA to implement,
say, "numbers in the 128-255 range are for testing, but production
numbers weill be in the 3-127 range", and then implementations will have
to support 2 numbers for the same EF type.  Ugh.

H
--

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 16 Jan 2017 13:34:41 +0000

One more thing, I don't mean to pick on autokey.  Yes, it's old and we
want to deprecate it.  But I think we want to "color inside the lines"
and not cause additional breakage.
-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 16 Jan 2017 13:43:40 +0000

Hi Harlan,

Thanks for the quick response.

>What you propose breaks autokey.

I recommend option (2). I don't think (2) breaks Autokey. I believe (2) is consistent with Autokey.

>Where is the benefit to IANA saying in a document that an EF will be assigne some
>number between 0-255, and then people will have to look somewhere else to
>see, for example, the needed values for the "code" and "flag bits"?

The thing is that the flag bits are *indicators*. They have a meaning, unlike IANA-assigned values, which are simply arbitrarily assigned *identifiers*.

Here is an example to make my point:
RFC7821 has been assigned the field type value 0x2005.
Now if we adopt option (1), it means that no one will be able to use 0x0005, or 0x4005, or 0x8005. But there is nothing in the IANA registry that documents this limitation, so it doesn't seem to make sense to me.

Cheers,
Tal.

>From: Harlan Stenn [mailto:[email-masked]]
>Sent: Monday, January 16, 2017 3:32 PM
>To: Tal Mizrahi
>Cc: [email-masked]; Harlan Stenn; Danny Mayer
>Subject: [EXT] Re: [ntpwg] New Version Notification for draft-stenn-ntp-
>extension-fields-00.txt
>
>External Email
>
>----------------------------------------------------------------------
>Tal Mizrahi writes:
>> Hi Harlan, All,
>>
>> One of the main issues that is proposed in this draft is to redefine
>> the <Fie ld Type> field in the extension field header.
>> In RFC5905 and in RFC7822, the <Field Type> is defined as a 16-bit
>> value that  defines the extension field type. An IANA registry is
>> defined for this field , allowing values in the range 0-65535.
>>
>> Draft-stenn-ntp-extension-fields proposes to redefine the <Field
>> Type>, as fo
>> llows:
>>        0                   1
>> (1) Adopt this proposal. That would mean that a new draft cannot ask
>> IANA to assign an arbitrary Field Type value in the range 0-65535. I
>> believe that wou ld mean we would have to update the IANA registry,
>> and only allow IANA to all ocate values for the <Primary Type>, i.e., in the
>ranges 0-255.
>> Or
>> (2) Continue working as defined so far: the Field Type is 16-bits
>> long, and a n RFC can request any set of values in the range 0-65535.
>> Thus, every RFC can  define sub-fields in a way that is consistent with its IANA-
>assigned values.
>Is there some reason to believe that IANA doesn't like it when we recommend a
>number for this field?
>
>Where is the benefit to IANA saying in a document that an EF will be assigne some
>number between 0-255, and then people will have to look somewhere else to
>see, for example, the needed values for the "code" and "flag bits"?
>
>If IANA doesn't object to our offering recommended assignments (I've been
>doing this for my proposals and I haven't received any feedback at all.
>
>themselves to the 3-255 range.  This will also cause problem down the road, as
>we need to test these things out and it's a PITA to implement, say, "numbers in
>the 128-255 range are for testing, but production numbers weill be in the 3-127
>range", and then implementations will have to support 2 numbers for the same
>EF type.  Ugh.
>
>H
>--
>
>> >Subject: New Version Notification for
>> >draft-stenn-ntp-extension-fields-00.tx
>> t
>> >
>> >
>> >has been successfully submitted by Harlan Stenn and posted to the
>> >IETF repository.
>> >
>> >Please note that it may take a couple of minutes from the time of
>> >submission
>>  until

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 16 Jan 2017 05:51:08 -0800

And to be clear, autokey (5906) uses field type 2, has 9 code values, and uses the R and E flag bits. It requests that codes 0-7 (as I recall) be reserved for future autokey versions and I ignore this because it's clear we're not planning any more autokey versions.  So my draft simply extends current behavior. 

Sent from my iPhone - please excuse brevity and typos

> On Jan 16, 2017, at 5:34 AM, Harlan Stenn <[email-masked]> wrote:
>

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 16 Jan 2017 14:18:01 +0000

Hi Harlan,

>And to be clear, autokey (5906) uses field type 2, has 9 code values, and uses the
>R and E flag bits. It requests that codes 0-7 (as I recall) be reserved for future
>autokey versions

Right, and the extension field IANA registry has assigned all the possible values that can use codes 0-9 for <Primary Type>=0x2.
So RFC 5906 is currently consistent with option (2), which I recommend to go for.

Just a reminder, option 2 is:

>> long, and an RFC can request any set of values in the range 0-65535.

Cheers,
Tal.

>From: Harlan Stenn [mailto:[email-masked]]
>Sent: Monday, January 16, 2017 3:51 PM
>To: Harlan Stenn
>Cc: Tal Mizrahi; [email-masked]; Danny Mayer
>And to be clear, autokey (5906) uses field type 2, has 9 code values, and uses the
>R and E flag bits. It requests that codes 0-7 (as I recall) be reserved for future
>autokey versions and I ignore this because it's clear we're not planning any more
>autokey versions.  So my draft simply extends current behavior.
>