Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Andy Bierman]

On Thu, Aug 18, 2016 at 7:15 PM, Dale R. Worley  wrote:

> William Lupton  writes:
> > Regardless of the discussion about “published”, other organisations
> > may be planning to use YANG modules that are currently within
> > IDs. Obviously it’s vastly preferable if such IDs become RFCs before
> > these other organisations publish any specifications or data models
> > that use such draft IETF YANG, but it might occasionally be necessary
> > to reference a draft model (hopefully one that has already been sent
> > for AD review) in a published standard. This is why I would like the
> > clarification to cover IDs (at least WG-adopted ones)!
>
> Unfortunately, this sort of problem has to be considered.  I remember
> when the "SIP multiple line appearances" draft was being worked on.
> Ultimately, there were products on the market that supported the -03
> version, the -04 version, and the final (RFC) version.
>
> My suggestion is that any time a version of a module is "published", it
> must either be identical to the previous "published" version, or have a
> newer revision date.  As far as I can see, the *practical* meaning of
> "published" is a document that has a permanent URL, because you can't
> convince a customer that a document is a "specification" if it doesn't
> have a stable URL.  For Internet Drafts, that seems to mean each
> numbered version entered into the Data Tracker.
>


The current text says the revision date MUST be updated
if the YANG module changed at all.  Seems clear to me.

I think I will add a reference to RFC 2026, sec. 2.2
to use the term  "published" specification

An Internet-Draft is NOT a means of "publishing" a specification;



Andy



>
> But there is a further problem:  A sequence of versions of a module with
> different revision dates are required to be related by the rules of
> section 11 of RFC 6020 (or draft-ietf-netmod-rfc6020bis), i.e., each
> newer version is a proper extension of the older version(s).  Clearly,
> we *don't* want to have that constraint between versions of modules in a
> sequence of I-Ds, we want to be able to delete elements.
>
> Dale
>
> ___


Andy


> 
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Dale R. Worley]

William Lupton  writes:
> Regardless of the discussion about “published”, other organisations
> may be planning to use YANG modules that are currently within
> IDs. Obviously it’s vastly preferable if such IDs become RFCs before
> these other organisations publish any specifications or data models
> that use such draft IETF YANG, but it might occasionally be necessary
> to reference a draft model (hopefully one that has already been sent
> for AD review) in a published standard. This is why I would like the
> clarification to cover IDs (at least WG-adopted ones)!

Unfortunately, this sort of problem has to be considered.  I remember
when the "SIP multiple line appearances" draft was being worked on.
Ultimately, there were products on the market that supported the -03
version, the -04 version, and the final (RFC) version.

My suggestion is that any time a version of a module is "published", it
must either be identical to the previous "published" version, or have a
newer revision date.  As far as I can see, the *practical* meaning of
"published" is a document that has a permanent URL, because you can't
convince a customer that a document is a "specification" if it doesn't
have a stable URL.  For Internet Drafts, that seems to mean each
numbered version entered into the Data Tracker.

But there is a further problem:  A sequence of versions of a module with
different revision dates are required to be related by the rules of
section 11 of RFC 6020 (or draft-ietf-netmod-rfc6020bis), i.e., each
newer version is a proper extension of the older version(s).  Clearly,
we *don't* want to have that constraint between versions of modules in a
sequence of I-Ds, we want to be able to delete elements.

Dale

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

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Andy Bierman]

Hi,


IMO it is not useful to have lots of
copies of a module that just differ by revision date.


   It is acceptable to reuse the same revision statement within
   unpublished versions (e.g., Internet-Drafts), but the revision date
   MUST be updated to a higher value each time the YANG module is changed.
   The revision date MAY be updated if nothing in the module has changed.



Andy


On Thu, Aug 18, 2016 at 10:26 AM, William Lupton <
wlup...@broadband-forum.org> wrote:

