Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

2018-03-01 Thread Kent Watsen
Thanks Clyde.

Benoit, it's ready now.

Kent // shepherd

On 3/1/18, 10:29 AM, "Clyde Wildes (cwildes)" 
<cwil...@cisco.com<mailto:cwil...@cisco.com>> wrote:

Kent,

I published a new draft that fixes the last two points.

Thanks,

Clyde

From: Kent Watsen <kwat...@juniper.net>
Date: Wednesday, February 28, 2018 at 10:11 AM
To: Mahesh Jethanandani <mjethanand...@gmail.com>
Cc: Clyde Wildes <cwil...@cisco.com>, "t.petch" <ie...@btconnect.com>, Yaron 
Sheffer <yaronf.i...@gmail.com>, Ron Bonica <rbon...@juniper.net>, NETMOD 
Working Group <netmod@ietf.org>, "Benoit Claise (bclaise)" <bcla...@cisco.com>
Subject: Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

[+benoit]

Mahesh,

That's fine, if we want to put the RFC Editor note into the Introduction, I see 
that you did the same in the ACL draft.  But there still remains the use of IP 
addresses (not hostnames) in examples and, if we're fixing that, let's please 
also fix the typo in the title of Section 1.4.

Clyde, can you please post a v23 that fixes these last two points?

Thanks,
Kent  // shepherd


On 2/23/18, 1:05 PM, "Mahesh Jethanandani" 
<mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>> wrote:

Kent,




On Feb 23, 2018, at 8:02 AM, Kent Watsen 
<kwat...@juniper.net<mailto:kwat...@juniper.net>> wrote:

Hi Clyde,

Looking at your diff, I see that you aligned the Usage Example text and artwork 
by making the artwork use the IP address from the text, but you should've 
instead used the hostname in both locations.  Please see section 3.6 here: 
https://www.ietf.org/standards/ids/checklist<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_standards_ids_checklist=DwMFAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=N9LJpCJBafHdUNdSOe63fe4yTYxK-wmVz_DgH1cnKjM=JrRJ2H8Pa9954dNFWzFQ0xW4hCYHxwnrMtFTBVZyvZI=>.

Also, I see that you moved the Editorial Note to Section 1.4 (along with a typo 
in the title, ooops).  This is fine, I guess, though I was thinking instead 
about something like a top-level "RFC Editor Considerations" near the end 
[hmmm, a budding BCP? ;)].  Actually, I wish you had explained that the text 
was not in the Abstract, but in a "" element, and it was just a rendering 
issue.  It's actually common to use the  element for this purpose (sorry 
for not recognizing it before). Please also either fix the typo or, better, 
move the section back to the  element.

I had recommended the move of the note from abstract section to the end of the 
Introduction section. Abstracts cannot have cross-references in them, which the 
note had. And that was one of the OPS-DIR comments too.





Kent // shepherd


= original message =

Kent, Tom, Yaron, and Ron,

A new version of the draft-ietf-netmod-syslog-model has been published that 
addresses your concerns.

Thanks,



Clyde



On 2/20/18, 9:06 AM, "netmod on behalf of Kent Watsen" 
<netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org> on behalf of 
kwat...@juniper.net<mailto:kwat...@juniper.net>> wrote:












Kent









You illustrate beautifully the problem I would like a solution to.









The current thinking AFAICT is that tree-diagrams




should be an Informative Reference.









Therefore, the RFC Editor will not hold publication until an RFC number




is assigned.









Therefore, a note asking the I-D reference to be updated to reflect the




assigned RFC number is null - the RFC can be published with the




reference as an i-d and not as an RFC which is what I expect the RFC




Editor to do.









QED





   Except I know that this draft will be stuck in MISREF state and tree-diagrams

   will in fact be assigned an RFC number by the time this draft is published.



   K.








Note that this is not the case of a Normative i-d reference being buried




in the YANG module and not being.noticed by the RFC Editor; that problem




I am content with.














Tom Petch

























Please also address these issues when posting -21 to address Benoit's

   issues.  Please post -21 ASAP as Benoit has already placed this draft on

   the IESG telechat in a couple weeks.









Thanks,




Kent // shepherd














On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"

   
<netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org><mailto:netmod-boun...@ietf.org>
 on behalf of

   bcla...@cisco.com<mailto:bcla...@cisco.com><mailto:bcla...@cisco.com>> wrote:









Dear all,









- the draft is NMDA compliant, right? It should be mentioned.




Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro









  The YANG model in this document conforms to the Network Management









  Datastore Architecture defined in

   I-D.ietf-n

Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

2018-03-01 Thread Clyde Wildes (cwildes)
Kent,

I published a new draft that fixes the last two points.

Thanks,

Clyde

