Subject: Re: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

From: Brian Haberman <[email-masked]>
Date: Tue, 29 Oct 2013 15:24:26 -0400

Hi Tal,

On 5/17/13 12:28 PM, RFC Errata System wrote:
> The following errata report has been submitted for RFC5905,
> "Network Time Protocol Version 4: Protocol and Algorithms Specification".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5905&eid=3627
> 
> --------------------------------------
> Type: Technical
> Reported by: Tal Mizrahi <[email-masked]>
> 
> Section: 7.5
> 
> Original Text
> -------------
> In NTPv4, one or more extension fields can be inserted after the header and before the MAC, which is always present when an extension field is present.
> 
> Corrected Text
> --------------
> In NTPv4, one or more extension fields can be inserted after the header and before the MAC, if a MAC is present. If a MAC is not present, one or more extension fields can be inserted after the header, according to the following rules:
> o If the packet includes a single extension field, the length of the extension field MUST be at least 7 words, i.e., at least 28 octets.
> o If the packet includes more than one extension field, the length of the last extension field MUST be at least 28 octets. The length of the other extension fields in this case MUST be at least 16 octets each.
> 
> 
> Notes
> -----
> The usage of NTP extension fields without authentication is aligned with Section 10 of RFC 5906:
>

While the text you quote below is correct, it does not include the
sentence immediately precedes it.  That sentence states:

"One or more extension fields follow the NTP packet header and the last
followed by the MAC."

I don't think that changes the intent of your text, but it does leave
that text lacking in clarity saying that a MAC must be added after the
extension if it is not present.

Regards,
Brian

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

---

From: Greg Dowd <[email-masked]>
Date: Tue, 29 Oct 2013 19:58:20 +0000

I don't think this is a bad idea per se but I think this errata entry is incomplete and ambiguous.  There are other places in 5905 which call out MAC and extensions which should also be addressed.  I have a little heartburn with the fact that it is using 5906, an informational RFC, as an argument for modifying a standards track document.  Also, it is disingenuous to present 5906 as logic for removing MAC requirement.  5906 is entirely predicated on the requirement that a MAC be present whenever extensions are present.

In conclusion, I like the idea of clarifying the extension/MAC relationship but I think the errata should consider 2 elements, first a complete review of 5905 for MAC/extensions details for consistency, including a better argument justifying the change, and second, an informal review of future-proofing the MAC by size since I see that Tal has allocated what appears to be 4 more bytes than absolutely necessary perhaps as a placeholder for a different MAC schema?

