Re: [netmod] Fwd: Re: Last Call: <draft-ietf-netmod-iana-timezones-03

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]