From: Kent Watsen <kwat...@juniper.net>
Date: Wednesday, February 28, 2018 at 10:11 AM
To: Mahesh Jethanandani <mjethanand...@gmail.com>
Cc: Clyde Wildes <cwil...@cisco.com>, "t.petch" <ie...@btconnect.com>, Yaron 
Sheffer <yaronf.i...@gmail.com>, Ron Bonica <rbon...@juniper.net>, NETMOD 
Working Group <netmod@ietf.org>, "Benoit Claise (bclaise)" <bcla...@cisco.com>
Subject: Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

[+benoit]

Mahesh,

That's fine, if we want to put the RFC Editor note into the Introduction, I see 
that you did the same in the ACL draft.  But there still remains the use of IP 
addresses (not hostnames) in examples and, if we're fixing that, let's please 
also fix the typo in the title of Section 1.4.

Clyde, can you please post a v23 that fixes these last two points?

Thanks,
Kent  // shepherd


On 2/23/18, 1:05 PM, "Mahesh Jethanandani" 
<mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>> wrote:

Kent,



On Feb 23, 2018, at 8:02 AM, Kent Watsen 
<kwat...@juniper.net<mailto:kwat...@juniper.net>> wrote:

Hi Clyde,

Looking at your diff, I see that you aligned the Usage Example text and artwork 
by making the artwork use the IP address from the text, but you should've 
instead used the hostname in both locations.  Please see section 3.6 here: 
https://www.ietf.org/standards/ids/checklist<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_standards_ids_checklist=DwMFAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=N9LJpCJBafHdUNdSOe63fe4yTYxK-wmVz_DgH1cnKjM=JrRJ2H8Pa9954dNFWzFQ0xW4hCYHxwnrMtFTBVZyvZI=>.

Also, I see that you moved the Editorial Note to Section 1.4 (along with a typo 
in the title, ooops).  This is fine, I guess, though I was thinking instead 
about something like a top-level "RFC Editor Considerations" near the end 
[hmmm, a budding BCP? ;)].  Actually, I wish you had explained that the text 
was not in the Abstract, but in a "" element, and it was just a rendering 
issue.  It's actually common to use the  element for this purpose (sorry 
for not recognizing it before). Please also either fix the typo or, better, 
move the section back to the  element.

I had recommended the move of the note from abstract section to the end of the 
Introduction section. Abstracts cannot have cross-references in them, which the 
note had. And that was one of the OPS-DIR comments too.




Kent // shepherd


= original message =

Kent, Tom, Yaron, and Ron,

A new version of the draft-ietf-netmod-syslog-model has been published that 
addresses your concerns.

Thanks,



Clyde



On 2/20/18, 9:06 AM, "netmod on behalf of Kent Watsen" 
<netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org> on behalf of 
kwat...@juniper.net<mailto:kwat...@juniper.net>> wrote:











Kent







You illustrate beautifully the problem I would like a solution to.







The current thinking AFAICT is that tree-diagrams



should be an Informative Reference.







Therefore, the RFC Editor will not hold publication until an RFC number



is assigned.







Therefore, a note asking the I-D reference to be updated to reflect the



assigned RFC number is null - the RFC can be published with the



reference as an i-d and not as an RFC which is what I expect the RFC



Editor to do.







QED





   Except I know that this draft will be stuck in MISREF state and tree-diagrams

   will in fact be assigned an RFC number by the time this draft is published.



   K.







Note that this is not the case of a Normative i-d reference being buried



in the YANG module and not being.noticed by the RFC Editor; that problem



I am content with.











Tom Petch























Please also address these issues when posting -21 to address Benoit's

   issues.  Please post -21 ASAP as Benoit has already placed this draft on

   the IESG telechat in a couple weeks.







Thanks,



Kent // shepherd











On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"

   
<netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org><mailto:netmod-boun...@ietf.org>
 on behalf of

   bcla...@cisco.com<mailto:bcla...@cisco.com><mailto:bcla...@cisco.com>> wrote:







Dear all,







- the draft is NMDA compliant, right? It should be mentioned.



Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro







  The YANG model in this document conforms to the Network Management







  Datastore Architecture defined in

   I-D.ietf-netmod-revised-datastores.











- As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams]

   should be an informative reference, not normative.







- Editorial:



OLD:



This draft add

Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

2018-02-28 Thread Kent Watsen
[+benoit]

Mahesh,

That's fine, if we want to put the RFC Editor note into the Introduction, I see 
that you did the same in the ACL draft.  But there still remains the use of IP 
addresses (not hostnames) in examples and, if we're fixing that, let's please 
also fix the typo in the title of Section 1.4.

Clyde, can you please post a v23 that fixes these last two points?

Thanks,
Kent  // shepherd


On 2/23/18, 1:05 PM, "Mahesh Jethanandani" 
> wrote:

Kent,


On Feb 23, 2018, at 8:02 AM, Kent Watsen 
> wrote:

Hi Clyde,

Looking at your diff, I see that you aligned the Usage Example text and artwork 
by making the artwork use the IP address from the text, but you should've 
instead used the hostname in both locations.  Please see section 3.6 here: 
https://www.ietf.org/standards/ids/checklist.

Also, I see that you moved the Editorial Note to Section 1.4 (along with a typo 
in the title, ooops).  This is fine, I guess, though I was thinking instead 
about something like a top-level "RFC Editor Considerations" near the end 
[hmmm, a budding BCP? ;)].  Actually, I wish you had explained that the text 
was not in the Abstract, but in a "" element, and it was just a rendering 
issue.  It's actually common to use the  element for this purpose (sorry 
for not recognizing it before). Please also either fix the typo or, better, 
move the section back to the  element.

I had recommended the move of the note from abstract section to the end of the 
Introduction section. Abstracts cannot have cross-references in them, which the 
note had. And that was one of the OPS-DIR comments too.



Kent // shepherd


= original message =

Kent, Tom, Yaron, and Ron,

A new version of the draft-ietf-netmod-syslog-model has been published that 
addresses your concerns.

Thanks,



Clyde



On 2/20/18, 9:06 AM, "netmod on behalf of Kent Watsen" 
 on behalf of 
kwat...@juniper.net> wrote:










Kent





You illustrate beautifully the problem I would like a solution to.





The current thinking AFAICT is that tree-diagrams


should be an Informative Reference.





Therefore, the RFC Editor will not hold publication until an RFC number


is assigned.





Therefore, a note asking the I-D reference to be updated to reflect the


assigned RFC number is null - the RFC can be published with the


reference as an i-d and not as an RFC which is what I expect the RFC


Editor to do.





QED





   Except I know that this draft will be stuck in MISREF state and tree-diagrams

   will in fact be assigned an RFC number by the time this draft is published.



   K.






Note that this is not the case of a Normative i-d reference being buried


in the YANG module and not being.noticed by the RFC Editor; that problem


I am content with.








Tom Petch





















Please also address these issues when posting -21 to address Benoit's

   issues.  Please post -21 ASAP as Benoit has already placed this draft on

   the IESG telechat in a couple weeks.





Thanks,


Kent // shepherd








On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"

   

 on behalf of

   bcla...@cisco.com> wrote:





Dear all,





- the draft is NMDA compliant, right? It should be mentioned.


Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro





  The YANG model in this document conforms to the Network Management





  Datastore Architecture defined in

   I-D.ietf-netmod-revised-datastores.








- As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams]

   should be an informative reference, not normative.





- Editorial:


OLD:


This draft addresses the common leafs


NEW:


This document addresses the common leafs





Please publish a new version asap.


In the mean time, I'm sending this draft to IETF LC.





Regards, Benoit














   

   






___


netmod mailing list


netmod@ietf.org


https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=cJ7MVnQVc1hgxpVF7oYiVn6Rbm-Qf2dDyrfYhL-s9io=u0Hn9GkO-B0jUGm1MnIQ4x4AgIZNXHBIaZhTPmt3dC8=










   ___

   netmod mailing list

   

Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

2018-02-23 Thread Mahesh Jethanandani
Kent,

> On Feb 23, 2018, at 8:02 AM, Kent Watsen  wrote:
> 
> Hi Clyde,
> 
> Looking at your diff, I see that you aligned the Usage Example text and 
> artwork by making the artwork use the IP address from the text, but you 
> should've instead used the hostname in both locations.  Please see section 
> 3.6 here: https://www.ietf.org/standards/ids/checklist 
> .
> 
> Also, I see that you moved the Editorial Note to Section 1.4 (along with a 
> typo in the title, ooops).  This is fine, I guess, though I was thinking 
> instead about something like a top-level "RFC Editor Considerations" near the 
> end [hmmm, a budding BCP? ;)].  Actually, I wish you had explained that the 
> text was not in the Abstract, but in a "" element, and it was just a 
> rendering issue.  It's actually common to use the  element for this 
> purpose (sorry for not recognizing it before). Please also either fix the 
> typo or, better, move the section back to the  element.

I had recommended the move of the note from abstract section to the end of the 
Introduction section. Abstracts cannot have cross-references in them, which the 
note had. And that was one of the OPS-DIR comments too.