> Oh dear :(. What do you think about this, which is what I really care
> about?
>
> —
> Regardless of the discussion about “published”, other organisations may be
> planning to use YANG modules that are currently within IDs. Obviously it’s
> vastly preferable if such IDs become RFCs before these other organisations
> publish any specifications or data models that use such draft IETF YANG,
> but it might occasionally be necessary to reference a draft model
> (hopefully one that has already been sent for AD review) in a published
> standard. This is why I would like the clarification to cover IDs (at least
> WG-adopted ones)!
> —
>
> William
>
> On 18 Aug 2016, at 18:21, Andy Bierman  wrote:
>
> Hi,
>
> So this is the test that is supposed to replace 5.8, para 7:
>
>It is acceptable to reuse the same revision statement within
>unpublished versions (i.e., Internet-Drafts), but the revision date
>MUST be updated to a higher value each time the Internet-Draft is re-
>posted.
>
>
> IMO the new text is worse.
>
> I like the suggestion to define "published" and "unpublished"
> to have the semantics defined in RFC 2026.
>
>
>
> Andy
>
> On Thu, Aug 18, 2016 at 10:08 AM, William Lupton <
> wlup...@broadband-forum.org> wrote:
>
>> Thanks. Of course I am fine with this suggestion. This gives:
>>
>> NEW:
>>
>> It is not required to keep the full revision history of draft versions
>> (e.g., modules contained within Internet-Drafts). That is, within a
>> sequence of draft versions, only the most recent revision need be recorded
>> in the module. However, if the module has changed, the revision date of the
>> most recent revision MUST be updated to a later date whenever a new version
>> is made available (e.g., via a new version of an Internet-Draft).
>>
>> > On 18 Aug 2016, at 13:21, Ladislav Lhotka  wrote:
>> >
>> > William Lupton  writes:
>> >
>> >> Kent, all,
>> >>
>> >> OK :). I will take Lada’s update to my Monday text as a baseline and
>> will give my proposed new text without further ado, followed by rationale.
>> >>
>> >> BASELINE:
>> >>
>> >> It is not required to keep the revision history of unpublished
>> versions (e.g., Internet-Drafts). That is, within a sequence of unpublished
>> versions, only the most recent revision MAY be recorded in the module or
>> submodule. However, the revision date of the most recent revision MUST be
>> updated to a higher value each time a new version (e.g., of the
>> Internet-Draft) is posted.
>> >>
>> >> NEW:
>> >>
>> >> It is not required to keep the full revision history of draft versions
>> >> (e.g., modules contained within Internet-Drafts). That is, within a
>> >> sequence of draft versions, only the most recent revision need be
>> >> recorded in the module. However, if the module has changed, the
>> >> revision date of the most recent revision MUST be updated to a higher
>> >> value whenever a new version is made available (e.g., via a new
>> >> version of an Internet-Draft).
>> >
>> > I like this text. Perhaps "a higher value" could be replaced with "a
>> > later date"?
>> >
>> > Lada
>> >
>> >>
>> >> ——
>> >>
>> >> The main comments and suggestions on the baseline text were:
>> >> Why say MAY rather than MUST? Suggestion to say “need” to avoid
>> difficulty with “only” and “MAY”.
>> >> Should be more precise re the difference between a draft and a module
>> contained within a draft.
>> >> Should allow or encourage the module revision date to be bumped only
>> if the YANG has changed (or on the containing draft becoming a standard).
>> >> Discussion of “published” / “posted” etc., and their meanings in an
>> IETF context.
>> >> Support for the principle that the text should be both general
>> (applying to all organisations) and specific (applying to IETF) and note
>> that IETF-specific text should be parenthesised.
>> >> Assertion that all publicly-available “adopted” modules (whether draft
>> or standard) must bump revision dates if the YANG changes.
>> >>
>> >> Here are a few notes to forestall some of your possible comments:
>> >> I didn’t mention submodules, because of the generic (Section 2.3) note
>> that “module” means “module or submodule” unless specifically discussing
>> submodules.
>> >> I didn’t mention RFC publication as a special case (revision date MUST
>> be unconditionally updated) because this paragraph is only about drafts. I
>> assume that requirements governing modules in RFCs are already covered
>> elsewhere.
>> >> I hope that I avoided IETF-emotive terms outsi

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[William Lupton]

