Hi Benoit, Andy,
At 08:37 08-01-2014, Benoit Claise wrote:
Not sure what you propose here. Proposed Standard seems right to me.
From http://www.rfc-editor.org/RFCoverview.html
RFC Categories
Each RFC has a "category" or "status" designation. The possible
categories (see RFC 2026 "The Internet Standards Process -- Revision 3") are:
INTERNET STANDARD, DRAFT STANDARD (deprecated; see RFC 6410),
PROPOSED STANDARD
These are Standards Track documents, official specifications of the
Internet protocol suite defined by the Internet Engineering Task
Force (IETF) and its steering group the IESG.
BEST CURRENT PRACTICE
These are official guidelines and recommendations, but not
standards, from the IETF.
INFORMATIONAL, EXPERIMENTAL
These non-standards documents may originate in the IETF or may be
independent submissions.
HISTORIC
These are former standards that have been actively deprecated.
At 09:09 08-01-2014, Andy Bierman wrote:
By "this one" I assume you mean the question "Why Proposed Standard?"
This YANG module is meant to be imported by other standard YANG modules,
which creates a normative reference in each importing RFC. We try to avoid
standard modules that rely on non-standard modules. At first, (e.g, RFC 5277,
RFC 5717) the YANG modules were not normative. But since 2010,
(RFC 6020) all YANG modules are normative and XSD is no longer used.
I included the comment from Andy Bierman above as it is also related
to the document status.
If I understood the argument, it is that this YANG module would be
referenced by other standard YANG modules and that is why the
intended status is "Proposed Standard". The argument from Benoit
Claise is that the document is on the Standards Track as it is an
official specification of the Internet protocol suite defined by the
Internet Engineering Task Force. I'll consider the question as
addressed as the matter could be argued that way.
The WGLC was from 5 July to 22 July. There wasn't any comments
during the WGLC. The only comment I found was one posted on 9 August.
According to the write-up, the "document has strong consensus". In
my opinion that determination is questionable.
Correct, but see BCP 175: Procedures for Maintaining the Time Zone Database:
The TZ Coordinator is an IANA Designated Expert
Are you questioning the term "IANA timezone database", which should
be "TZ Database" according to BCP 175?
I suggested using the same name as in RFC 6557.
TZ locations can be controversial every now and then. There have
been discussions about having a (TZ) location for an island inhabited
by penguins. :-) There have been arguments about changing a
location as a matter of national pride. There has been an attempt to
take up a TZ mailing list disagreement with IANA. IETF
standardization of this information makes it look official and paves
the way for governance questions.
I think it does: http://www.iana.org/time-zones
What I meant was that IANA provides hosting services. IANA does not
track the changes.
Well, we need to specify the system clock in the following YANG
module
(https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/),
and hence we require a way to represent the TZ in YANG.
Would it be possible to use "timezone-utc-offset" only and not have
"timezone-location"? RFC 5277 references RFC 3339 for time zones.
Regards,
-sm