> 
> Kent // shepherd
> 
> 
> = original message =
> 
> Kent, Tom, Yaron, and Ron,
> 
> A new version of the draft-ietf-netmod-syslog-model has been published that 
> addresses your concerns.
> 
> Thanks,
> 
> 
> 
> Clyde
> 
> 
> 
> On 2/20/18, 9:06 AM, "netmod on behalf of Kent Watsen" 
>  on behalf of 
> kwat...@juniper.net > wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> Kent
> 
>> 
> 
>> You illustrate beautifully the problem I would like a solution to.
> 
>> 
> 
>> The current thinking AFAICT is that tree-diagrams
> 
>> should be an Informative Reference.
> 
>> 
> 
>> Therefore, the RFC Editor will not hold publication until an RFC number
> 
>> is assigned.
> 
>> 
> 
>> Therefore, a note asking the I-D reference to be updated to reflect the
> 
>> assigned RFC number is null - the RFC can be published with the
> 
>> reference as an i-d and not as an RFC which is what I expect the RFC
> 
>> Editor to do.
> 
>> 
> 
>> QED
> 
> 
> 
> 
> 
>Except I know that this draft will be stuck in MISREF state and 
> tree-diagrams
> 
>will in fact be assigned an RFC number by the time this draft is published.
> 
> 
> 
>K.
> 
> 
> 
> 
> 
>> Note that this is not the case of a Normative i-d reference being buried
> 
>> in the YANG module and not being.noticed by the RFC Editor; that problem
> 
>> I am content with.
> 
>> 
> 
>> 
> 
>> Tom Petch
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> 
> 
>> Please also address these issues when posting -21 to address Benoit's
> 
>issues.  Please post -21 ASAP as Benoit has already placed this draft on
> 
>the IESG telechat in a couple weeks.
> 
>> 
> 
>> Thanks,
> 
>> Kent // shepherd
> 
>> 
> 
>> 
> 
>> On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"
> 
> on behalf of
> 
>bcla...@cisco.com> wrote:
> 
>> 
> 
>> Dear all,
> 
>> 
> 
>> - the draft is NMDA compliant, right? It should be mentioned.
> 
>> Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro
> 
>> 
> 
>>   The YANG model in this document conforms to the Network Management
> 
>> 
> 
>>   Datastore Architecture defined in
> 
>I-D.ietf-netmod-revised-datastores.
> 
>> 
> 
>> 
> 
>> - As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams]
> 
>should be an informative reference, not normative.
> 
>> 
> 
>> - Editorial:
> 
>> OLD:
> 
>> This draft addresses the common leafs
> 
>> NEW:
> 
>> This document addresses the common leafs
> 
>> 
> 
>> Please publish a new version asap.
> 
>> In the mean time, I'm sending this draft to IETF LC.
> 
>> 
> 
>> Regards, Benoit
> 
>> 
> 
>> 
> 
>> 
> 
> 
> 
> 
> 
>
> 
>
> 
> 
> 
> 
> 
>> ___
> 
>> netmod mailing list
> 
>> netmod@ietf.org
> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=cJ7MVnQVc1hgxpVF7oYiVn6Rbm-Qf2dDyrfYhL-s9io=u0Hn9GkO-B0jUGm1MnIQ4x4AgIZNXHBIaZhTPmt3dC8=
> 
>> 
> 
> 
> 
> 
> 
> 
> 
>___
> 
>netmod mailing list
> 
>netmod@ietf.org
> 
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=vELsmeOQEHNm4fcyJJKG7EpwwzMBGc-MHvHhSPWRzro=jSGwP16XlM6ntMKUF3bkCAwRfRtRwATdly2BlUtx2RA=
>  
> 

Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

2018-02-23 Thread Kent Watsen
Hi Clyde,

Looking at your diff, I see that you aligned the Usage Example text and artwork 
by making the artwork use the IP address from the text, but you should've 
instead used the hostname in both locations.  Please see section 3.6 here: 
https://www.ietf.org/standards/ids/checklist.

Also, I see that you moved the Editorial Note to Section 1.4 (along with a typo 
in the title, ooops).  This is fine, I guess, though I was thinking instead 
about something like a top-level "RFC Editor Considerations" near the end 
[hmmm, a budding BCP? ;)].  Actually, I wish you had explained that the text 
was not in the Abstract, but in a "" element, and it was just a rendering 
issue.  It's actually common to use the  element for this purpose (sorry 
for not recognizing it before).  Please also either fix the typo or, better, 
move the section back to the  element.

Kent // shepherd


= original message =

Kent, Tom, Yaron, and Ron,

A new version of the draft-ietf-netmod-syslog-model has been published that 
addresses your concerns.

Thanks,



Clyde



On 2/20/18, 9:06 AM, "netmod on behalf of Kent Watsen"  wrote:









> Kent

> 

> You illustrate beautifully the problem I would like a solution to.

>

> The current thinking AFAICT is that tree-diagrams

> should be an Informative Reference.

>

> Therefore, the RFC Editor will not hold publication until an RFC number

> is assigned.

> 

> Therefore, a note asking the I-D reference to be updated to reflect the