Oh dear :(. What do you think about this, which is what I really care about?

— 
Regardless of the discussion about “published”, other organisations may be 
planning to use YANG modules that are currently within IDs. Obviously it’s 
vastly preferable if such IDs become RFCs before these other organisations 
publish any specifications or data models that use such draft IETF YANG, but it 
might occasionally be necessary to reference a draft model (hopefully one that 
has already been sent for AD review) in a published standard. This is why I 
would like the clarification to cover IDs (at least WG-adopted ones)!
— 

William

> On 18 Aug 2016, at 18:21, Andy Bierman  wrote:
> 
> Hi,
> 
> So this is the test that is supposed to replace 5.8, para 7:
> 
>It is acceptable to reuse the same revision statement within
>unpublished versions (i.e., Internet-Drafts), but the revision date
>MUST be updated to a higher value each time the Internet-Draft is re-
>posted.
> 
> IMO the new text is worse.
> 
> I like the suggestion to define "published" and "unpublished"
> to have the semantics defined in RFC 2026.
> 
> 
> 
> Andy
> 
> On Thu, Aug 18, 2016 at 10:08 AM, William Lupton  > wrote:
> Thanks. Of course I am fine with this suggestion. This gives:
> 
> NEW:
> 
> It is not required to keep the full revision history of draft versions (e.g., 
> modules contained within Internet-Drafts). That is, within a sequence of 
> draft versions, only the most recent revision need be recorded in the module. 
> However, if the module has changed, the revision date of the most recent 
> revision MUST be updated to a later date whenever a new version is made 
> available (e.g., via a new version of an Internet-Draft).
> 
> > On 18 Aug 2016, at 13:21, Ladislav Lhotka  > > wrote:
> >
> > William Lupton  > > writes:
> >
> >> Kent, all,
> >>
> >> OK :). I will take Lada’s update to my Monday text as a baseline and will 
> >> give my proposed new text without further ado, followed by rationale.
> >>
> >> BASELINE:
> >>
> >> It is not required to keep the revision history of unpublished versions 
> >> (e.g., Internet-Drafts). That is, within a sequence of unpublished 
> >> versions, only the most recent revision MAY be recorded in the module or 
> >> submodule. However, the revision date of the most recent revision MUST be 
> >> updated to a higher value each time a new version (e.g., of the 
> >> Internet-Draft) is posted.
> >>
> >> NEW:
> >>
> >> It is not required to keep the full revision history of draft versions
> >> (e.g., modules contained within Internet-Drafts). That is, within a
> >> sequence of draft versions, only the most recent revision need be
> >> recorded in the module. However, if the module has changed, the
> >> revision date of the most recent revision MUST be updated to a higher
> >> value whenever a new version is made available (e.g., via a new
> >> version of an Internet-Draft).
> >
> > I like this text. Perhaps "a higher value" could be replaced with "a
> > later date"?
> >
> > Lada
> >
> >>
> >> ——
> >>
> >> The main comments and suggestions on the baseline text were:
> >> Why say MAY rather than MUST? Suggestion to say “need” to avoid difficulty 
> >> with “only” and “MAY”.
> >> Should be more precise re the difference between a draft and a module 
> >> contained within a draft.
> >> Should allow or encourage the module revision date to be bumped only if 
> >> the YANG has changed (or on the containing draft becoming a standard).
> >> Discussion of “published” / “posted” etc., and their meanings in an IETF 
> >> context.
> >> Support for the principle that the text should be both general (applying 
> >> to all organisations) and specific (applying to IETF) and note that 
> >> IETF-specific text should be parenthesised.
> >> Assertion that all publicly-available “adopted” modules (whether draft or 
> >> standard) must bump revision dates if the YANG changes.
> >>
> >> Here are a few notes to forestall some of your possible comments:
> >> I didn’t mention submodules, because of the generic (Section 2.3) note 
> >> that “module” means “module or submodule” unless specifically discussing 
> >> submodules.
> >> I didn’t mention RFC publication as a special case (revision date MUST be 
> >> unconditionally updated) because this paragraph is only about drafts. I 
> >> assume that requirements governing modules in RFCs are already covered 
> >> elsewhere.
> >> I hope that I avoided IETF-emotive terms outside the parentheses, e.g I 
> >> used the terms “draft” and “made available”.
> >> I nearly added “statement” as in “revision date of the most recent 
> >> revision statement”. I would certainly be happy with that change.
> >> I don’t really like “higher value” because that makes it sounds like a 
> >> numeric value. However, no-one has commented on this and I guess it’s 
> >> unambiguous. So let fido sleep on.
> 

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Andy Bierman]

Hi,

So this is the test that is supposed to replace 5.8, para 7:

   It is acceptable to reuse the same revision statement within
   unpublished versions (i.e., Internet-Drafts), but the revision date
   MUST be updated to a higher value each time the Internet-Draft is re-
   posted.


IMO the new text is worse.

I like the suggestion to define "published" and "unpublished"
to have the semantics defined in RFC 2026.



Andy

On Thu, Aug 18, 2016 at 10:08 AM, William Lupton <
wlup...@broadband-forum.org> wrote:

