[ntpwg] REQUEST FOR TEXT - Protocol Doc Changes

[Jim Martin]

Gentlepeople,
	Based upon the notes (and my recollection) from the meeting in  
Chicago, there were four  main points to be addressed in the next (and  
hopefully final) rev of the protocol spec.  They were:

> Comments/Questions from Floor:
>
> Mark Townsley concerned with usage of the term "private networks"
> in resolving Stewart Bryant comments
> * Proposal to use stratum (i.e. a different stratum level) as a  
> protection mechanism
> * Tim Sheppard proposed use of port number
> * Yakov proposed using a field in header that could be used as  
> indicator
> * Karen proposed to modify text (eliminate reference to private  
> networks)
> to remove issue
> *The consensus was that the term "private networks" will be removed  
> from draft
	This has been done. Specifically, the text in Section 2, "Modes of  
Operation" has been changed from:

"Alternative algorithms MAY be used, but their output MUST be  
identical to the algorithms described in this specification, or they  
MUST be used exclusively in a private network."

to

"Alternative algorithms MAY be used, but their output MUST be  
identical to the algorithms described in this specification."
>
> -Comment from Tony Hain, refid should not be associated with IP  
> address
> *Jim believes that text in draft is OK
> *It was agreed that this will be verified
  	Tony was concerned that this was a v4 only dependancy. As seen in  
the following quote from the text, that's not the case. No change  
required.

"Above stratum 1 (secondary servers and clients) this is the reference  
identifier of the server and can be used to detect timing loops. If  
using the IPv4 address family, the identifier is the four-octet IPv4  
address. If using the IPv6 address family, it is the first four octets  
of the MD5 hash of the IPv6 address."


> -Comment from Stewart Bryant:  need to specify precisely the start bit
> * Yakov and Stewart Bryant agreed to contribute text to resolve this  
> issue

	This is where I'm looking for input from the community. Yakov,  
Stewart, Rich Osman, or anyone who has a good grasp on the issue and  
can generate a few lines to precisely characterize the details.  This  
is currently the blocker on getting this out.

>
>
> -Discussion regarding IANA
> * The group consensus was that the group needs to precisely identify
> items that are to be IANA Managed
> *Need to identify and articulate policies
	I'm currently in the process of going through the document and  
identifying which code points make sense to pull out and put under  
IANA control.  If anyone wants to take a pass through and give me  
their opinion of what needs to move into the IANA considerations, I'd  
appreciate it, but if not, I'll just go ahead with my best estimate.

- Jim