> assigned RFC number is null - the RFC can be published with the

> reference as an i-d and not as an RFC which is what I expect the RFC

> Editor to do.

> 

> QED





Except I know that this draft will be stuck in MISREF state and 
tree-diagrams

will in fact be assigned an RFC number by the time this draft is published.



K.





> Note that this is not the case of a Normative i-d reference being buried

> in the YANG module and not being.noticed by the RFC Editor; that problem

> I am content with.

>

>

>Tom Petch

















>

> Please also address these issues when posting -21 to address Benoit's

issues.  Please post -21 ASAP as Benoit has already placed this draft on

the IESG telechat in a couple weeks.

>

> Thanks,

> Kent // shepherd

>

>

> On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"

 on behalf of

bcla...@cisco.com> wrote:

>

> Dear all,

>

> - the draft is NMDA compliant, right? It should be mentioned.

> Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro

>

>The YANG model in this document conforms to the Network Management

>

>Datastore Architecture defined in

I-D.ietf-netmod-revised-datastores.

>

>

> - As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams]

should be an informative reference, not normative.

>

> - Editorial:

> OLD:

> This draft addresses the common leafs

> NEW:

> This document addresses the common leafs

>

> Please publish a new version asap.

> In the mean time, I'm sending this draft to IETF LC.

>

> Regards, Benoit

>

>

>













> ___

> netmod mailing list

> netmod@ietf.org

> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=cJ7MVnQVc1hgxpVF7oYiVn6Rbm-Qf2dDyrfYhL-s9io=u0Hn9GkO-B0jUGm1MnIQ4x4AgIZNXHBIaZhTPmt3dC8=

>







___

netmod mailing list

netmod@ietf.org


https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=vELsmeOQEHNm4fcyJJKG7EpwwzMBGc-MHvHhSPWRzro=jSGwP16XlM6ntMKUF3bkCAwRfRtRwATdly2BlUtx2RA=







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


Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

2018-02-22 Thread Benoit Claise

On 2/22/2018 11:49 AM, t.petch wrote:

- Original Message -
From: "Kent Watsen" 
To: "t.petch" ; "NETMOD Working Group"

Sent: Tuesday, February 20, 2018 5:06 PM

Kent

You illustrate beautifully the problem I would like a solution to.

The current thinking AFAICT is that tree-diagrams
should be an Informative Reference.

Therefore, the RFC Editor will not hold publication until an RFC

number

is assigned.

Therefore, a note asking the I-D reference to be updated to reflect

the

assigned RFC number is null - the RFC can be published with the
reference as an i-d and not as an RFC which is what I expect the RFC
Editor to do.

QED


Except I know that this draft will be stuck in MISREF state and

tree-diagrams

will in fact be assigned an RFC number by the time this draft is

published.

Kent

Corner case:-)
Note that, for this corner case, the IESG agreed for the tree-diagrams 
to go through expedited processing.
Even if this is an informative reference, it's nicer to get an RFC as a 
reference.


Regards, Benoit



You cannot know in general that drafts that appear as Informational
References and which are referenced from within a YANG module will be
published before the referencing I-D will be and so will have a RFC
number which can be inserted by the RFC Editor.




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


Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

2018-02-22 Thread t.petch
- Original Message -
From: "Clyde Wildes (cwildes)" 
Sent: Wednesday, February 21, 2018 9:21 PM

> Kent, Tom, Yaron, and Ron,
>
> A new version of the draft-ietf-netmod-syslog-model has been published
that addresses your concerns.

Optimist:-)