> Thanks. Of course I am fine with this suggestion. This gives:
>
> NEW:
>
> It is not required to keep the full revision history of draft versions
> (e.g., modules contained within Internet-Drafts). That is, within a
> sequence of draft versions, only the most recent revision need be recorded
> in the module. However, if the module has changed, the revision date of the
> most recent revision MUST be updated to a later date whenever a new version
> is made available (e.g., via a new version of an Internet-Draft).
>
> > On 18 Aug 2016, at 13:21, Ladislav Lhotka  wrote:
> >
> > William Lupton  writes:
> >
> >> Kent, all,
> >>
> >> OK :). I will take Lada’s update to my Monday text as a baseline and
> will give my proposed new text without further ado, followed by rationale.
> >>
> >> BASELINE:
> >>
> >> It is not required to keep the revision history of unpublished versions
> (e.g., Internet-Drafts). That is, within a sequence of unpublished
> versions, only the most recent revision MAY be recorded in the module or
> submodule. However, the revision date of the most recent revision MUST be
> updated to a higher value each time a new version (e.g., of the
> Internet-Draft) is posted.
> >>
> >> NEW:
> >>
> >> It is not required to keep the full revision history of draft versions
> >> (e.g., modules contained within Internet-Drafts). That is, within a
> >> sequence of draft versions, only the most recent revision need be
> >> recorded in the module. However, if the module has changed, the
> >> revision date of the most recent revision MUST be updated to a higher
> >> value whenever a new version is made available (e.g., via a new
> >> version of an Internet-Draft).
> >
> > I like this text. Perhaps "a higher value" could be replaced with "a
> > later date"?
> >
> > Lada
> >
> >>
> >> ——
> >>
> >> The main comments and suggestions on the baseline text were:
> >> Why say MAY rather than MUST? Suggestion to say “need” to avoid
> difficulty with “only” and “MAY”.
> >> Should be more precise re the difference between a draft and a module
> contained within a draft.
> >> Should allow or encourage the module revision date to be bumped only if
> the YANG has changed (or on the containing draft becoming a standard).
> >> Discussion of “published” / “posted” etc., and their meanings in an
> IETF context.
> >> Support for the principle that the text should be both general
> (applying to all organisations) and specific (applying to IETF) and note
> that IETF-specific text should be parenthesised.
> >> Assertion that all publicly-available “adopted” modules (whether draft
> or standard) must bump revision dates if the YANG changes.
> >>
> >> Here are a few notes to forestall some of your possible comments:
> >> I didn’t mention submodules, because of the generic (Section 2.3) note
> that “module” means “module or submodule” unless specifically discussing
> submodules.
> >> I didn’t mention RFC publication as a special case (revision date MUST
> be unconditionally updated) because this paragraph is only about drafts. I
> assume that requirements governing modules in RFCs are already covered
> elsewhere.
> >> I hope that I avoided IETF-emotive terms outside the parentheses, e.g I
> used the terms “draft” and “made available”.
> >> I nearly added “statement” as in “revision date of the most recent
> revision statement”. I would certainly be happy with that change.
> >> I don’t really like “higher value” because that makes it sounds like a
> numeric value. However, no-one has commented on this and I guess it’s
> unambiguous. So let fido sleep on.
> >>
> >> Comments?
> >>
> >> Thanks,
> >> William
> >>
> >>> On 16 Aug 2016, at 19:02, Kent Watsen  wrote:
> >>>
> >>> Hi William,
> >>>
> >>> Do you want to take a stab on consolidating on the comments into new
> proposed draft-text?  - there were two proposals put out before, and a
> number of refinements since, but I’m unsure which were picked up or not.
> Since you raised this issue originally, if would be helpful to get your
> current take on it.
> >>>
> >>> Thanks,
> >>> Kent
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[William Lupton]

Thanks. Of course I am fine with this suggestion. This gives:

NEW:

It is not required to keep the full revision history of draft versions (e.g., 
modules contained within Internet-Drafts). That is, within a sequence of draft 
versions, only the most recent revision need be recorded in the module. 
However, if the module has changed, the revision date of the most recent 
revision MUST be updated to a later date whenever a new version is made 
available (e.g., via a new version of an Internet-Draft).

> On 18 Aug 2016, at 13:21, Ladislav Lhotka  wrote:
> 
> William Lupton  writes:
> 
>> Kent, all,
>> 
>> OK :). I will take Lada’s update to my Monday text as a baseline and will 
>> give my proposed new text without further ado, followed by rationale.
>> 
>> BASELINE:
>> 
>> It is not required to keep the revision history of unpublished versions 
>> (e.g., Internet-Drafts). That is, within a sequence of unpublished versions, 
>> only the most recent revision MAY be recorded in the module or submodule. 
>> However, the revision date of the most recent revision MUST be updated to a 
>> higher value each time a new version (e.g., of the Internet-Draft) is posted.
>> 
>> NEW:
>> 
>> It is not required to keep the full revision history of draft versions
>> (e.g., modules contained within Internet-Drafts). That is, within a
>> sequence of draft versions, only the most recent revision need be
>> recorded in the module. However, if the module has changed, the
>> revision date of the most recent revision MUST be updated to a higher
>> value whenever a new version is made available (e.g., via a new
>> version of an Internet-Draft).
> 
> I like this text. Perhaps "a higher value" could be replaced with "a
> later date"?
> 
> Lada
> 
>> 
>> —— 
>> 
>> The main comments and suggestions on the baseline text were:
>> Why say MAY rather than MUST? Suggestion to say “need” to avoid difficulty 
>> with “only” and “MAY”.
>> Should be more precise re the difference between a draft and a module 
>> contained within a draft.
>> Should allow or encourage the module revision date to be bumped only if the 
>> YANG has changed (or on the containing draft becoming a standard).
>> Discussion of “published” / “posted” etc., and their meanings in an IETF 
>> context.
>> Support for the principle that the text should be both general (applying to 
>> all organisations) and specific (applying to IETF) and note that 
>> IETF-specific text should be parenthesised.
>> Assertion that all publicly-available “adopted” modules (whether draft or 
>> standard) must bump revision dates if the YANG changes.
>> 
>> Here are a few notes to forestall some of your possible comments:
>> I didn’t mention submodules, because of the generic (Section 2.3) note that 
>> “module” means “module or submodule” unless specifically discussing 
>> submodules.
>> I didn’t mention RFC publication as a special case (revision date MUST be 
>> unconditionally updated) because this paragraph is only about drafts. I 
>> assume that requirements governing modules in RFCs are already covered 
>> elsewhere.
>> I hope that I avoided IETF-emotive terms outside the parentheses, e.g I used 
>> the terms “draft” and “made available”.
>> I nearly added “statement” as in “revision date of the most recent revision 
>> statement”. I would certainly be happy with that change.
>> I don’t really like “higher value” because that makes it sounds like a 
>> numeric value. However, no-one has commented on this and I guess it’s 
>> unambiguous. So let fido sleep on.
>> 
>> Comments?
>> 
>> Thanks,
>> William
>> 
>>> On 16 Aug 2016, at 19:02, Kent Watsen  wrote:
>>> 
>>> Hi William,
>>> 
>>> Do you want to take a stab on consolidating on the comments into new 
>>> proposed draft-text?  - there were two proposals put out before, and a 
>>> number of refinements since, but I’m unsure which were picked up or not.  
>>> Since you raised this issue originally, if would be helpful to get your 
>>> current take on it.
>>> 
>>> Thanks,
>>> Kent
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 

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