-----Original Message-----
From: ntpwg-bounces+gdowd=[email-masked] [mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf Of Brian Haberman
Sent: Tuesday, October 29, 2013 12:24 PM
To: RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Hi Tal,

On 5/17/13 12:28 PM, RFC Errata System wrote:
> The following errata report has been submitted for RFC5905, "Network 
> Time Protocol Version 4: Protocol and Algorithms Specification".
> 

While the text you quote below is correct, it does not include the sentence immediately precedes it.  That sentence states:

"One or more extension fields follow the NTP packet header and the last followed by the MAC."

I don't think that changes the intent of your text, but it does leave that text lacking in clarity saying that a MAC must be added after the extension if it is not present.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Tue, 29 Oct 2013 16:21:59 -0400

Danny,
     Having a new document that updates 5905 for this is fine.  The
question that Greg's statement raises is whether this erratum is valid
given it seems to miss details in other sections of the RFC.  Do we need
the erratum if we are going to be publishing a new RFC that specifies
the extension field behavior?  I am assuming that this new document will
be marked as updating 5905.

Regards,
Brian

On 10/29/13 4:04 PM, Danny Mayer wrote:
> I put into the extension field draft wording to update RFC 5905 when
> dealing with the MAC making it clear that it is optional. That document
> is standards track. Tal did this errata as an additional item.
> 
> Danny
> 
> On 10/29/2013 3:58 PM, Greg Dowd wrote:

---

From: Greg Dowd <[email-masked]>
Date: Tue, 29 Oct 2013 20:18:08 +0000

I'd like to see the extension field doc become a working group doc and completed and it can then become the logic for an errata against 5905.  Also, a quick look at the draft shows that a single extension field can be 16 bytes?  That doesn't seem right unless you also constrain the MAC to a minimum above that.  It also disagrees with Tal's errata?

-----Original Message-----
From: Danny Mayer [mailto:[email-masked]] 
Sent: Tuesday, October 29, 2013 1:05 PM
To: Greg Dowd; Brian Haberman; RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Danny

---

From: Greg Dowd <[email-masked]>
Date: Tue, 29 Oct 2013 20:27:59 +0000

Actually, that is a great point.  Looking at the extension draft, it should update 5905 and it does nicely cover the ground presented in this errata.  Is that sufficient?

-----Original Message-----
From: Brian Haberman [mailto:[email-masked]] 
Sent: Tuesday, October 29, 2013 1:22 PM
To: Danny Mayer; Greg Dowd; RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Danny,
     Having a new document that updates 5905 for this is fine.  The question that Greg's statement raises is whether this erratum is valid given it seems to miss details in other sections of the RFC.  Do we need the erratum if we are going to be publishing a new RFC that specifies the extension field behavior?  I am assuming that this new document will be marked as updating 5905.

Regards,
Brian

On 10/29/13 4:04 PM, Danny Mayer wrote:
> dealing with the MAC making it clear that it is optional. That 
> document is standards track. Tal did this errata as an additional item.
> 
> Danny
> 
>> From: ntpwg-bounces+gdowd=[email-masked] 
>> [mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf 
>> Of Brian Haberman
>> To: RFC Errata System; [email-masked]; [email-masked]; 
>> [email-masked]; [email-masked]; 
>> [email-masked]; [email-masked]
>> Cc: [email-masked]

---

From: Danny Mayer <[email-masked]>
Date: Tue, 29 Oct 2013 16:04:38 -0400

Danny

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 30 Oct 2013 14:05:23 +0200

Hi Brian, 

The draft is indeed intended to update RFC 5905.

The reason for the erratum is that there currently seems to be a conflict between RFC5905 and RFC5906. It seems that this conflict should be documented as an erratum to allow the (innocent) reader to resolve this conflict.

One of Greg's points was that RFC5906 is informational, and thus should not be weighed against RFC5905 (standard track). And yet it seems that the problem is in fact in RFC5905, and hence I believe this erratum makes sense.

Thanks,
Tal.

-----Original Message-----
From: ntpwg-bounces+talmi=[email-masked] [mailto:ntpwg-bounces+talmi=[email-masked]] On Behalf Of Brian Haberman
Sent: Tuesday, October 29, 2013 10:22 PM
To: Danny Mayer; Greg Dowd; RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Danny,

Regards,
Brian

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 30 Oct 2013 18:28:10 +0200

Hi Greg,

>It's a nit I guess but I still don't get 28 from the quoted language.  I see text that says "if greater than 22 bytes, an extension is 
>present" and "extension must be greater than 8 and multiple of 4".  Hence 24, no?  Is there another rule forcing this minimum of 
>28?  I can see needing a couple padding bytes if there is a 22byte MAC but that is padding.

The text in RFC5906 is a bit confusing (to me); I believe 22 is a typo, and it should be 24 instead. The text below seems to say that the "remaining length" is 160/8+4= 24 bytes. So correct me if I am wrong, but it seems that 22 is a typo. That is why it must be greater the 8 (words) and a multiple of 4, i.e., 28.

Quoting RFC5906:
   the remaining length is 20 (128-bit digest plus 4-octet key ID) or 22
   (160-bit digest plus 4-octet key ID)

Tal.

-----Original Message-----
From: Greg Dowd [mailto:[email-masked]] 
Sent: Wednesday, October 30, 2013 6:14 PM
To: Tal Mizrahi; Brian Haberman; RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

It's a nit I guess but I still don't get 28 from the quoted language.  I see text that says "if greater than 22 bytes, an extension is present" and "extension must be greater than 8 and multiple of 4".  Hence 24, no?  Is there another rule forcing this minimum of 28?  I can see needing a couple padding bytes if there is a 22byte MAC but that is padding.

-----Original Message-----
From: Tal Mizrahi [mailto:[email-masked]]
Sent: Wednesday, October 30, 2013 4:59 AM
To: Greg Dowd; Brian Haberman; RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Hi Greg, 

>I see that Tal has allocated what appears to be 4 more bytes than absolutely necessary perhaps as a placeholder for a different MAC schema?

The minimal length of 28 bytes is applicable when there is a single extension field, or when there is more than one extension field the last one must be at least 28 bytes long. The 28 byte minimum was not intended as a placeholder, but as a lower bound that is intended to be backward compatible with the parsing rules defined in section 10 of RFC5906:

   One or more extension fields follow the NTP packet header and the
   last followed by the MAC.  The extension field parser initializes a
   pointer to the first octet beyond the NTP packet header and
   calculates the number of octets remaining to the end of the packet If
   the remaining length is 20 (128-bit digest plus 4-octet key ID) or 22
   (160-bit digest plus 4-octet key ID), the remaining data are the MAC
   and parsing is complete.  If the remaining length is greater than 22,
   an extension field is present.  If the remaining length is less than
   8 or not a multiple of 4, a format error has occurred and the packet
   is discarded; otherwise, the parser increments the pointer by the
   extension field length and then uses the same rules as above to
   determine whether a MAC is present or another extension field.

Tal.

-----Original Message-----
From: ntpwg-bounces+gdowd=[email-masked] [mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf Of Brian Haberman
Sent: Tuesday, October 29, 2013 12:24 PM
To: RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Hi Tal,

Regards,
Brian

---

From: Greg Dowd <[email-masked]>
Date: Wed, 30 Oct 2013 16:33:56 +0000

In my opinion, 5906 is the wrong source to point to when talking about extensions without MACs.  Section 4 says that the MAC is checked on every packet, with or without extensions.  The entire autokey protocol mandates MACs on every packet.  Section 9 has mechanisms defined for client and server operations, all of which include generating a MAC.  Section 10 specifies one or more extension fields "and the last followed by a MAC".

Again, I'm in favor of the new draft defining mechanisms for using extensions outside of autokey, I just don't think this errata is correctly framed.  By this argument, 5905 and 5906 are both "in error" because, honestly, the goal of the ntp working group in v4 was to document the existing mechanism and the existing mechanism mandates MAC with extensions.  It wasn't really a mistake and I don't see a conflict.  Instead, we now want to broaden the capabilities of the protocol.

Can you clarify where exactly you see the justification in Section 10 of 5906?  And how it would counteract all of the other language in 5906 mandating or implicitly requiring MACs?  Maybe I am missing something?  Otherwise, I would again vote to use your draft as the clarifying text once published.

-----Original Message-----
From: Tal Mizrahi [mailto:[email-masked]] 
Sent: Wednesday, October 30, 2013 5:05 AM
To: Brian Haberman; Danny Mayer; Greg Dowd; RFC Errata System; [email-masked]
Cc: [email-masked]
Subject: RE: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Hi Brian, 

Thanks,
Tal.

-----Original Message-----
From: ntpwg-bounces+talmi=[email-masked] [mailto:ntpwg-bounces+talmi=[email-masked]] On Behalf Of Brian Haberman
Sent: Tuesday, October 29, 2013 10:22 PM
To: Danny Mayer; Greg Dowd; RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Danny,

Regards,
Brian

---

From: Greg Dowd <[email-masked]>
Date: Wed, 30 Oct 2013 16:35:53 +0000

Ah, good catch.  Okay, I support an errata on that :-)

-----Original Message-----
From: Tal Mizrahi [mailto:[email-masked]] 
Sent: Wednesday, October 30, 2013 9:28 AM
To: Greg Dowd; Brian Haberman; RFC Errata System; [email-masked]
Cc: [email-masked]
Subject: RE: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Hi Greg,

Quoting RFC5906:

Tal.

-----Original Message-----
From: Tal Mizrahi [mailto:[email-masked]]
Sent: Wednesday, October 30, 2013 4:59 AM
To: Greg Dowd; Brian Haberman; RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Hi Greg, 

Tal.

-----Original Message-----
From: ntpwg-bounces+gdowd=[email-masked] [mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf Of Brian Haberman
Sent: Tuesday, October 29, 2013 12:24 PM
To: RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Hi Tal,

Regards,
Brian

---

From: [email-masked]
Date: Wed, 30 Oct 2013 20:14:30 +0100

I also support this errata. As far as I remembered this was also the 
recommendation at the last meeting in Atlanta. 

//Dieter

Von:    Tal Mizrahi <[email-masked]>
An:     Greg Dowd <[email-masked]>, Brian Haberman 
<[email-masked]>, RFC Errata System <[email-masked]>, 
"[email-masked]" <[email-masked]>
Kopie:  "[email-masked]" <[email-masked]>
Datum:  30.10.2013 17:28
Betreff:        Re: [ntpwg] [Technical Errata Reported] RFC5905 (3627)
Gesendet von:   ntpwg-bounces+dieter.sibold=[email-masked]

Hi Greg,

>It's a nit I guess but I still don't get 28 from the quoted language.  I 
see text that says "if greater than 22 bytes, an extension is 
>present" and "extension must be greater than 8 and multiple of 4".  Hence 
24, no?  Is there another rule forcing this minimum of 
>28?  I can see needing a couple padding bytes if there is a 22byte MAC 
but that is padding.

The text in RFC5906 is a bit confusing (to me); I believe 22 is a typo, 
and it should be 24 instead. The text below seems to say that the 
"remaining length" is 160/8+4= 24 bytes. So correct me if I am wrong, but 
it seems that 22 is a typo. That is why it must be greater the 8 (words) 
and a multiple of 4, i.e., 28.

Quoting RFC5906:

Tal.

-----Original Message-----
From: Greg Dowd [mailto:[email-masked]] 
Sent: Wednesday, October 30, 2013 6:14 PM
To: Tal Mizrahi; Brian Haberman; RFC Errata System; [email-masked]; 
[email-masked]; [email-masked]; [email-masked]; 
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

It's a nit I guess but I still don't get 28 from the quoted language.  I 
see text that says "if greater than 22 bytes, an extension is present" and 
"extension must be greater than 8 and multiple of 4".  Hence 24, no?  Is 
there another rule forcing this minimum of 28?  I can see needing a couple 
padding bytes if there is a 22byte MAC but that is padding.

-----Original Message-----
From: Tal Mizrahi [mailto:[email-masked]]
Sent: Wednesday, October 30, 2013 4:59 AM
To: Greg Dowd; Brian Haberman; RFC Errata System; [email-masked]; 
[email-masked]; [email-masked]; [email-masked]; 
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Hi Greg, 

>I see that Tal has allocated what appears to be 4 more bytes than 
absolutely necessary perhaps as a placeholder for a different MAC schema?

The minimal length of 28 bytes is applicable when there is a single 
extension field, or when there is more than one extension field the last 
one must be at least 28 bytes long. The 28 byte minimum was not intended 
as a placeholder, but as a lower bound that is intended to be backward 
compatible with the parsing rules defined in section 10 of RFC5906:

Tal.

-----Original Message-----
From: ntpwg-bounces+talmi=[email-masked] [
mailto:ntpwg-bounces+talmi=[email-masked]] On Behalf Of Greg 
Dowd
Sent: Tuesday, October 29, 2013 9:58 PM
To: Brian Haberman; RFC Errata System; [email-masked]; [email-masked]; 
[email-masked]; [email-masked]; [email-masked]; 
[email-masked]
Cc: [email-masked]
Subject: Re: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

I don't think this is a bad idea per se but I think this errata entry is 
incomplete and ambiguous.  There are other places in 5905 which call out 
MAC and extensions which should also be addressed.  I have a little 
heartburn with the fact that it is using 5906, an informational RFC, as an 
argument for modifying a standards track document.  Also, it is 
disingenuous to present 5906 as logic for removing MAC requirement.  5906 
is entirely predicated on the requirement that a MAC be present whenever 
extensions are present.

In conclusion, I like the idea of clarifying the extension/MAC 
relationship but I think the errata should consider 2 elements, first a 
complete review of 5905 for MAC/extensions details for consistency, 
including a better argument justifying the change, and second, an informal 
review of future-proofing the MAC by size since I see that Tal has 
allocated what appears to be 4 more bytes than absolutely necessary 
perhaps as a placeholder for a different MAC schema?

-----Original Message-----
From: ntpwg-bounces+gdowd=[email-masked] [
mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf Of 
Brian Haberman
Sent: Tuesday, October 29, 2013 12:24 PM
To: RFC Errata System; [email-masked]; [email-masked]; 
[email-masked]; [email-masked]; [email-masked]; 
[email-masked]
Cc: [email-masked]
Subject: Re: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Hi Tal,

On 5/17/13 12:28 PM, RFC Errata System wrote:
> In NTPv4, one or more extension fields can be inserted after the header 
and before the MAC, which is always present when an extension field is 
present.
> 
> Corrected Text
> --------------
> In NTPv4, one or more extension fields can be inserted after the header 
and before the MAC, if a MAC is present. If a MAC is not present, one or 
more extension fields can be inserted after the header, according to the 
following rules:
> o If the packet includes a single extension field, the length of the 
extension field MUST be at least 7 words, i.e., at least 28 octets.
> o If the packet includes more than one extension field, the length of 
the last extension field MUST be at least 28 octets. The length of the 
other extension fields in this case MUST be at least 16 octets each.

I don't think that changes the intent of your text, but it does leave that 
text lacking in clarity saying that a MAC must be added after the 
extension if it is not present.

Regards,
Brian

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 30 Oct 2013 23:19:19 +0200

Hi Greg,

> Can you clarify where exactly you see the justification in Section 10 of 5906?

Quoting section 10: "If the remaining length is greater than 22, an extension field is present."
(as we discussed it should be 24 rather than 22 - I think it was Dieter's catch BTW).

So based on this sentence (and the rest of the paragraph it is taken from), if you have a long extension field at the end of the packet, i.e., 7 words or longer, the parser processes it without looking for a MAC.

These parsing rules essentially allow you to use an extension field without a MAC, provided the extension field is long enough. Any implementation that complies to these parsing rules in fact already allows an extension field in the absence of a MAC.

Tal.

-----Original Message-----
From: Tal Mizrahi [mailto:[email-masked]]
Sent: Wednesday, October 30, 2013 5:05 AM
To: Brian Haberman; Danny Mayer; Greg Dowd; RFC Errata System; [email-masked]
Cc: [email-masked]
Subject: RE: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Hi Brian, 

Thanks,
Tal.

-----Original Message-----
From: ntpwg-bounces+talmi=[email-masked] [mailto:ntpwg-bounces+talmi=[email-masked]] On Behalf Of Brian Haberman
Sent: Tuesday, October 29, 2013 10:22 PM
To: Danny Mayer; Greg Dowd; RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Danny,

Regards,
Brian

---

From: Greg Dowd <[email-masked]>
Date: Wed, 30 Oct 2013 23:20:30 +0000

I understand that this sentence describes how to distinguish a MAC from an extension field.  I see nothing which indicates whether either should or should not be included, it is ambiguous in that respect.  Instead, I find very specific language just before that which indicates that the presence of a MAC is mandatory, no?  

Is there a particular reason to submit RFC5906 as the justification for the errata instead of the upcoming extension draft?

BTW, I'm going to drop the wider email list in favor of just Tal and the wg mailer so it doesn't keep getting stuck in the moderator queue after this.  Be forewarned :-)

-----Original Message-----
From: Tal Mizrahi [mailto:[email-masked]] 
Sent: Wednesday, October 30, 2013 2:19 PM
To: Greg Dowd; Brian Haberman; Danny Mayer; RFC Errata System; [email-masked]
Cc: [email-masked]
Subject: RE: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Hi Greg,

Tal.

-----Original Message-----
From: Tal Mizrahi [mailto:[email-masked]]
Sent: Wednesday, October 30, 2013 5:05 AM
To: Brian Haberman; Danny Mayer; Greg Dowd; RFC Errata System; [email-masked]
Cc: [email-masked]
Subject: RE: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Hi Brian, 

Thanks,
Tal.

-----Original Message-----
From: ntpwg-bounces+talmi=[email-masked] [mailto:ntpwg-bounces+talmi=[email-masked]] On Behalf Of Brian Haberman
Sent: Tuesday, October 29, 2013 10:22 PM
To: Danny Mayer; Greg Dowd; RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Danny,

Regards,
Brian

---

From: Tal Mizrahi <[email-masked]>
Date: Thu, 31 Oct 2013 09:41:59 +0200

Hi Greg,

>I understand that this sentence describes how to distinguish a MAC from an extension field.  I see nothing which indicates whether 
>either should or should not be included, it is ambiguous in that respect.  Instead, I find very specific language just before that which 
>indicates that the presence of a MAC is mandatory, no?  

>Is there a particular reason to submit RFC5906 as the justification for the errata instead of the upcoming extension draft?

Well, as an innocent reader and an implementer I found these conflicting descriptions very confusing. We have had quite a bit of discussions on the NTP mailing list about whether it was possible to use an extension field without authentication according to the *existing* RFCs, and whether existing implementations would support this, and we found there were different interpretations by different people. 
For example, see the following thread from a couple of years ago:
http://lists.ntp.org/pipermail/ntpwg/2011-July/001698.html

My feeling is that the current text is not satisfactorily clear, and we need an immediate solution in the form of an erratum to clarify the ambiguity. The draft is a longer term solution, which also adds additional functionality that is not currently in RFC5905.

Tal.

-----Original Message-----
From: Tal Mizrahi [mailto:[email-masked]]
Sent: Wednesday, October 30, 2013 2:19 PM
To: Greg Dowd; Brian Haberman; Danny Mayer; RFC Errata System; [email-masked]
Cc: [email-masked]
Subject: RE: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Hi Greg,

Tal.

-----Original Message-----
From: Tal Mizrahi [mailto:[email-masked]]
Sent: Wednesday, October 30, 2013 5:05 AM
To: Brian Haberman; Danny Mayer; Greg Dowd; RFC Errata System; [email-masked]
Cc: [email-masked]
Subject: RE: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Hi Brian, 

Thanks,
Tal.

-----Original Message-----
From: ntpwg-bounces+talmi=[email-masked] [mailto:ntpwg-bounces+talmi=[email-masked]] On Behalf Of Brian Haberman
Sent: Tuesday, October 29, 2013 10:22 PM
To: Danny Mayer; Greg Dowd; RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Danny,

Regards,
Brian

---

From: Greg Dowd <[email-masked]>
Date: Wed, 30 Oct 2013 16:13:48 +0000

-----Original Message-----
From: Tal Mizrahi [mailto:[email-masked]] 
Sent: Wednesday, October 30, 2013 4:59 AM
To: Greg Dowd; Brian Haberman; RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Hi Greg, 

Tal.

-----Original Message-----
From: ntpwg-bounces+gdowd=[email-masked] [mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf Of Brian Haberman
Sent: Tuesday, October 29, 2013 12:24 PM
To: RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Hi Tal,

Regards,
Brian

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 30 Oct 2013 13:54:31 +0200

Greg, 

As clarified in draft-mizrahi-ntp-extension-field:

- the minimal length of an extension field is 16 bytes.
- *specifically* in the absence of a MAC (section 3.2 in the draft):
   o If the packet includes a single extension field, the length of the
      extension field MUST be at least 7 words, i.e., at least 28
      octets.

   o If the packet includes more than one extension field, the length
      of the last extension field MUST be at least 28 octets. The length
      of the other extension fields in this case MUST be at least 16
      octets each, as defined in [RFC5905].

Does this make sense?

Tal.

-----Original Message-----
From: Danny Mayer [mailto:[email-masked]]
Sent: Tuesday, October 29, 2013 1:05 PM
To: Greg Dowd; Brian Haberman; RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

I put into the extension field draft wording to update RFC 5905 when dealing with the MAC making it clear that it is optional. That document is standards track. Tal did this errata as an additional item.

Danny

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 30 Oct 2013 13:58:38 +0200

Hi Greg, 

Tal.

-----Original Message-----
From: ntpwg-bounces+gdowd=[email-masked] [mailto:ntpwg-bounces+gdowd=[email-masked]] On Behalf Of Brian Haberman
Sent: Tuesday, October 29, 2013 12:24 PM
To: RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

Hi Tal,

Regards,
Brian