And we can always have fresh concerns:-(

I note that this I-D imports interface-ref  from RFC7223 while
draft-ietf-netmod-rfc7223bis
is in the RFC Edittor's queue.  I do not think that there is any reason
not to use the latter.

Tom Petch


>
> Thanks,
>
> Clyde
>
> On 2/20/18, 9:06 AM, "netmod on behalf of Kent Watsen"
 wrote:
>
>
>
>
> > Kent
> >
> > You illustrate beautifully the problem I would like a solution
to.
> >
> > The current thinking AFAICT is that tree-diagrams
> > should be an Informative Reference.
> >
> > Therefore, the RFC Editor will not hold publication until an RFC
number
> > is assigned.
> >
> > Therefore, a note asking the I-D reference to be updated to
reflect the
> > assigned RFC number is null - the RFC can be published with the
> > reference as an i-d and not as an RFC which is what I expect the
RFC
> > Editor to do.
> >
> > QED
>
>
> Except I know that this draft will be stuck in MISREF state and
tree-diagrams
> will in fact be assigned an RFC number by the time this draft is
published.
>
> K.
>
>
> > Note that this is not the case of a Normative i-d reference
being buried
> > in the YANG module and not being.noticed by the RFC Editor; that
problem
> > I am content with.
> >
> >
> >Tom Petch
>
>
>
>
>
>
>
>
> >
> > Please also address these issues when posting -21 to address
Benoit's
> issues.  Please post -21 ASAP as Benoit has already placed this
draft on
> the IESG telechat in a couple weeks.
> >
> > Thanks,
> > Kent // shepherd
> >
> >
> > On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"
>  on behalf
of
> bcla...@cisco.com> wrote:
> >
> > Dear all,
> >
> > - the draft is NMDA compliant, right? It should be mentioned.
> > Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro
> >
> >The YANG model in this document conforms to the Network
Management
> >
> >Datastore Architecture defined in
> I-D.ietf-netmod-revised-datastores.
> >
> >
> > - As mentioned in the writeup,
[I-D.ietf-netmod-yang-tree-diagrams]
> should be an informative reference, not normative.
> >
> > - Editorial:
> > OLD:
> > This draft addresses the common leafs
> > NEW:
> > This document addresses the common leafs
> >
> > Please publish a new version asap.
> > In the mean time, I'm sending this draft to IETF LC.
> >
> > Regards, Benoit
> >
> >
> >
>
>
> --
--
> 
>
>
> > ___
> > netmod mailing list
> > netmod@ietf.org
> >
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailma
n_listinfo_netmod=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI
=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=cJ7MVnQVc1hgxpVF7oYiVn6
Rbm-Qf2dDyrfYhL-s9io=u0Hn9GkO-B0jUGm1MnIQ4x4AgIZNXHBIaZhTPmt3dC8=
> >
>
>
>
> ___
> 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] AD review of draft-ietf-netmod-syslog-model-20

2018-02-22 Thread t.petch
- Original Message -
From: "Kent Watsen" 
To: "t.petch" ; "NETMOD Working Group"

Sent: Tuesday, February 20, 2018 5:06 PM
>
> > Kent
> >
> > You illustrate beautifully the problem I would like a solution to.
> >
> > The current thinking AFAICT is that tree-diagrams
> > should be an Informative Reference.
> >
> > Therefore, the RFC Editor will not hold publication until an RFC
number
> > is assigned.
> >
> > Therefore, a note asking the I-D reference to be updated to reflect
the
> > assigned RFC number is null - the RFC can be published with the
> > reference as an i-d and not as an RFC which is what I expect the RFC
> > Editor to do.
> >
> > QED
>
>
> Except I know that this draft will be stuck in MISREF state and
tree-diagrams
> will in fact be assigned an RFC number by the time this draft is
published.

Kent

Corner case:-)

You cannot know in general that drafts that appear as Informational
References and which are referenced from within a YANG module will be
published before the referencing I-D will be and so will have a RFC
number which can be inserted by the RFC Editor.

Tom Petch

> K.
>
>
> > Note that this is not the case of a Normative i-d reference being
buried
> > in the YANG module and not being.noticed by the RFC Editor; that
problem
> > I am content with.
> >
> >
> >Tom Petch
>
>
>
>
>
>
>
>
> >
> > Please also address these issues when posting -21 to address
Benoit's
> issues.  Please post -21 ASAP as Benoit has already placed this draft
on
> the IESG telechat in a couple weeks.
> >
> > Thanks,
> > Kent // shepherd
> >
> >
> > On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"
>  on behalf of
> bcla...@cisco.com> wrote:
> >
> > Dear all,
> >
> > - the draft is NMDA compliant, right? It should be mentioned.
> > Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro
> >
> >The YANG model in this document conforms to the Network
Management
> >
> >Datastore Architecture defined in
> I-D.ietf-netmod-revised-datastores.
> >
> >
> > - As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams]
> should be an informative reference, not normative.
> >
> > - Editorial:
> > OLD:
> > This draft addresses the common leafs
> > NEW:
> > This document addresses the common leafs
> >
> > Please publish a new version asap.
> > In the mean time, I'm sending this draft to IETF LC.
> >
> > Regards, Benoit
> >
> >
> >
>
>
> --
--
> 
>
>
> > ___
> > netmod mailing list
> > netmod@ietf.org
> >
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailma
n_listinfo_netmod=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI
=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=cJ7MVnQVc1hgxpVF7oYiVn6
Rbm-Qf2dDyrfYhL-s9io=u0Hn9GkO-B0jUGm1MnIQ4x4AgIZNXHBIaZhTPmt3dC8=
> >
>
>
>
>

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


Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

2018-02-21 Thread Clyde Wildes (cwildes)
Kent, Tom, Yaron, and Ron,

A new version of the draft-ietf-netmod-syslog-model has been published that 
addresses your concerns.

Thanks,

Clyde

On 2/20/18, 9:06 AM, "netmod on behalf of Kent Watsen"  wrote:




> Kent
> 
> You illustrate beautifully the problem I would like a solution to.
>
> The current thinking AFAICT is that tree-diagrams
> should be an Informative Reference.
>
> Therefore, the RFC Editor will not hold publication until an RFC number
> is assigned.
> 
> Therefore, a note asking the I-D reference to be updated to reflect the
> assigned RFC number is null - the RFC can be published with the
> reference as an i-d and not as an RFC which is what I expect the RFC
> Editor to do.
> 
> QED


Except I know that this draft will be stuck in MISREF state and 
tree-diagrams
will in fact be assigned an RFC number by the time this draft is published.

K.


> Note that this is not the case of a Normative i-d reference being buried
> in the YANG module and not being.noticed by the RFC Editor; that problem
> I am content with.
>
>
>Tom Petch








>
> Please also address these issues when posting -21 to address Benoit's
issues.  Please post -21 ASAP as Benoit has already placed this draft on
the IESG telechat in a couple weeks.
>
> Thanks,
> Kent // shepherd
>
>
> On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"
 on behalf of
bcla...@cisco.com> wrote:
>
> Dear all,
>
> - the draft is NMDA compliant, right? It should be mentioned.
> Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro
>
>The YANG model in this document conforms to the Network Management
>
>Datastore Architecture defined in
I-D.ietf-netmod-revised-datastores.
>
>
> - As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams]
should be an informative reference, not normative.
>
> - Editorial:
> OLD:
> This draft addresses the common leafs
> NEW:
> This document addresses the common leafs
>
> Please publish a new version asap.
> In the mean time, I'm sending this draft to IETF LC.
>
> Regards, Benoit
>
>
>






> ___
> netmod mailing list
> netmod@ietf.org
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=cJ7MVnQVc1hgxpVF7oYiVn6Rbm-Qf2dDyrfYhL-s9io=u0Hn9GkO-B0jUGm1MnIQ4x4AgIZNXHBIaZhTPmt3dC8=
>



___
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] AD review of draft-ietf-netmod-syslog-model-20

2018-02-20 Thread Kent Watsen



> Kent
> 
> You illustrate beautifully the problem I would like a solution to.
>
> The current thinking AFAICT is that tree-diagrams
> should be an Informative Reference.
>
> Therefore, the RFC Editor will not hold publication until an RFC number
> is assigned.
> 
> Therefore, a note asking the I-D reference to be updated to reflect the
> assigned RFC number is null - the RFC can be published with the
> reference as an i-d and not as an RFC which is what I expect the RFC
> Editor to do.
> 
> QED


Except I know that this draft will be stuck in MISREF state and tree-diagrams
will in fact be assigned an RFC number by the time this draft is published.

K.


> Note that this is not the case of a Normative i-d reference being buried
> in the YANG module and not being.noticed by the RFC Editor; that problem
> I am content with.
>
>
>Tom Petch








>
> Please also address these issues when posting -21 to address Benoit's
issues.  Please post -21 ASAP as Benoit has already placed this draft on
the IESG telechat in a couple weeks.
>
> Thanks,
> Kent // shepherd
>
>
> On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"
 on behalf of
bcla...@cisco.com> wrote:
>
> Dear all,
>
> - the draft is NMDA compliant, right? It should be mentioned.
> Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro
>
>The YANG model in this document conforms to the Network Management
>
>Datastore Architecture defined in
I-D.ietf-netmod-revised-datastores.
>
>
> - As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams]
should be an informative reference, not normative.
>
> - Editorial:
> OLD:
> This draft addresses the common leafs
> NEW:
> This document addresses the common leafs
>
> Please publish a new version asap.
> In the mean time, I'm sending this draft to IETF LC.
>
> Regards, Benoit
>
>
>






> ___
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=cJ7MVnQVc1hgxpVF7oYiVn6Rbm-Qf2dDyrfYhL-s9io=u0Hn9GkO-B0jUGm1MnIQ4x4AgIZNXHBIaZhTPmt3dC8=
>



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


Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

2018-02-20 Thread t.petch
- Original Message -
From: "Kent Watsen" 
Sent: Wednesday, February 14, 2018 6:03 PM