[netmod] FW: Fwd: I-D Action: draft-ietf-netmod-routing-cfg-23.txt

[Acee Lindem (acee)]

Lou, Kent, 

Lada and I feel this version is ready for WG last call.

Thanks,
Acee 

On 8/18/16, 11:17 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:

>Hi,
>
>apart from relatively minor changes to the schema that were agreed in
>Berlin, all modules were migrated to YANG 1.1 and actively use new YANG
>1.1 features: XPath function derived-from-or-self(), and the action
>"active-route".
>
>Lada
>
>> Begin forwarded message:
>> 
>> From: internet-dra...@ietf.org
>> Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-23.txt
>> Date: 18 August 2016 at 17:12:35 GMT+2
>> To: 
>> Cc: netmod@ietf.org
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>> This draft is a work item of the NETCONF Data Modeling Language of the
>>IETF.
>> 
>>Title   : A YANG Data Model for Routing Management
>>Authors : Ladislav Lhotka
>>  Acee Lindem
>>  Filename: draft-ietf-netmod-routing-cfg-23.txt
>>  Pages   : 74
>>  Date: 2016-08-18
>> 
>> Abstract:
>>   This document contains a specification of three YANG modules and one
>>   submodule.  Together they form the core routing data model which
>>   serves as a framework for configuring and managing a routing
>>   subsystem.  It is expected that these modules will be augmented by
>>   additional YANG modules defining data models for control plane
>>   protocols, route filters and other functions.  The core routing data
>>   model provides common building blocks for such extensions -- routes,
>>   routing information bases (RIB), and control plane protocols.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/
>> 
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-23
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-routing-cfg-23
>> 
>> 
>> Please note that it may take a couple of minutes from the time of
>>submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

[netmod] Fwd: I-D Action: draft-ietf-netmod-routing-cfg-23.txt

[Ladislav Lhotka]

Hi,

apart from relatively minor changes to the schema that were agreed in Berlin, 
all modules were migrated to YANG 1.1 and actively use new YANG 1.1 features: 
XPath function derived-from-or-self(), and the action "active-route".

Lada

> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-23.txt
> Date: 18 August 2016 at 17:12:35 GMT+2
> To: 
> Cc: netmod@ietf.org
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the NETCONF Data Modeling Language of the IETF.
> 
>Title   : A YANG Data Model for Routing Management
>Authors : Ladislav Lhotka
>  Acee Lindem
>   Filename: draft-ietf-netmod-routing-cfg-23.txt
>   Pages   : 74
>   Date: 2016-08-18
> 
> Abstract:
>   This document contains a specification of three YANG modules and one
>   submodule.  Together they form the core routing data model which
>   serves as a framework for configuring and managing a routing
>   subsystem.  It is expected that these modules will be augmented by
>   additional YANG modules defining data models for control plane
>   protocols, route filters and other functions.  The core routing data
>   model provides common building blocks for such extensions -- routes,
>   routing information bases (RIB), and control plane protocols.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-23
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-routing-cfg-23
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

[netmod] I-D Action: draft-ietf-netmod-routing-cfg-23.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NETCONF Data Modeling Language of the IETF.

Title   : A YANG Data Model for Routing Management
Authors : Ladislav Lhotka
  Acee Lindem
Filename: draft-ietf-netmod-routing-cfg-23.txt
Pages   : 74
Date: 2016-08-18

Abstract:
   This document contains a specification of three YANG modules and one
   submodule.  Together they form the core routing data model which
   serves as a framework for configuring and managing a routing
   subsystem.  It is expected that these modules will be augmented by
   additional YANG modules defining data models for control plane
   protocols, route filters and other functions.  The core routing data
   model provides common building blocks for such extensions -- routes,
   routing information bases (RIB), and control plane protocols.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-23

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-routing-cfg-23


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [netmod] YANG 1.1 bug fix last call

[Martin Bjorklund]

"Jernej Tuljak"  wrote:
> While you are at it, there seems to be an orphaned production in the grammar 
> (rfc6020bis-14):
> 
>boolean-operator = and-keyword / or-keyword
> 
> It is probably a leftover from previous versions of if-feature-expr.

Thanks!  I will remove it during AUTH48.


