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

From: Danny Mayer <[email-masked]>
Date: Fri, 01 Nov 2013 19:54:25 -0400

I forgot to send you a link to the draft that I tried to update
RFC5905 for this issue. Here it is:
http://tools.ietf.org/html/draft-mizrahi-ntp-extension-field-02

Danny

On 10/29/2013 4:21 PM, Brian Haberman wrote:
> 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:
>>> 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".
>>>> 
>>>> -------------------------------------- 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
>>> 
>>> 
> 

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