> Buggers, I thought we caught that tree-diagrams informative/normative
thing before.
>
> Regardless, Clyde, please note that I think I was wrong before from
the shepherd write-up regarding idnits having a problem:
>
> """
>   == Unused Reference: 'I-D.ietf-netconf-keystore' is defined on line
1340,
>  but no explicit reference was found in the text
>  '[I-D.ietf-netconf-keystore] Watsen, K., "YANG Data Model for a
"Keys...'
>
>This is a bug in idnits, whereby a reference that splits two lines
is
>not found.
> """
>
> Looking at the XML, it seems that references are not specified
correctly.
>
> CURRENT:
>
> This module imports typedefs from [RFC7223], groupings from
> [I-D.ietf-netconf-keystore], and
[I-D.ietf-netconf-tls-client-server], and it references [RFC5424],
> [RFC5425], [RFC5426], and [RFC5848] and [Std-1003.1-2008].
>
> SHOULD BE:
>
> This module imports typedefs from ,
groupings from
> , and , and it references ,
> , , and  and .
>
> Right?
>
> And while you're at it, please update the reference to the
tree-diagrams draft (-06 is current).  Also, missing is an RFC Editor
note requesting that the I-D reference to be updated to reflect the
assigned RFC number.

Kent

You illustrate beautifully the problem I would like a solution to.

The current thinking AFAICT is that
tree-diagrams
should be an Informative Reference.

Therefore, the RFC Editor will not hold publication until an RFC number
is assigned.

Therefore, a note asking the I-D reference to be updated to reflect the
assigned RFC number is null - the RFC can be published with the
reference as an i-d and not as an RFC which is what I expect the RFC
Editor to do.

QED

Note that this is not the case of a Normative i-d reference being buried
in the YANG module and not being.noticed by the RFC Editor; that problem
I am content with.


Tom Petch








>
> Please also address these issues when posting -21 to address Benoit's
issues.  Please post -21 ASAP as Benoit has already placed this draft on
the IESG telechat in a couple weeks.
>
> Thanks,
> Kent // shepherd
>
>
> On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"
 on behalf of
bcla...@cisco.com> wrote:
>
> Dear all,
>
> - the draft is NMDA compliant, right? It should be mentioned.
> Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro
>
>The YANG model in this document conforms to the Network Management
>
>Datastore Architecture defined in
I-D.ietf-netmod-revised-datastores.
>
>
> - As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams]
should be an informative reference, not normative.
>
> - Editorial:
> OLD:
> This draft addresses the common leafs
> NEW:
> This document addresses the common leafs
>
> Please publish a new version asap.
> In the mean time, I'm sending this draft to IETF LC.
>
> Regards, Benoit
>
>
>






> ___
> 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] AD review of draft-ietf-netmod-syslog-model-20

2018-02-14 Thread Kent Watsen
Buggers, I thought we caught that tree-diagrams informative/normative thing 
before.

Regardless, Clyde, please note that I think I was wrong before from the 
shepherd write-up regarding idnits having a problem:

"""
  == Unused Reference: 'I-D.ietf-netconf-keystore' is defined on line 1340,
 but no explicit reference was found in the text
 '[I-D.ietf-netconf-keystore] Watsen, K., "YANG Data Model for a "Keys...'

   This is a bug in idnits, whereby a reference that splits two lines is
   not found.
"""

Looking at the XML, it seems that references are not specified correctly.

CURRENT:

This module imports typedefs from [RFC7223], groupings from
[I-D.ietf-netconf-keystore], and [I-D.ietf-netconf-tls-client-server], 
and it references [RFC5424],
[RFC5425], [RFC5426], and [RFC5848] and [Std-1003.1-2008].

SHOULD BE:

This module imports typedefs from , 
groupings from
, and , and it references ,
, , and  and .

Right?

And while you're at it, please update the reference to the tree-diagrams draft 
(-06 is current).  Also, missing is an RFC Editor note requesting that the I-D 
reference to be updated to reflect the assigned RFC number.

Please also address these issues when posting -21 to address Benoit's issues.  
Please post -21 ASAP as Benoit has already placed this draft on the IESG 
telechat in a couple weeks.

Thanks,
Kent // shepherd


On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise" 
 on behalf of 
bcla...@cisco.com> wrote:

Dear all,

- the draft is NMDA compliant, right? It should be mentioned.
Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro

   The YANG model in this document conforms to the Network Management

   Datastore Architecture defined in I-D.ietf-netmod-revised-datastores.


- As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams] should be 
an informative reference, not normative.

- Editorial:
OLD:
This draft addresses the common leafs
NEW:
This document addresses the common leafs

Please publish a new version asap.
In the mean time, I'm sending this draft to IETF LC.

Regards, Benoit


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


[netmod] AD review of draft-ietf-netmod-syslog-model-20

2018-02-14 Thread Benoit Claise

Dear all,

- the draft is NMDA compliant, right? It should be mentioned.
Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro

   The YANG model in this document conforms to the Network Management
   Datastore Architecture defined in I-D.ietf-netmod-revised-datastores.

- As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams] 
should be an informative reference, not normative.


- Editorial:
OLD:
This draft addresses the common leafs
NEW:
This document addresses the common leafs

Please publish a new version asap.
In the mean time, I'm sending this draft to IETF LC.

Regards, Benoit

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