/martin


>  
> Jernej
> 
> 
> > -Original Message-
> > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Juergen
> > Schoenwaelder
> > Sent: Thursday, August 18, 2016 12:02 PM
> > To: netmod@ietf.org
> > Subject: [netmod] YANG 1.1 bug fix last call (was YANG 1.1: XML naming
> > restriction)
> > 
> > Hi,
> > 
> > as discussed in the thread 'YANG 1.1: XML naming restriction', it
> > seems that the restriction that identifiers may not start with "xml"
> > is not necessary according to XML 1.0 (5th edition). In addition, it
> > seems the YANG 1.1 specification should have an explicit normative
> > reference to the XML specification it is based on. The suggested
> > document changes are detailed below (thanks to Martin for writing this
> > up). Please let the WG know by August 24th if you object against
> > implementing this change before YANG 1.1 is published.
> > 
> > /js (with my RFC6020bis document shepherd hat on)
> > 
> > Section 1:
> > 
> > OLD:
> > 
> >This document describes the syntax and semantics of version 1.1 of
> >the YANG language.  It also describes how a data model defined in a
> >YANG module is encoded in the Extensible Markup Language (XML), and
> > 
> > NEW:
> > 
> >This document describes the syntax and semantics of version 1.1 of
> >the YANG language.  It also describes how a data model defined in a
> >YANG module is encoded in the Extensible Markup Language (XML)
> >[XML], and
> > 
> > 
> > Section 1.1:
> > 
> > OLD:
> > 
> >o  Allow type empty in a key.
> > 
> >The following changes have been done to the NETCONF mapping:
> > 
> > NEW:
> > 
> >o  Allow type empty in a key.
> > 
> >o  Removed the restriction that identifiers could not start with
> >   the characters "xml".
> > 
> >The following changes have been done to the NETCONF mapping:
> > 
> > 
> > Section 14:
> > 
> > OLD:
> > 
> >;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))
> >identifier  = (ALPHA / "_")
> >  *(ALPHA / DIGIT / "_" / "-" / ".")
> > 
> > NEW:
> > 
> >identifier  = (ALPHA / "_")
> >  *(ALPHA / DIGIT / "_" / "-" / ".")
> > 
> > 
> > Section 21.1:
> > 
> > NEW:
> > 
> >[XML]  Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
> >   F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
> >   Edition)", World Wide Web Consortium Recommendation REC-
> >   xml-20081126, November 2008,
> >   .
> > 
> > 
> > --
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

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

Re: [netmod] YANG 1.1 bug fix last call

[Martin Bjorklund]

Hi,

Juergen Schoenwaelder  wrote:
> Hi,
> 
> as discussed in the thread 'YANG 1.1: XML naming restriction', it
> seems that the restriction that identifiers may not start with "xml"
> is not necessary according to XML 1.0 (5th edition). In addition, it
> seems the YANG 1.1 specification should have an explicit normative
> reference to the XML specification it is based on. The suggested
> document changes are detailed below (thanks to Martin for writing this
> up). Please let the WG know by August 24th if you object against
> implementing this change before YANG 1.1 is published.
> 
> /js (with my RFC6020bis document shepherd hat on)

I found one more change that I'd like to do, in section 9.4.7:

OLD:

With the following type:

  typedef yang-identifier {
type string {
  length "1..max";
  pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
  pattern '[xX][mM][lL].*' {
modifier invert-match;
  }
}
  }

NEW:

With the following type:

  type string {
length "1..max";
pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
pattern '[xX][mM][lL].*' {
  modifier invert-match;
}
  }


/martin


> 
> Section 1:
> 
> OLD:
> 
>This document describes the syntax and semantics of version 1.1 of
>the YANG language.  It also describes how a data model defined in a
>YANG module is encoded in the Extensible Markup Language (XML), and
> 
> NEW:
> 
>This document describes the syntax and semantics of version 1.1 of
>the YANG language.  It also describes how a data model defined in a
>YANG module is encoded in the Extensible Markup Language (XML)
>[XML], and
> 
> 
> Section 1.1:
> 
> OLD:
> 
>o  Allow type empty in a key.
> 
>The following changes have been done to the NETCONF mapping:
> 
> NEW:
> 
>o  Allow type empty in a key.
> 
>o  Removed the restriction that identifiers could not start with
>   the characters "xml".
> 
>The following changes have been done to the NETCONF mapping:
> 
> 
> Section 14:
> 
> OLD:
> 
>;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))
>identifier  = (ALPHA / "_")
>  *(ALPHA / DIGIT / "_" / "-" / ".")
> 
> NEW:
> 
>identifier  = (ALPHA / "_")
>  *(ALPHA / DIGIT / "_" / "-" / ".")
> 
> 
> Section 21.1:
> 
> NEW:
> 
>[XML]  Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
>   F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
>   Edition)", World Wide Web Consortium Recommendation REC-
>   xml-20081126, November 2008,
>   .
> 
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

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

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[Ladislav Lhotka]

William Lupton  writes:

> Kent, all,
>
> OK :). I will take Lada’s update to my Monday text as a baseline and will 
> give my proposed new text without further ado, followed by rationale.
>
> BASELINE:
>
> It is not required to keep the revision history of unpublished versions 
> (e.g., Internet-Drafts). That is, within a sequence of unpublished versions, 
> only the most recent revision MAY be recorded in the module or submodule. 
> However, the revision date of the most recent revision MUST be updated to a 
> higher value each time a new version (e.g., of the Internet-Draft) is posted.
>
> NEW:
>
> It is not required to keep the full revision history of draft versions
> (e.g., modules contained within Internet-Drafts). That is, within a
> sequence of draft versions, only the most recent revision need be
> recorded in the module. However, if the module has changed, the
> revision date of the most recent revision MUST be updated to a higher
> value whenever a new version is made available (e.g., via a new
> version of an Internet-Draft).

I like this text. Perhaps "a higher value" could be replaced with "a
later date"?

Lada

>
> —— 
>
> The main comments and suggestions on the baseline text were:
> Why say MAY rather than MUST? Suggestion to say “need” to avoid difficulty 
> with “only” and “MAY”.
> Should be more precise re the difference between a draft and a module 
> contained within a draft.
> Should allow or encourage the module revision date to be bumped only if the 
> YANG has changed (or on the containing draft becoming a standard).
> Discussion of “published” / “posted” etc., and their meanings in an IETF 
> context.
> Support for the principle that the text should be both general (applying to 
> all organisations) and specific (applying to IETF) and note that 
> IETF-specific text should be parenthesised.
> Assertion that all publicly-available “adopted” modules (whether draft or 
> standard) must bump revision dates if the YANG changes.
>
> Here are a few notes to forestall some of your possible comments:
> I didn’t mention submodules, because of the generic (Section 2.3) note that 
> “module” means “module or submodule” unless specifically discussing 
> submodules.
> I didn’t mention RFC publication as a special case (revision date MUST be 
> unconditionally updated) because this paragraph is only about drafts. I 
> assume that requirements governing modules in RFCs are already covered 
> elsewhere.
> I hope that I avoided IETF-emotive terms outside the parentheses, e.g I used 
> the terms “draft” and “made available”.
> I nearly added “statement” as in “revision date of the most recent revision 
> statement”. I would certainly be happy with that change.
> I don’t really like “higher value” because that makes it sounds like a 
> numeric value. However, no-one has commented on this and I guess it’s 
> unambiguous. So let fido sleep on.
>
> Comments?
>
> Thanks,
> William
>
>> On 16 Aug 2016, at 19:02, Kent Watsen  wrote:
>> 
>> Hi William,
>> 
>> Do you want to take a stab on consolidating on the comments into new 
>> proposed draft-text?  - there were two proposals put out before, and a 
>> number of refinements since, but I’m unsure which were picked up or not.  
>> Since you raised this issue originally, if would be helpful to get your 
>> current take on it.
>> 
>> Thanks,
>> Kent
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

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

Re: [netmod] YANG 1.1 bug fix last call (was YANG 1.1: XML naming restriction)

[Jernej Tuljak]

While you are at it, there seems to be an orphaned production in the grammar 
(rfc6020bis-14):

   boolean-operator = and-keyword / or-keyword

It is probably a leftover from previous versions of if-feature-expr.
 
Jernej


> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Juergen
> Schoenwaelder
> Sent: Thursday, August 18, 2016 12:02 PM
> To: netmod@ietf.org
> Subject: [netmod] YANG 1.1 bug fix last call (was YANG 1.1: XML naming
> restriction)
> 
> Hi,
> 
> as discussed in the thread 'YANG 1.1: XML naming restriction', it
> seems that the restriction that identifiers may not start with "xml"
> is not necessary according to XML 1.0 (5th edition). In addition, it
> seems the YANG 1.1 specification should have an explicit normative
> reference to the XML specification it is based on. The suggested
> document changes are detailed below (thanks to Martin for writing this
> up). Please let the WG know by August 24th if you object against
> implementing this change before YANG 1.1 is published.
> 
> /js (with my RFC6020bis document shepherd hat on)
> 
> Section 1:
> 
> OLD:
> 
>This document describes the syntax and semantics of version 1.1 of
>the YANG language.  It also describes how a data model defined in a
>YANG module is encoded in the Extensible Markup Language (XML), and
> 
> NEW:
> 
>This document describes the syntax and semantics of version 1.1 of
>the YANG language.  It also describes how a data model defined in a
>YANG module is encoded in the Extensible Markup Language (XML)
>[XML], and
> 
> 
> Section 1.1:
> 
> OLD:
> 
>o  Allow type empty in a key.
> 
>The following changes have been done to the NETCONF mapping:
> 
> NEW:
> 
>o  Allow type empty in a key.
> 
>o  Removed the restriction that identifiers could not start with
>   the characters "xml".
> 
>The following changes have been done to the NETCONF mapping:
> 
> 
> Section 14:
> 
> OLD:
> 
>;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))
>identifier  = (ALPHA / "_")
>  *(ALPHA / DIGIT / "_" / "-" / ".")
> 
> NEW:
> 
>identifier  = (ALPHA / "_")
>  *(ALPHA / DIGIT / "_" / "-" / ".")
> 
> 
> Section 21.1:
> 
> NEW:
> 
>[XML]  Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
>   F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
>   Edition)", World Wide Web Consortium Recommendation REC-
>   xml-20081126, November 2008,
>   .
> 
> 
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[William Lupton]

