Re: [netmod] Fwd: Re: Last Call: <draft-ietf-netmod-iana-timezones-03.txt> (IANA Timezone Database YANG Module) to Proposed Standard

[Benoit Claise <bclaise@xxxxxxxxx>]

Hi Andy,

Hi,

By "this one" I assume you mean the question "Why Proposed Standard?"

I meant the other questions in this email, most importantly.

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.

Thanks for your answer.

Regards, Benoit

Andy

On Wed, Jan 8, 2014 at 8:37 AM, Benoit Claise <bclaise@xxxxxxxxx> wrote:

Dear all,

Sadly, I have not seen a reply to this one.
So let me start the discussion, copying both the ietf-discussion and the netmod WG mailers.
See in-line.

Dear all,

Here is some feedback from the IETF discussion list.
I would appreciate if the author and document shepherd could follow up. Ideally on the IETF discussion list.

Regards, Benoit

-------- Original Message --------

Subject:	Re: Last Call: <draft-ietf-netmod-iana-timezones-03.txt> (IANA Timezone Database YANG Module) to Proposed Standard
Date:	Tue, 3 Dec 2013 19:36:31 -0800
From:	SM <sm@xxxxxxxxxxxx>
To:	<ietf@xxxxxxxx>

At 12:46 03-12-2013, The IESG wrote:
>The IESG has received a request from the NETCONF Data Modeling Language
>WG (netmod) to consider the following document:
>- 'IANA Timezone Database YANG Module'
>   <draft-ietf-netmod-iana-timezones-03.txt> as Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>ietf@xxxxxxxx mailing lists by 2013-12-17. Exceptionally, comments may be

There is the following question in the document shepherd write-up:

  Why is this the proper type of RFC?

I did not see an answer to that question.

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.

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.

In Section 1:

  "The iana-timezones YANG module defines the iana-
   timezone type, which is a serialization of the existing IANA Time
   Zone registry [RFC6557] into YANG format."

The terminology in RFC 6557 defines a TZ Database sometimes referred 
to as the "Olson Database".  There isn't any mention of a "IANA Time 
Zone registry".  I suggest using the same name as in RFC 6557.

That makes sense.

>From Section 3:

  'The iana-timezones module is intended to reflect the IANA "timezone
   database" [RFC6557].  When a timezone location is added to the
   database, the "iana-timezone" enumeration MUST be updated as defined
   in RFC 6020 Section 10 to add the newly created timezone location to
   the enumeration.  The new "enum" statement MUST be added to the
   "iana-timezone" typedef with the same name as the newly added
   timezone location.  A new enum value MUST be allocated by IANA and
   applied to the newly created enum entry.  New entries MAY be placed
   in any order in the enumeration as long as the previously assigned
   enumeration values are not changed.

   If a timezone location is removed from the IANA timezone database,
   the corresponding existing enum statement is kept and a status
   statement is added to mark the enum entry as 'obsolete'.'

The maintainer of the TZ database is responsible for the TZ 
Database.  The person does not work for IANA.  

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 don't think that 
IANA keeps track of the contents of the TZ Database as it was not 
asked to do that work.  

I think it does: http://www.iana.org/time-zones

I don't see the value of using RFC 2119 key 
word for the IANA Considerations.

I suggest not creating the registry proposed in this draft.  The TZ 
database has strived to keep out of political issues.  Adding such a 
registry will pave the way for such issues.

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.

Regards, Benoit

Regards,
-sm 

.

_______________________________________________
netmod mailing list
netmod@xxxxxxxx
https://www.ietf.org/mailman/listinfo/netmod