Kent, all,

OK :). I will take Lada’s update to my Monday text as a baseline and will give 
my proposed new text without further ado, followed by rationale.

BASELINE:

It is not required to keep the revision history of unpublished versions (e.g., 
Internet-Drafts). That is, within a sequence of unpublished versions, only the 
most recent revision MAY be recorded in the module or submodule. However, the 
revision date of the most recent revision MUST be updated to a higher value 
each time a new version (e.g., of the Internet-Draft) is posted.

NEW:

It is not required to keep the full revision history of draft versions (e.g., 
modules contained within Internet-Drafts). That is, within a sequence of draft 
versions, only the most recent revision need be recorded in the module. 
However, if the module has changed, the revision date of the most recent 
revision MUST be updated to a higher value whenever a new version is made 
available (e.g., via a new version of an Internet-Draft).

—— 

The main comments and suggestions on the baseline text were:
Why say MAY rather than MUST? Suggestion to say “need” to avoid difficulty with 
“only” and “MAY”.
Should be more precise re the difference between a draft and a module contained 
within a draft.
Should allow or encourage the module revision date to be bumped only if the 
YANG has changed (or on the containing draft becoming a standard).
Discussion of “published” / “posted” etc., and their meanings in an IETF 
context.
Support for the principle that the text should be both general (applying to all 
organisations) and specific (applying to IETF) and note that IETF-specific text 
should be parenthesised.
Assertion that all publicly-available “adopted” modules (whether draft or 
standard) must bump revision dates if the YANG changes.

Here are a few notes to forestall some of your possible comments:
I didn’t mention submodules, because of the generic (Section 2.3) note that 
“module” means “module or submodule” unless specifically discussing submodules.
I didn’t mention RFC publication as a special case (revision date MUST be 
unconditionally updated) because this paragraph is only about drafts. I assume 
that requirements governing modules in RFCs are already covered elsewhere.
I hope that I avoided IETF-emotive terms outside the parentheses, e.g I used 
the terms “draft” and “made available”.
I nearly added “statement” as in “revision date of the most recent revision 
statement”. I would certainly be happy with that change.
I don’t really like “higher value” because that makes it sounds like a numeric 
value. However, no-one has commented on this and I guess it’s unambiguous. So 
let fido sleep on.

Comments?

Thanks,
William

> On 16 Aug 2016, at 19:02, Kent Watsen  wrote:
> 
> Hi William,
> 
> Do you want to take a stab on consolidating on the comments into new proposed 
> draft-text?  - there were two proposals put out before, and a number of 
> refinements since, but I’m unsure which were picked up or not.  Since you 
> raised this issue originally, if would be helpful to get your current take on 
> it.
> 
> Thanks,
> Kent
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] YANG 1.1 bug fix last call (was YANG 1.1: XML naming restriction)

[Juergen Schoenwaelder]

Hi,

as discussed in the thread 'YANG 1.1: XML naming restriction', it
seems that the restriction that identifiers may not start with "xml"
is not necessary according to XML 1.0 (5th edition). In addition, it
seems the YANG 1.1 specification should have an explicit normative
reference to the XML specification it is based on. The suggested
document changes are detailed below (thanks to Martin for writing this
up). Please let the WG know by August 24th if you object against
implementing this change before YANG 1.1 is published.

/js (with my RFC6020bis document shepherd hat on)

Section 1:

OLD:

   This document describes the syntax and semantics of version 1.1 of
   the YANG language.  It also describes how a data model defined in a
   YANG module is encoded in the Extensible Markup Language (XML), and

NEW:

   This document describes the syntax and semantics of version 1.1 of
   the YANG language.  It also describes how a data model defined in a
   YANG module is encoded in the Extensible Markup Language (XML)
   [XML], and


Section 1.1:

OLD:

   o  Allow type empty in a key.

   The following changes have been done to the NETCONF mapping:

NEW:

   o  Allow type empty in a key.

   o  Removed the restriction that identifiers could not start with
  the characters "xml".

   The following changes have been done to the NETCONF mapping:


Section 14:

OLD:

   ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))
   identifier  = (ALPHA / "_")
 *(ALPHA / DIGIT / "_" / "-" / ".")

NEW:

   identifier  = (ALPHA / "_")
 *(ALPHA / DIGIT / "_" / "-" / ".")


Section 21.1:

NEW:

   [XML]  Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
  F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
  Edition)", World Wide Web Consortium Recommendation REC-
  xml-20081126, November 2008,
  .


-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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