Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
"Clyde Wildes (cwildes)" writes: > Thanks for the simplification. I have incorporated this in the next > draft-ietf-netmod-syslog-model revision. Ah, thanks! Looking at -13, I see this: A syslog message is processed if: There is an element of facility-list (F, S) where the message facility matches F (if it is present) and the message severity matches S (if it is present) or the message text matches the regex pattern (if it is present) I think you want to move the line "and the message severity ..." to the left by two spaces so that the lines are aligned by how they are grouped by the logical operators. That would give: There is an element of facility-list (F, S) where the message facility matches F (if it is present) and the message severity matches S (if it is present) or the message text matches the regex pattern (if it is present) Dale ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Dale, Thanks for the simplification. I have incorporated this in the next draft-ietf-netmod-syslog-model revision. Regards, Clyde On 3/6/17, 12:53 PM, "Dale R. Worley" wrote: (We seem to be well beyond the original LC date, but this is only an editorial comment...) The algorithm in section 3 isn't clear to me (possibly because I'm not very familiar with syslog in practice): Selector processing (input is syslog message): 1. Loop through facility-list a. Facility match processing - continue to the next entry in the list if no match b. Severity compare processing - continue to the next list entry if no match c. Match - proceed with the action and exit further processing 2. Process pattern match if specified and if a match proceed with the action If I understand correctly, a message is processed if it matches any one element of facility-list OR the regexp. In that case, I think you could it clearer by writing the pseudocode in a style that is more functional than imperative: A syslog message is processed if there is an element of facility-list (F, S) where the message facility matches F (if it is present) and the message severity matches S (if it is present) or the message text matches the pattern (if it is present) Dale ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
(We seem to be well beyond the original LC date, but this is only an editorial comment...) The algorithm in section 3 isn't clear to me (possibly because I'm not very familiar with syslog in practice): Selector processing (input is syslog message): 1. Loop through facility-list a. Facility match processing - continue to the next entry in the list if no match b. Severity compare processing - continue to the next list entry if no match c. Match - proceed with the action and exit further processing 2. Process pattern match if specified and if a match proceed with the action If I understand correctly, a message is processed if it matches any one element of facility-list OR the regexp. In that case, I think you could it clearer by writing the pseudocode in a style that is more functional than imperative: A syslog message is processed if there is an element of facility-list (F, S) where the message facility matches F (if it is present) and the message severity matches S (if it is present) or the message text matches the pattern (if it is present) Dale ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Hi Kent, I would think option c is the preferable option. And I agree with your implied suggestion to accomplish this via references to the keystore. Option a could be a less-preferred-still-acceptable alternative. The case with multiple signers is a true corner case. I don’t think b is acceptable, frankly. --- Alex From: Kent Watsen [mailto:kwat...@juniper.net] Sent: Thursday, February 23, 2017 4:13 PM To: Alexander Clemm ; draft-ietf-netmod-syslog-mo...@ietf.org Cc: netmod@ietf.org Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 > > True, this is keystore territory, and I don’t think this should venture in > that direction – the [sic] > can be considered clearly out of scope. Why would it be out of scope? Seems like this is actually what you might want given what you wrote below... > However, what would actually make sense would be to offer a configuration > option that > clearly states which of the signature options (and signing material) should > be used. > Clearly the ability to configure this will be needed. I think I agree here but, if I understand you correctly, wouldn't this be best accomplished via references to keystore keys/certificates? > If you want to accommodate this, Actually, I'm just probing the issue. I was hoping the response was going to be "this was discussed by the working group here: " and we could move on. But since that does not seem to be the case, it would be good for the WG (not me) to decide if we want/need to accommodate this. What do people think? Options: a) leave as is (and document the shortcoming) b) remove signing-options (add back later when ready) c) address the issue now > you probably need to consider another modification to the model: It is > conceivable that there > could be multiple signers, and different signers might each use a different > option. Therefore, to > allow for differentiation by signer, you might want to consider introducing a > corresponding > parameter under a list of signers. (You could even move the configuration > parameters into this > list, although frankly I would opt to keep those parameters global (and the > use of the model > simple), not per-signer.) True, and potentially a reason to not go with (a) as, with that option, it may not be easy to add in this kind of flexibility later in a backwards-compatible manner. Thanks, Kent// shepherd ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
> > True, this is keystore territory, and I don’t think this should venture in > that direction – the [sic] > can be considered clearly out of scope. Why would it be out of scope? Seems like this is actually what you might want given what you wrote below... > However, what would actually make sense would be to offer a configuration > option that > clearly states which of the signature options (and signing material) should > be used. > Clearly the ability to configure this will be needed. I think I agree here but, if I understand you correctly, wouldn't this be best accomplished via references to keystore keys/certificates? > If you want to accommodate this, Actually, I'm just probing the issue. I was hoping the response was going to be "this was discussed by the working group here: " and we could move on. But since that does not seem to be the case, it would be good for the WG (not me) to decide if we want/need to accommodate this. What do people think? Options: a) leave as is (and document the shortcoming) b) remove signing-options (add back later when ready) c) address the issue now > you probably need to consider another modification to the model: It is > conceivable that there > could be multiple signers, and different signers might each use a different > option. Therefore, to > allow for differentiation by signer, you might want to consider introducing a > corresponding > parameter under a list of signers. (You could even move the configuration > parameters into this > list, although frankly I would opt to keep those parameters global (and the > use of the model > simple), not per-signer.) True, and potentially a reason to not go with (a) as, with that option, it may not be easy to add in this kind of flexibility later in a backwards-compatible manner. Thanks, Kent// shepherd ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Hi Kent More responses, --- Alex From: Kent Watsen [mailto:kwat...@juniper.net] Sent: Thursday, February 23, 2017 2:52 PM To: Alexander Clemm ; draft-ietf-netmod-syslog-mo...@ietf.org Cc: netmod@ietf.org Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 >> - should the leafs not starting with "cert-" start with "sig-", to better >> match section 6.1? > > No, that would actually match less and be misleading. The parameters > mentioned in 6.1.1 > refer to configuration parameters for certificate blocks, and are accordingly > prefixed “cert”. The > parameters mentioned in 6.1.2 are related to Signature Blocks and are > accordingly prefixed with > “sig” (sigMaxDelay, sigNumberResends, sigREsendDelay, and sigResendCount). > So, you might > actually want to consider prefixing max-delay, number-resends, resend-delay, > and resend-count > with“sig-“. Exactly, we agree. These were the leafs I meant by "not starting with 'cert-' ". Ah, okay. Yes, we agree; I misunderstood your earlier sentence. > Syslog-sign does not specify how these types got there and what key material > they > used. Now, if you wanted to manage that as well, sure, but now you would be > getting > into TLS territory as you mention and I would think this should be kept > outside the > scope. That Syslog-sign doesn't specify this is a good response as well. But answer me honestly, isn't it something that a device would have to have configured and, if so, wouldn't it make most sense for that configuration to be in this module? FWIW, I don't think that it's TLS-territory so much as keystore-territory. True, this is keystore territory, and I don’t think this should venture in that direction – the can be considered clearly out of scope. However, what would actually make sense would be to offer a configuration option that clearly states which of the signature options (and signing material) should be used.Clearly the ability to configure this will be needed. If you want to accommodate this, you probably need to consider another modification to the model: It is conceivable that there could be multiple signers, and different signers might each use a different option. Therefore, to allow for differentiation by signer, you might want to consider introducing a corresponding parameter under a list of signers. (You could even move the configuration parameters into this list, although frankly I would opt to keep those parameters global (and the use of the model simple), not per-signer.) Thanks, Kent// shepherd ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
>> - should the leafs not starting with "cert-" start with "sig-", to better >> match section 6.1? > > No, that would actually match less and be misleading. The parameters > mentioned in 6.1.1 > refer to configuration parameters for certificate blocks, and are accordingly > prefixed “cert”. The > parameters mentioned in 6.1.2 are related to Signature Blocks and are > accordingly prefixed with > “sig” (sigMaxDelay, sigNumberResends, sigREsendDelay, and sigResendCount). > So, you might > actually want to consider prefixing max-delay, number-resends, resend-delay, > and resend-count > with“sig-“. Exactly, we agree. These were the leafs I meant by "not starting with 'cert-' ". > Syslog-sign does not specify how these types got there and what key material > they > used. Now, if you wanted to manage that as well, sure, but now you would be > getting > into TLS territory as you mention and I would think this should be kept > outside the > scope. That Syslog-sign doesn't specify this is a good response as well. But answer me honestly, isn't it something that a device would have to have configured and, if so, wouldn't it make most sense for that configuration to be in this module? FWIW, I don't think that it's TLS-territory so much as keystore-territory. Thanks, Kent// shepherd ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Thanks Alex, that was helpful. So then: - should the "signing-options" description statement mention "Section 6.1"? - should the leafs not starting with "cert-" start with "sig-", to better match section 6.1? Again, is there not a need to configure a private key to do the signing and/or the certificate to send? Recall, we took out the TLS transport from this draft because the model didn't support being able to configure similar things... Thanks, Kent On 2/23/17, 2:10 PM, "Alexander Clemm" mailto:alexander.cl...@huawei.com>> wrote: Hi, I am no an author, but I do have an opinion regarding the signed-messages feature. IMHO, this is something that needs to be definitely included as part of the draft. Syslog signing is a part of the suite of IETF standards-track RFCs geared towards syslog. Quite simply, I don’t think the YANG model would be complete without it. In short, don’t remove this from the YANG data model draft. RFC 5848 section 6.1 actually calls out the parameters that make sense for an implementation to make configurable, which are the ones supported in the model. Now, it is certainly possible to introduce more. It is conceivable for sign messages to go to a separate collector as you mention; however, in general they will go towards the same collector even although they will be used by a separate verification process used to verify and authenticate the other (non-sign) messages. Section 7 in RFC 5848 describes all this in detail. --- Alex From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen Sent: Wednesday, February 22, 2017 7:46 PM To: draft-ietf-netmod-syslog-mo...@ietf.org Cc: netmod@ietf.org Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 Authors, I was asked to do another YANG Doctor review on this module (in addition to Juergen's review back in 2015), and I'm also the shepherd for this draft, so I decided to give the draft a fresh reading and had some preliminary questions (i.e., this is neither a doctor-review or a shepherd-review). I'm sending this to you now, as I know that you plan to put out an update shortly to address Andy's most recent comments. S2, last paragraph, is "conceptual layer" a term in 5424? If so, then make that more obvious. If not, then this sentence should be reworded to be more clear. S3, P2: s/The base model/This base model/ or just "This model"? Same issue just below Figure 1 (aside: should 'actions' be in quotes here?) S3, last paragraph, should "disable a facility" actually be "disable a filter", as it says in the YANG description statement? S4: Please remove the four "WG Chair" lines from the two modules. S4: Can you explain why there are two separate modules? - does the types module need to be imported by any future module? I see, SA.1, but this could be done as well with a single module. If there really is a need, then perhaps explain it in the draft? S4: Noticing the "signing-options" container. My first question was why isn’t something related to this in the security considerations section, but then I noticed that this module doesn't configure certificates or configure which signature blocks go to which collectors. Is this really fleshed out completely? Perhaps we should remove the signing-options container (and signed-messages feature)? S8.1 and S8.2: as written, these don't seem like "security considerations", maybe they should go into Appendix A (implementor [sic] guidelines)? Kent // pick a hat On 2/21/17, 6:10 PM, "Andy Bierman" mailto:a...@yumaworks.com>> wrote: Hi, Lots of improvement. Just some minor details I noticed... SYSLOG-MSG field: RFC 5424 is mentioned in the 2nd usage, not the first. Should be a citation -- SYSLOG-MSG field [RFC5424] Page header says 'Abbreviated Title' (the template placeholder text). I suggest 'Syslog Management' (consistent with RFC 8022) p5: The severity is one of syslogtypes:severity perhaps: The severity is one of: type "syslogtypes:severity" Actions are to log perhaps: Actions are used to log Andy On Tue, Feb 21, 2017 at 1:28 PM, Kent Watsen mailto:kwat...@juniper.net>> wrote: Thanks for the update you Clyde! Alex/Andy, since this update was made per comments you made during Last Call, can you please confirm that it does indeed address your concerns, and doesn't add any new ones? Thanks, Kent On 2/14/17, 8:31 AM, "netmod on behalf of Clyde Wildes (cwildes)" mailto:netmod-boun...@ietf.org> on behalf of cwil...@cisco.com<mailto:cwil...@cisco.com>> wrote: Hi, I just posted draft-ietf-netmod-syslog-model-12 which addresses the concerns that Alex and Andy raised in their review of draft 11. Changes from draft 11 to draft 12 can be s
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Hi, I am no an author, but I do have an opinion regarding the signed-messages feature. IMHO, this is something that needs to be definitely included as part of the draft. Syslog signing is a part of the suite of IETF standards-track RFCs geared towards syslog. Quite simply, I don’t think the YANG model would be complete without it. In short, don’t remove this from the YANG data model draft. RFC 5848 section 6.1 actually calls out the parameters that make sense for an implementation to make configurable, which are the ones supported in the model. Now, it is certainly possible to introduce more. It is conceivable for sign messages to go to a separate collector as you mention; however, in general they will go towards the same collector even although they will be used by a separate verification process used to verify and authenticate the other (non-sign) messages. Section 7 in RFC 5848 describes all this in detail. --- Alex From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen Sent: Wednesday, February 22, 2017 7:46 PM To: draft-ietf-netmod-syslog-mo...@ietf.org Cc: netmod@ietf.org Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 Authors, I was asked to do another YANG Doctor review on this module (in addition to Juergen's review back in 2015), and I'm also the shepherd for this draft, so I decided to give the draft a fresh reading and had some preliminary questions (i.e., this is neither a doctor-review or a shepherd-review). I'm sending this to you now, as I know that you plan to put out an update shortly to address Andy's most recent comments. S2, last paragraph, is "conceptual layer" a term in 5424? If so, then make that more obvious. If not, then this sentence should be reworded to be more clear. S3, P2: s/The base model/This base model/ or just "This model"? Same issue just below Figure 1 (aside: should 'actions' be in quotes here?) S3, last paragraph, should "disable a facility" actually be "disable a filter", as it says in the YANG description statement? S4: Please remove the four "WG Chair" lines from the two modules. S4: Can you explain why there are two separate modules? - does the types module need to be imported by any future module? I see, SA.1, but this could be done as well with a single module. If there really is a need, then perhaps explain it in the draft? S4: Noticing the "signing-options" container. My first question was why isn’t something related to this in the security considerations section, but then I noticed that this module doesn't configure certificates or configure which signature blocks go to which collectors. Is this really fleshed out completely? Perhaps we should remove the signing-options container (and signed-messages feature)? S8.1 and S8.2: as written, these don't seem like "security considerations", maybe they should go into Appendix A (implementor [sic] guidelines)? Kent // pick a hat On 2/21/17, 6:10 PM, "Andy Bierman" mailto:a...@yumaworks.com>> wrote: Hi, Lots of improvement. Just some minor details I noticed... SYSLOG-MSG field: RFC 5424 is mentioned in the 2nd usage, not the first. Should be a citation -- SYSLOG-MSG field [RFC5424] Page header says 'Abbreviated Title' (the template placeholder text). I suggest 'Syslog Management' (consistent with RFC 8022) p5: The severity is one of syslogtypes:severity perhaps: The severity is one of: type "syslogtypes:severity" Actions are to log perhaps: Actions are used to log Andy On Tue, Feb 21, 2017 at 1:28 PM, Kent Watsen mailto:kwat...@juniper.net>> wrote: Thanks for the update you Clyde! Alex/Andy, since this update was made per comments you made during Last Call, can you please confirm that it does indeed address your concerns, and doesn't add any new ones? Thanks, Kent On 2/14/17, 8:31 AM, "netmod on behalf of Clyde Wildes (cwildes)" mailto:netmod-boun...@ietf.org> on behalf of cwil...@cisco.com<mailto:cwil...@cisco.com>> wrote: Hi, I just posted draft-ietf-netmod-syslog-model-12 which addresses the concerns that Alex and Andy raised in their review of draft 11. Changes from draft 11 to draft 12 can be seen at this link: https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-syslog-model-11&url2=draft-ietf-netmod-syslog-model-12&difftype=--hwdiff Please review and comment. Thanks, Clyde From: "Clyde Wildes (cwildes)" mailto:cwil...@cisco.com>> Date: Wednesday, January 11, 2017 at 2:54 PM To: Andy Bierman mailto:a...@yumaworks.com>> Cc: Alex Campbell mailto:alex.campb...@aviatnet.com>>, "netmod@ietf.org<mailto:netmod@ietf.org>" mailto:netmod@ietf.org>> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 Any My comm
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Authors, I was asked to do another YANG Doctor review on this module (in addition to Juergen's review back in 2015), and I'm also the shepherd for this draft, so I decided to give the draft a fresh reading and had some preliminary questions (i.e., this is neither a doctor-review or a shepherd-review). I'm sending this to you now, as I know that you plan to put out an update shortly to address Andy's most recent comments. S2, last paragraph, is "conceptual layer" a term in 5424? If so, then make that more obvious. If not, then this sentence should be reworded to be more clear. S3, P2: s/The base model/This base model/ or just "This model"? Same issue just below Figure 1 (aside: should 'actions' be in quotes here?) S3, last paragraph, should "disable a facility" actually be "disable a filter", as it says in the YANG description statement? S4: Please remove the four "WG Chair" lines from the two modules. S4: Can you explain why there are two separate modules? - does the types module need to be imported by any future module? I see, SA.1, but this could be done as well with a single module. If there really is a need, then perhaps explain it in the draft? S4: Noticing the "signing-options" container. My first question was why isn’t something related to this in the security considerations section, but then I noticed that this module doesn't configure certificates or configure which signature blocks go to which collectors. Is this really fleshed out completely? Perhaps we should remove the signing-options container (and signed-messages feature)? S8.1 and S8.2: as written, these don't seem like "security considerations", maybe they should go into Appendix A (implementor [sic] guidelines)? Kent // pick a hat On 2/21/17, 6:10 PM, "Andy Bierman" mailto:a...@yumaworks.com>> wrote: Hi, Lots of improvement. Just some minor details I noticed... SYSLOG-MSG field: RFC 5424 is mentioned in the 2nd usage, not the first. Should be a citation -- SYSLOG-MSG field [RFC5424] Page header says 'Abbreviated Title' (the template placeholder text). I suggest 'Syslog Management' (consistent with RFC 8022) p5: The severity is one of syslogtypes:severity perhaps: The severity is one of: type "syslogtypes:severity" Actions are to log perhaps: Actions are used to log Andy On Tue, Feb 21, 2017 at 1:28 PM, Kent Watsen mailto:kwat...@juniper.net>> wrote: Thanks for the update you Clyde! Alex/Andy, since this update was made per comments you made during Last Call, can you please confirm that it does indeed address your concerns, and doesn't add any new ones? Thanks, Kent On 2/14/17, 8:31 AM, "netmod on behalf of Clyde Wildes (cwildes)" mailto:netmod-boun...@ietf.org> on behalf of cwil...@cisco.com<mailto:cwil...@cisco.com>> wrote: Hi, I just posted draft-ietf-netmod-syslog-model-12 which addresses the concerns that Alex and Andy raised in their review of draft 11. Changes from draft 11 to draft 12 can be seen at this link: https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-syslog-model-11&url2=draft-ietf-netmod-syslog-model-12&difftype=--hwdiff Please review and comment. Thanks, Clyde From: "Clyde Wildes (cwildes)" mailto:cwil...@cisco.com>> Date: Wednesday, January 11, 2017 at 2:54 PM To: Andy Bierman mailto:a...@yumaworks.com>> Cc: Alex Campbell mailto:alex.campb...@aviatnet.com>>, "netmod@ietf.org<mailto:netmod@ietf.org>" mailto:netmod@ietf.org>> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 Any My comments inline as [clyde2]… From: Andy Bierman mailto:a...@yumaworks.com>> Date: Saturday, December 31, 2016 at 8:24 AM To: "Clyde Wildes (cwildes)" mailto:cwil...@cisco.com>> Cc: Alex Campbell mailto:alex.campb...@aviatnet.com>>, "netmod@ietf.org<mailto:netmod@ietf.org>" mailto:netmod@ietf.org>> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 On Fri, Dec 30, 2016 at 10:16 AM, Clyde Wildes (cwildes) mailto:cwil...@cisco.com>> wrote: Hi Andy, Thanks for taking the time to review the model. My comments are inline as [clyde]… From: netmod mailto:netmod-boun...@ietf.org>> on behalf of Andy Bierman mailto:a...@yumaworks.com>> Date: Tuesday, December 27, 2016 at 3:04 PM To: Alex Campbell Cc: "netmod@ietf.org<mailto:netmod@ietf.org>" mailto:netmod@ietf.org>> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 Hi, I am also considering an implementation. I share the same concerns that Alex has brought up. Some detailed comments: 1) /syslog/actions: seems like everything is in this container. Why is it needed? Seems like it could be removed as it serves
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Hi, Lots of improvement. Just some minor details I noticed... SYSLOG-MSG field: RFC 5424 is mentioned in the 2nd usage, not the first. Should be a citation -- SYSLOG-MSG field [RFC5424] Page header says 'Abbreviated Title' (the template placeholder text). I suggest 'Syslog Management' (consistent with RFC 8022) p5: The severity is one of syslogtypes:severity perhaps: The severity is one of: type "syslogtypes:severity" Actions are to log perhaps: Actions are used to log Andy On Tue, Feb 21, 2017 at 1:28 PM, Kent Watsen wrote: > Thanks for the update you Clyde! > > > > Alex/Andy, since this update was made per comments you made during Last > Call, can you please confirm that it does indeed address your concerns, and > doesn't add any new ones? > > > > Thanks, > > Kent > > > > On 2/14/17, 8:31 AM, "netmod on behalf of Clyde Wildes (cwildes)" < > netmod-boun...@ietf.org on behalf of cwil...@cisco.com> wrote: > > > > Hi, > > > > I just posted draft-ietf-netmod-syslog-model-12 which addresses the > concerns that Alex and Andy raised in their review of draft 11. > > > > Changes from draft 11 to draft 12 can be seen at this link: > > https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-syslog- > model-11&url2=draft-ietf-netmod-syslog-model-12&difftype=--hwdiff > > > > Please review and comment. > > > > Thanks, > > > > Clyde > > > > *From: *"Clyde Wildes (cwildes)" > *Date: *Wednesday, January 11, 2017 at 2:54 PM > *To: *Andy Bierman > *Cc: *Alex Campbell , "netmod@ietf.org" < > netmod@ietf.org> > *Subject: *Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 > > > > Any > > > > My comments inline as [clyde2]… > > > > *From: *Andy Bierman > *Date: *Saturday, December 31, 2016 at 8:24 AM > *To: *"Clyde Wildes (cwildes)" > *Cc: *Alex Campbell , "netmod@ietf.org" < > netmod@ietf.org> > *Subject: *Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 > > > > > > > > On Fri, Dec 30, 2016 at 10:16 AM, Clyde Wildes (cwildes) < > cwil...@cisco.com> wrote: > > Hi Andy, > > > > Thanks for taking the time to review the model. > > > > My comments are inline as [clyde]… > > > > *From: *netmod on behalf of Andy Bierman < > a...@yumaworks.com> > *Date: *Tuesday, December 27, 2016 at 3:04 PM > *To: *Alex Campbell > *Cc: *"netmod@ietf.org" > *Subject: *Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 > > > > Hi, > > > > I am also considering an implementation. > > I share the same concerns that Alex has brought up. > > > > Some detailed comments: > > > > 1) /syslog/actions: seems like everything is in this container. > > Why is it needed? Seems like it could be removed as it serves no purpose > > > > [clyde] Although this model is currently designated as config only, we > could add operational data and rpc leaves in the future. The actions > container is to future-proof the model. > > > > 2) 8 features: the granularity seems wrong. The main container for each > section > > should have its own if-feature > > /console > > /buffer > > /file > > /remote > > > > [clyde] We have gone back and forth on this…some have complained that > there are too many features. I will be happy to add a feature for each > action. Note that we studied the implementation of each action by six > vendors including Linux and opted to not add features for actions > implemented by at least 3 vendors. Vendors not implementing an action could > create a deviation. > > > > > > I prefer 1 mandatory-to-implement and a minimal number of additional > options. > > > > /console > > /file > > /remote > > > > These are all mandatory-to-implement.. > > IMO only /file should be mandatory-to-implement. > > > > [clyde2] I will remove the buffer and session actions in the next draft > and will make the remaining three features. > > > > > > 3) What is the 'buffer' container for? > > How is the internal memory accessed by the client? > > > > [clyde] buffer is implemented by vendors typically for routers capable of > generating many syslog messages in event-storm bursts. Logging to memory > (aka buffer) allows the preservation of syslog messages which might > otherwise be lost. > > > > > > > > IMO it should be removed from the draft. > > We certa
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
I can confirm that this new draft addresses my concerns and doesn't add any new
ones.
From: Kent Watsen
Sent: Wednesday, 22 February 2017 10:28 a.m.
To: Clyde Wildes (cwildes); netmod@ietf.org
Cc: Andy Bierman; Alex Campbell
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Thanks for the update you Clyde!
Alex/Andy, since this update was made per comments you made during Last Call,
can you please confirm that it does indeed address your concerns, and doesn't
add any new ones?
Thanks,
Kent
On 2/14/17, 8:31 AM, "netmod on behalf of Clyde Wildes (cwildes)"
mailto:netmod-boun...@ietf.org> on behalf of
cwil...@cisco.com<mailto:cwil...@cisco.com>> wrote:
Hi,
I just posted draft-ietf-netmod-syslog-model-12 which addresses the concerns
that Alex and Andy raised in their review of draft 11.
Changes from draft 11 to draft 12 can be seen at this link:
https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-syslog-model-11&url2=draft-ietf-netmod-syslog-model-12&difftype=--hwdiff
Please review and comment.
Thanks,
Clyde
From: "Clyde Wildes (cwildes)"
Date: Wednesday, January 11, 2017 at 2:54 PM
To: Andy Bierman
Cc: Alex Campbell , "netmod@ietf.org"
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Any
My comments inline as [clyde2]…
From: Andy Bierman
Date: Saturday, December 31, 2016 at 8:24 AM
To: "Clyde Wildes (cwildes)"
Cc: Alex Campbell , "netmod@ietf.org"
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
On Fri, Dec 30, 2016 at 10:16 AM, Clyde Wildes (cwildes)
mailto:cwil...@cisco.com>> wrote:
Hi Andy,
Thanks for taking the time to review the model.
My comments are inline as [clyde]…
From: netmod mailto:netmod-boun...@ietf.org>> on
behalf of Andy Bierman mailto:a...@yumaworks.com>>
Date: Tuesday, December 27, 2016 at 3:04 PM
To: Alex Campbell
Cc: "netmod@ietf.org<mailto:netmod@ietf.org>"
mailto:netmod@ietf.org>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Hi,
I am also considering an implementation.
I share the same concerns that Alex has brought up.
Some detailed comments:
1) /syslog/actions: seems like everything is in this container.
Why is it needed? Seems like it could be removed as it serves no purpose
[clyde] Although this model is currently designated as config only, we could
add operational data and rpc leaves in the future. The actions container is to
future-proof the model.
2) 8 features: the granularity seems wrong. The main container for each section
should have its own if-feature
/console
/buffer
/file
/remote
[clyde] We have gone back and forth on this…some have complained that there are
too many features. I will be happy to add a feature for each action. Note that
we studied the implementation of each action by six vendors including Linux and
opted to not add features for actions implemented by at least 3 vendors.
Vendors not implementing an action could create a deviation.
I prefer 1 mandatory-to-implement and a minimal number of additional options.
/console
/file
/remote
These are all mandatory-to-implement..
IMO only /file should be mandatory-to-implement.
[clyde2] I will remove the buffer and session actions in the next draft and
will make the remaining three features.
3) What is the 'buffer' container for?
How is the internal memory accessed by the client?
[clyde] buffer is implemented by vendors typically for routers capable of
generating many syslog messages in event-storm bursts. Logging to memory (aka
buffer) allows the preservation of syslog messages which might otherwise be
lost.
IMO it should be removed from the draft.
We certainly have changed the IETF NM focus.
In SNMP-land we routinely left the configuration out of scope
and standardized the monitoring. Now we are standardizing
the configuration and leaving the monitoring out of scope?
I prefer complete standard solutions only.
There is no standard way to access the /console either.
Since the console provides "show log" I really do not see a need for
/buffer at all.
[clyde2] The buffer action will be removed.
A “show log” command is used to access the buffers. As this model is current
designed as a configuration only model, there is no operational leaves for show
log, or rpc leaves for clear log.
4) selector-facility: Seems like no-facilities servers the same purpose
as an empty facility-list. The choice is not needed; just use the
facility-list
[clyde] This was changed as a result of Alex’s feedback – please see my
response to him. The model will be changed to the following:
container selector {
description
"This container describes the log selector parameters
for syslog.";
list facility-list {
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Thanks for the update you Clyde!
Alex/Andy, since this update was made per comments you made during Last Call,
can you please confirm that it does indeed address your concerns, and doesn't
add any new ones?
Thanks,
Kent
On 2/14/17, 8:31 AM, "netmod on behalf of Clyde Wildes (cwildes)"
mailto:netmod-boun...@ietf.org> on behalf of
cwil...@cisco.com<mailto:cwil...@cisco.com>> wrote:
Hi,
I just posted draft-ietf-netmod-syslog-model-12 which addresses the concerns
that Alex and Andy raised in their review of draft 11.
Changes from draft 11 to draft 12 can be seen at this link:
https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-syslog-model-11&url2=draft-ietf-netmod-syslog-model-12&difftype=--hwdiff
Please review and comment.
Thanks,
Clyde
From: "Clyde Wildes (cwildes)"
Date: Wednesday, January 11, 2017 at 2:54 PM
To: Andy Bierman
Cc: Alex Campbell , "netmod@ietf.org"
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Any
My comments inline as [clyde2]…
From: Andy Bierman
Date: Saturday, December 31, 2016 at 8:24 AM
To: "Clyde Wildes (cwildes)"
Cc: Alex Campbell , "netmod@ietf.org"
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
On Fri, Dec 30, 2016 at 10:16 AM, Clyde Wildes (cwildes)
mailto:cwil...@cisco.com>> wrote:
Hi Andy,
Thanks for taking the time to review the model.
My comments are inline as [clyde]…
From: netmod mailto:netmod-boun...@ietf.org>> on
behalf of Andy Bierman mailto:a...@yumaworks.com>>
Date: Tuesday, December 27, 2016 at 3:04 PM
To: Alex Campbell
Cc: "netmod@ietf.org<mailto:netmod@ietf.org>"
mailto:netmod@ietf.org>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Hi,
I am also considering an implementation.
I share the same concerns that Alex has brought up.
Some detailed comments:
1) /syslog/actions: seems like everything is in this container.
Why is it needed? Seems like it could be removed as it serves no purpose
[clyde] Although this model is currently designated as config only, we could
add operational data and rpc leaves in the future. The actions container is to
future-proof the model.
2) 8 features: the granularity seems wrong. The main container for each section
should have its own if-feature
/console
/buffer
/file
/remote
[clyde] We have gone back and forth on this…some have complained that there are
too many features. I will be happy to add a feature for each action. Note that
we studied the implementation of each action by six vendors including Linux and
opted to not add features for actions implemented by at least 3 vendors.
Vendors not implementing an action could create a deviation.
I prefer 1 mandatory-to-implement and a minimal number of additional options.
/console
/file
/remote
These are all mandatory-to-implement..
IMO only /file should be mandatory-to-implement.
[clyde2] I will remove the buffer and session actions in the next draft and
will make the remaining three features.
3) What is the 'buffer' container for?
How is the internal memory accessed by the client?
[clyde] buffer is implemented by vendors typically for routers capable of
generating many syslog messages in event-storm bursts. Logging to memory (aka
buffer) allows the preservation of syslog messages which might otherwise be
lost.
IMO it should be removed from the draft.
We certainly have changed the IETF NM focus.
In SNMP-land we routinely left the configuration out of scope
and standardized the monitoring. Now we are standardizing
the configuration and leaving the monitoring out of scope?
I prefer complete standard solutions only.
There is no standard way to access the /console either.
Since the console provides "show log" I really do not see a need for
/buffer at all.
[clyde2] The buffer action will be removed.
A “show log” command is used to access the buffers. As this model is current
designed as a configuration only model, there is no operational leaves for show
log, or rpc leaves for clear log.
4) selector-facility: Seems like no-facilities servers the same purpose
as an empty facility-list. The choice is not needed; just use the
facility-list
[clyde] This was changed as a result of Alex’s feedback – please see my
response to him. The model will be changed to the following:
container selector {
description
"This container describes the log selector parameters
for syslog.";
list facility-list {
key facility;
description
"This list describes a collection of syslog
facilities and severities.";
leaf facility {
type union {
type identityref {
base syslogtypes:syslog-facility;
}
type enumeration {
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Hi,
I just posted draft-ietf-netmod-syslog-model-12 which addresses the concerns
that Alex and Andy raised in their review of draft 11.
Changes from draft 11 to draft 12 can be seen at this link:
https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-syslog-model-11&url2=draft-ietf-netmod-syslog-model-12&difftype=--hwdiff
Please review and comment.
Thanks,
Clyde
From: "Clyde Wildes (cwildes)"
Date: Wednesday, January 11, 2017 at 2:54 PM
To: Andy Bierman
Cc: Alex Campbell , "netmod@ietf.org"
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Any
My comments inline as [clyde2]…
From: Andy Bierman
Date: Saturday, December 31, 2016 at 8:24 AM
To: "Clyde Wildes (cwildes)"
Cc: Alex Campbell , "netmod@ietf.org"
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
On Fri, Dec 30, 2016 at 10:16 AM, Clyde Wildes (cwildes)
mailto:cwil...@cisco.com>> wrote:
Hi Andy,
Thanks for taking the time to review the model.
My comments are inline as [clyde]…
From: netmod mailto:netmod-boun...@ietf.org>> on
behalf of Andy Bierman mailto:a...@yumaworks.com>>
Date: Tuesday, December 27, 2016 at 3:04 PM
To: Alex Campbell
Cc: "netmod@ietf.org<mailto:netmod@ietf.org>"
mailto:netmod@ietf.org>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Hi,
I am also considering an implementation.
I share the same concerns that Alex has brought up.
Some detailed comments:
1) /syslog/actions: seems like everything is in this container.
Why is it needed? Seems like it could be removed as it serves no purpose
[clyde] Although this model is currently designated as config only, we could
add operational data and rpc leaves in the future. The actions container is to
future-proof the model.
2) 8 features: the granularity seems wrong. The main container for each section
should have its own if-feature
/console
/buffer
/file
/remote
[clyde] We have gone back and forth on this…some have complained that there are
too many features. I will be happy to add a feature for each action. Note that
we studied the implementation of each action by six vendors including Linux and
opted to not add features for actions implemented by at least 3 vendors.
Vendors not implementing an action could create a deviation.
I prefer 1 mandatory-to-implement and a minimal number of additional options.
/console
/file
/remote
These are all mandatory-to-implement..
IMO only /file should be mandatory-to-implement.
[clyde2] I will remove the buffer and session actions in the next draft and
will make the remaining three features.
3) What is the 'buffer' container for?
How is the internal memory accessed by the client?
[clyde] buffer is implemented by vendors typically for routers capable of
generating many syslog messages in event-storm bursts. Logging to memory (aka
buffer) allows the preservation of syslog messages which might otherwise be
lost.
IMO it should be removed from the draft.
We certainly have changed the IETF NM focus.
In SNMP-land we routinely left the configuration out of scope
and standardized the monitoring. Now we are standardizing
the configuration and leaving the monitoring out of scope?
I prefer complete standard solutions only.
There is no standard way to access the /console either.
Since the console provides "show log" I really do not see a need for
/buffer at all.
[clyde2] The buffer action will be removed.
A “show log” command is used to access the buffers. As this model is current
designed as a configuration only model, there is no operational leaves for show
log, or rpc leaves for clear log.
4) selector-facility: Seems like no-facilities servers the same purpose
as an empty facility-list. The choice is not needed; just use the
facility-list
[clyde] This was changed as a result of Alex’s feedback – please see my
response to him. The model will be changed to the following:
container selector {
description
"This container describes the log selector parameters
for syslog.";
list facility-list {
key facility;
description
"This list describes a collection of syslog
facilities and severities.";
leaf facility {
type union {
type identityref {
base syslogtypes:syslog-facility;
}
type enumeration {
enum all {
description
"This enum describes the case where all
facilities are requested.";
}
}
}
description
"The leaf uniquely identifies a syslog facility.";
}
uses log-severity;
}
leaf pattern-match {
if-feature select-match;
type
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Hi, "Clyde Wildes (cwildes)" wrote: > Any > > My comments inline as [clyde2]… > > From: Andy Bierman > Date: Saturday, December 31, 2016 at 8:24 AM > To: "Clyde Wildes (cwildes)" > Cc: Alex Campbell , "netmod@ietf.org" > > Subject: Re: [netmod] WG Last Call for > draft-ietf-netmod-syslog-model-11 > > > > On Fri, Dec 30, 2016 at 10:16 AM, Clyde Wildes (cwildes) > mailto:cwil...@cisco.com>> wrote: > Hi Andy, > > Thanks for taking the time to review the model. > > My comments are inline as [clyde]… > > From: netmod mailto:netmod-boun...@ietf.org>> > on behalf of Andy Bierman > mailto:a...@yumaworks.com>> > Date: Tuesday, December 27, 2016 at 3:04 PM > To: Alex Campbell > Cc: "netmod@ietf.org<mailto:netmod@ietf.org>" > mailto:netmod@ietf.org>> > Subject: Re: [netmod] WG Last Call for > draft-ietf-netmod-syslog-model-11 > > Hi, > > I am also considering an implementation. > I share the same concerns that Alex has brought up. > > Some detailed comments: > > 1) /syslog/actions: seems like everything is in this container. > Why is it needed? Seems like it could be removed as it serves no > purpose > > [clyde] Although this model is currently designated as config only, we > could add operational data and rpc leaves in the future. The actions > container is to future-proof the model. > > 2) 8 features: the granularity seems wrong. The main container for > each section > should have its own if-feature > /console > /buffer > /file > /remote > > [clyde] We have gone back and forth on this…some have complained that > there are too many features. I will be happy to add a feature for each > action. Note that we studied the implementation of each action by six > vendors including Linux and opted to not add features for actions > implemented by at least 3 vendors. Vendors not implementing an action > could create a deviation. This is not a good usage of deviations. Deviations should be used as a last resort by vendors that cannot comply with the standard. Designing the usage of deviations into the overall solution is not a good idea. These should really be features, even if the number of features becomes higher. > I prefer 1 mandatory-to-implement and a minimal number of additional > options. > > /console > /file > /remote > > These are all mandatory-to-implement.. > IMO only /file should be mandatory-to-implement. But not all systems have a local file system to write logs to. If there must be one mandatory-to-implement, shouldn't it be 'remote'? > [clyde2] I will remove the buffer and session actions in the next > draft and will make the remaining three features. Good! /martin ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Any
My comments inline as [clyde2]…
From: Andy Bierman
Date: Saturday, December 31, 2016 at 8:24 AM
To: "Clyde Wildes (cwildes)"
Cc: Alex Campbell , "netmod@ietf.org"
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
On Fri, Dec 30, 2016 at 10:16 AM, Clyde Wildes (cwildes)
mailto:cwil...@cisco.com>> wrote:
Hi Andy,
Thanks for taking the time to review the model.
My comments are inline as [clyde]…
From: netmod mailto:netmod-boun...@ietf.org>> on
behalf of Andy Bierman mailto:a...@yumaworks.com>>
Date: Tuesday, December 27, 2016 at 3:04 PM
To: Alex Campbell
Cc: "netmod@ietf.org<mailto:netmod@ietf.org>"
mailto:netmod@ietf.org>>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Hi,
I am also considering an implementation.
I share the same concerns that Alex has brought up.
Some detailed comments:
1) /syslog/actions: seems like everything is in this container.
Why is it needed? Seems like it could be removed as it serves no purpose
[clyde] Although this model is currently designated as config only, we could
add operational data and rpc leaves in the future. The actions container is to
future-proof the model.
2) 8 features: the granularity seems wrong. The main container for each section
should have its own if-feature
/console
/buffer
/file
/remote
[clyde] We have gone back and forth on this…some have complained that there are
too many features. I will be happy to add a feature for each action. Note that
we studied the implementation of each action by six vendors including Linux and
opted to not add features for actions implemented by at least 3 vendors.
Vendors not implementing an action could create a deviation.
I prefer 1 mandatory-to-implement and a minimal number of additional options.
/console
/file
/remote
These are all mandatory-to-implement..
IMO only /file should be mandatory-to-implement.
[clyde2] I will remove the buffer and session actions in the next draft and
will make the remaining three features.
3) What is the 'buffer' container for?
How is the internal memory accessed by the client?
[clyde] buffer is implemented by vendors typically for routers capable of
generating many syslog messages in event-storm bursts. Logging to memory (aka
buffer) allows the preservation of syslog messages which might otherwise be
lost.
IMO it should be removed from the draft.
We certainly have changed the IETF NM focus.
In SNMP-land we routinely left the configuration out of scope
and standardized the monitoring. Now we are standardizing
the configuration and leaving the monitoring out of scope?
I prefer complete standard solutions only.
There is no standard way to access the /console either.
Since the console provides "show log" I really do not see a need for
/buffer at all.
[clyde2] The buffer action will be removed.
A “show log” command is used to access the buffers. As this model is current
designed as a configuration only model, there is no operational leaves for show
log, or rpc leaves for clear log.
4) selector-facility: Seems like no-facilities servers the same purpose
as an empty facility-list. The choice is not needed; just use the
facility-list
[clyde] This was changed as a result of Alex’s feedback – please see my
response to him. The model will be changed to the following:
container selector {
description
"This container describes the log selector parameters
for syslog.";
list facility-list {
key facility;
description
"This list describes a collection of syslog
facilities and severities.";
leaf facility {
type union {
type identityref {
base syslogtypes:syslog-facility;
}
type enumeration {
enum all {
description
"This enum describes the case where all
facilities are requested.";
}
}
}
description
"The leaf uniquely identifies a syslog facility.";
}
uses log-severity;
}
leaf pattern-match {
if-feature select-match;
type string;
description
"This leaf desribes a Posix 1003.2 regular expression
string that can be used to select a syslog message for
logging. The match is performed on the RFC 5424
SYSLOG-MSG field.";
}
5) pattern-match:
leaf pattern-match {
if-feature select-match;
type string;
description
"This leaf desribes a Posix 1003.2 regular expression
string that can be used to select a syslog message for
logging. The match is performed on the RFC 5424
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Kent, I will respond to Andy’s comments this morning and publish a new draft ASAP. It would be very helpful if Andy and Alex could work with me on the new draft. Thanks, Clyde On 1/10/17, 11:34 AM, "Kent Watsen" wrote: Hi Clyde, The LC period has ended. While we only received two reviews, I think both were quite good and thorough and, as far as I can tell, entail needing a non-trivial update to the draft. My thoughts are that you should continue working with Alex and Andy to ensure their issues are resolved, and then post an updated draft that we can run another LC on with the hope of getting a larger response. Makes sense? Kent // as shepherd ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
On Tue, Jan 10, 2017 at 2:20 PM, Alex Campbell
wrote:
> Hi,
>
> I approve of all of your proposed changes.
>
> However, I'm still not sure that "[implementing] the minimum set of
> functionality that is contained in at least three vendor implementations"
> is a sensible policy.
> The fact that three vendors produce devices that support a feature doesn't
> necessarily mean that every device that would implement this model supports
> the feature - especially for a widely-used, generic model such as syslog.
>
> In my opinion the syslog model should be designed to accommodate all sorts
> of devices, not just rack-mount switches and routers.
> For example, many IP phones don't have a console or an accessible
> filesystem. (Just an example; I'm not actually familiar with the internals
> of IP phones)
> The same goes for small managed switches, such as the HP 1810-G8 that
> happened to be on a nearby coworker's desk when I wrote this.
>
>
totally agree - I was going to send a followup, glad you already did.
YANG mandatory-to-implement should be coupled to the feature set, not the
assumed platform.
For example, is there something in the SYSLOG standard that mandates
console ports or user logins?
If not, why are these mandatory parts of the syslog configuration?
The draft is light on context and use-cases.
A user of the standard should not need to be aware of proprietary
predecessors
in order to understand it.
> Alex
>
Andy
>
> From: Clyde Wildes (cwildes)
> Sent: Friday, 16 December 2016 7:29 a.m.
> To: Alex Campbell
> Cc: netmod@ietf.org; Kent Watsen; Juergen Schoenwaelder
> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
>
> Hi Alex,
>
> Thanks for your review. My comments are inline as [clyde]…
>
> On 12/13/16, 8:16 PM, "netmod on behalf of Alex Campbell" <
> netmod-boun...@ietf.org on behalf of alex.campb...@aviatnet.com> wrote:
>
> I am considering to implement the data model in this draft.
>
> I have reviewed this draft and found the following issues. In
> approximately decreasing order of severity:
>
> * In the "selector-facility" choice statement the cases have
> misleading names - the case where no facility is matched is named
> "facility", and the case where specific facilities are matched is named
> "name". I suggest "no-facilities" and "specified-facilities", or similar.
>
> [clyde] I understand your concern and agree. Please see the next answer
> where I have removed the no-facilities case from the model.
>
>
> * I disagree with the premise of the "no-facilities" case, which is
> that it can be used to disable a log action, according to the description:
>
> description
> "This case specifies no facilities will match when
> comparing the syslog message facility. This is a
> method that can be used to effectively disable a
> particular log-action (buffer, file, etc).";
>
> If an administrator wants to disable a log action they should do it
> by either removing it from the configuration, or by setting an "enabled"
> leaf to false.
> With that in mind, there is no reason for the "no-facilities" case
> to exist.
>
> [clyde] I agree with your suggestion to simplify by removing the
> no-facilities case. Please see the revised selector grouping which will
> appear in the next draft:
>
> grouping selector {
> description
> "This grouping defines a syslog selector which is used to
>select log messages for the log-action (console, file,
>remote, etc.). Choose one or both of the following:
> facility [ ...]
> pattern-match regular-expression-match-string
>If both facility and pattern-match are specified, both must
>match in order for a log message to be selected.";
> container selector {
> description
> "This container describes the log selector parameters
> for syslog.";
> list facility-list {
> key facility;
> description
> "This list describes a collection of syslog
>facilities and severities.";
> leaf facility {
> type union {
> type identityref {
> base syslogtypes:syslog-facility;
> }
> type enumeration {
> enum all {
> description
> "This enum describes the case where all
>facilities are requested.&
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Hi,
I approve of all of your proposed changes.
However, I'm still not sure that "[implementing] the minimum set of
functionality that is contained in at least three vendor implementations" is a
sensible policy.
The fact that three vendors produce devices that support a feature doesn't
necessarily mean that every device that would implement this model supports the
feature - especially for a widely-used, generic model such as syslog.
In my opinion the syslog model should be designed to accommodate all sorts of
devices, not just rack-mount switches and routers.
For example, many IP phones don't have a console or an accessible filesystem.
(Just an example; I'm not actually familiar with the internals of IP phones)
The same goes for small managed switches, such as the HP 1810-G8 that happened
to be on a nearby coworker's desk when I wrote this.
Alex
From: Clyde Wildes (cwildes)
Sent: Friday, 16 December 2016 7:29 a.m.
To: Alex Campbell
Cc: netmod@ietf.org; Kent Watsen; Juergen Schoenwaelder
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Hi Alex,
Thanks for your review. My comments are inline as [clyde]…
On 12/13/16, 8:16 PM, "netmod on behalf of Alex Campbell"
wrote:
I am considering to implement the data model in this draft.
I have reviewed this draft and found the following issues. In approximately
decreasing order of severity:
* In the "selector-facility" choice statement the cases have misleading
names - the case where no facility is matched is named "facility", and the case
where specific facilities are matched is named "name". I suggest
"no-facilities" and "specified-facilities", or similar.
[clyde] I understand your concern and agree. Please see the next answer where I
have removed the no-facilities case from the model.
* I disagree with the premise of the "no-facilities" case, which is that it
can be used to disable a log action, according to the description:
description
"This case specifies no facilities will match when
comparing the syslog message facility. This is a
method that can be used to effectively disable a
particular log-action (buffer, file, etc).";
If an administrator wants to disable a log action they should do it by
either removing it from the configuration, or by setting an "enabled" leaf to
false.
With that in mind, there is no reason for the "no-facilities" case to
exist.
[clyde] I agree with your suggestion to simplify by removing the no-facilities
case. Please see the revised selector grouping which will appear in the next
draft:
grouping selector {
description
"This grouping defines a syslog selector which is used to
select log messages for the log-action (console, file,
remote, etc.). Choose one or both of the following:
facility [ ...]
pattern-match regular-expression-match-string
If both facility and pattern-match are specified, both must
match in order for a log message to be selected.";
container selector {
description
"This container describes the log selector parameters
for syslog.";
list facility-list {
key facility;
description
"This list describes a collection of syslog
facilities and severities.";
leaf facility {
type union {
type identityref {
base syslogtypes:syslog-facility;
}
type enumeration {
enum all {
description
"This enum describes the case where all
facilities are requested.";
}
}
}
description
"The leaf uniquely identifies a syslog facility.";
}
uses log-severity;
}
leaf pattern-match {
if-feature select-match;
type string;
description
"This leaf desribes a Posix 1003.2 regular expression
string that can be used to select a syslog message for
logging. The match is performed on the RFC 5424
SYSLOG-MSG field.";
}
}
}
* What is the behaviour of a selector if neither "no-facilities" nor
"facility-list" is present?
[clyde] At least one or both of the following must be specified: facility;
pattern-match (if supported).
I have updated the description at the beginning of the selector – please see
above.
* In the "selector" grouping it is not clear how the facility and pattern
conditions are combined to decide whether a message is selected.
Must they both match the message, or is it sufficient for
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Hi Clyde, The LC period has ended. While we only received two reviews, I think both were quite good and thorough and, as far as I can tell, entail needing a non-trivial update to the draft. My thoughts are that you should continue working with Alex and Andy to ensure their issues are resolved, and then post an updated draft that we can run another LC on with the hope of getting a larger response. Makes sense? Kent // as shepherd ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
On Fri, Dec 30, 2016 at 10:16 AM, Clyde Wildes (cwildes)
wrote:
> Hi Andy,
>
>
>
> Thanks for taking the time to review the model.
>
>
>
> My comments are inline as [clyde]…
>
>
>
> *From: *netmod on behalf of Andy Bierman <
> a...@yumaworks.com>
> *Date: *Tuesday, December 27, 2016 at 3:04 PM
> *To: *Alex Campbell
> *Cc: *"netmod@ietf.org"
> *Subject: *Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
>
>
>
> Hi,
>
>
>
> I am also considering an implementation.
>
> I share the same concerns that Alex has brought up.
>
>
>
> Some detailed comments:
>
>
>
> 1) /syslog/actions: seems like everything is in this container.
>
> Why is it needed? Seems like it could be removed as it serves no purpose
>
>
>
> [clyde] Although this model is currently designated as config only, we
> could add operational data and rpc leaves in the future. The actions
> container is to future-proof the model.
>
>
>
> 2) 8 features: the granularity seems wrong. The main container for each
> section
>
> should have its own if-feature
>
> /console
>
> /buffer
>
> /file
>
> /remote
>
>
>
> [clyde] We have gone back and forth on this…some have complained that
> there are too many features. I will be happy to add a feature for each
> action. Note that we studied the implementation of each action by six
> vendors including Linux and opted to not add features for actions
> implemented by at least 3 vendors. Vendors not implementing an action could
> create a deviation.
>
I prefer 1 mandatory-to-implement and a minimal number of additional
options.
/console
/file
/remote
These are all mandatory-to-implement..
IMO only /file should be mandatory-to-implement.
>
>
> 3) What is the 'buffer' container for?
>
> How is the internal memory accessed by the client?
>
>
>
> [clyde] buffer is implemented by vendors typically for routers capable of
> generating many syslog messages in event-storm bursts. Logging to memory
> (aka buffer) allows the preservation of syslog messages which might
> otherwise be lost.
>
>
>
IMO it should be removed from the draft.
We certainly have changed the IETF NM focus.
In SNMP-land we routinely left the configuration out of scope
and standardized the monitoring. Now we are standardizing
the configuration and leaving the monitoring out of scope?
I prefer complete standard solutions only.
There is no standard way to access the /console either.
Since the console provides "show log" I really do not see a need for
/buffer at all.
A “show log” command is used to access the buffers. As this model is
> current designed as a configuration only model, there is no operational
> leaves for show log, or rpc leaves for clear log.
>
>
>
> 4) selector-facility: Seems like no-facilities servers the same purpose
>
> as an empty facility-list. The choice is not needed; just use the
> facility-list
>
>
>
> [clyde] This was changed as a result of Alex’s feedback – please see my
> response to him. The model will be changed to the following:
>
>
>
> container selector {
>
> description
>
> "This container describes the log selector parameters
>
> for syslog.";
>
> list facility-list {
>
> key facility;
>
> description
>
> "This list describes a collection of syslog
>
>facilities and severities.";
>
> leaf facility {
>
> type union {
>
> type identityref {
>
> base syslogtypes:syslog-facility;
>
> }
>
> type enumeration {
>
> enum all {
>
> description
>
> "This enum describes the case where all
>
>facilities are requested.";
>
> }
>
> }
>
> }
>
> description
>
> "The leaf uniquely identifies a syslog facility.";
>
> }
>
> uses log-severity;
>
> }
>
> leaf pattern-match {
>
> if-feature select-match;
>
> type string;
>
> description
>
> "This leaf desribes a Posix 1003.2 regular expression
>
>string that can be used to select a syslog message for
>
>logging. The match is performed on the RFC 5424
>
>SYSLOG-MSG field.";
>
> }
>
>
>
>
>
> 5) pattern-match:
>
>
>
> leaf pattern-mat
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Hi Andy,
Thanks for taking the time to review the model.
My comments are inline as [clyde]…
From: netmod on behalf of Andy Bierman
Date: Tuesday, December 27, 2016 at 3:04 PM
To: Alex Campbell
Cc: "netmod@ietf.org"
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Hi,
I am also considering an implementation.
I share the same concerns that Alex has brought up.
Some detailed comments:
1) /syslog/actions: seems like everything is in this container.
Why is it needed? Seems like it could be removed as it serves no purpose
[clyde] Although this model is currently designated as config only, we could
add operational data and rpc leaves in the future. The actions container is to
future-proof the model.
2) 8 features: the granularity seems wrong. The main container for each section
should have its own if-feature
/console
/buffer
/file
/remote
[clyde] We have gone back and forth on this…some have complained that there are
too many features. I will be happy to add a feature for each action. Note that
we studied the implementation of each action by six vendors including Linux and
opted to not add features for actions implemented by at least 3 vendors.
Vendors not implementing an action could create a deviation.
3) What is the 'buffer' container for?
How is the internal memory accessed by the client?
[clyde] buffer is implemented by vendors typically for routers capable of
generating many syslog messages in event-storm bursts. Logging to memory (aka
buffer) allows the preservation of syslog messages which might otherwise be
lost.
A “show log” command is used to access the buffers. As this model is current
designed as a configuration only model, there is no operational leaves for show
log, or rpc leaves for clear log.
4) selector-facility: Seems like no-facilities servers the same purpose
as an empty facility-list. The choice is not needed; just use the
facility-list
[clyde] This was changed as a result of Alex’s feedback – please see my
response to him. The model will be changed to the following:
container selector {
description
"This container describes the log selector parameters
for syslog.";
list facility-list {
key facility;
description
"This list describes a collection of syslog
facilities and severities.";
leaf facility {
type union {
type identityref {
base syslogtypes:syslog-facility;
}
type enumeration {
enum all {
description
"This enum describes the case where all
facilities are requested.";
}
}
}
description
"The leaf uniquely identifies a syslog facility.";
}
uses log-severity;
}
leaf pattern-match {
if-feature select-match;
type string;
description
"This leaf desribes a Posix 1003.2 regular expression
string that can be used to select a syslog message for
logging. The match is performed on the RFC 5424
SYSLOG-MSG field.";
}
5) pattern-match:
leaf pattern-match {
if-feature select-match;
type string;
description
"This leaf desribes a Posix 1003.2 regular expression
string that can be used to select a syslog message for
logging. The match is performed on the RFC 5424
SYSLOG-MSG field.";
}
The field SYSLOG-MSG is referenced but never defined or listed in
the terminology section.
[clyde] This will be fixed in the next draft.
6) how are the syslog-facility identities mapped to SYSLOG messages?
6a) how to distinguish acme:foo-facility from example:foo-facility in a SYSLOG
message?
[clyde] I do not understand your question. The current implementation of
facilities was designed with the help of several Yang Doctors. The requirement
is to support the facilities as called out in RFC 5424 as well as vendor
specific facilities that can be added through augmentation. Vendor specific
facilities are not meant to be used across multiple vendor implementations.
7) source-interface: what if the server does not let a source interface be used
and instead
normal routing determines the source interface (this leaf is very
router-centric)
[clyde] source-interface is optional. If not specified normal routing flow
would be used.
8) signing-options: are these widely deployed on all routers and Linux hosts?
[clyde] Alex Clemm asked that we include syslog signing-options. This is
implemented by at least Linux rsyslog.
9) logrotate: there are several features related to log file cleanup allowing
lots of
server variability and forces the client to suppor
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
Hi,
I am also considering an implementation.
I share the same concerns that Alex has brought up.
Some detailed comments:
1) /syslog/actions: seems like everything is in this container.
Why is it needed? Seems like it could be removed as it serves no purpose
2) 8 features: the granularity seems wrong. The main container for each
section
should have its own if-feature
/console
/buffer
/file
/remote
3) What is the 'buffer' container for?
How is the internal memory accessed by the client?
4) selector-facility: Seems like no-facilities servers the same purpose
as an empty facility-list. The choice is not needed; just use the
facility-list
5) pattern-match:
leaf pattern-match {
if-feature select-match;
type string;
description
"This leaf desribes a Posix 1003.2 regular expression
string that can be used to select a syslog message for
logging. The match is performed on the RFC 5424
SYSLOG-MSG field.";
}
The field SYSLOG-MSG is referenced but never defined or listed in
the terminology section.
6) how are the syslog-facility identities mapped to SYSLOG messages?
6a) how to distinguish acme:foo-facility from example:foo-facility in a
SYSLOG message?
7) source-interface: what if the server does not let a source interface be
used and instead
normal routing determines the source interface (this leaf is very
router-centric)
8) signing-options: are these widely deployed on all routers and Linux
hosts?
9) logrotate: there are several features related to log file cleanup
allowing lots of
server variability and forces the client to support all the options.
Can't this be simplified
and all the micro-behavior YANG features removed?
10) numeric limits: there is some odd usage of YANG types; some limits are
uint64, some uint32,
some uint16. Seems like uint32 is sufficient
Andy
On Tue, Dec 13, 2016 at 8:16 PM, Alex Campbell
wrote:
> I am considering to implement the data model in this draft.
>
> I have reviewed this draft and found the following issues. In
> approximately decreasing order of severity:
>
> * In the "selector-facility" choice statement the cases have misleading
> names - the case where no facility is matched is named "facility", and the
> case where specific facilities are matched is named "name". I suggest
> "no-facilities" and "specified-facilities", or similar.
>
> * I disagree with the premise of the "no-facilities" case, which is that
> it can be used to disable a log action, according to the description:
>
> description
> "This case specifies no facilities will match when
> comparing the syslog message facility. This is a
> method that can be used to effectively disable a
> particular log-action (buffer, file, etc).";
>
> If an administrator wants to disable a log action they should do it by
> either removing it from the configuration, or by setting an "enabled" leaf
> to false.
> With that in mind, there is no reason for the "no-facilities" case to
> exist.
>
> * What is the behaviour of a selector if neither "no-facilities" nor
> "facility-list" is present?
> * In the "selector" grouping it is not clear how the facility and pattern
> conditions are combined to decide whether a message is selected.
> Must they both match the message, or is it sufficient for either one to
> match the message?
> * Not all servers have a console; there should be a feature to indicate
> whether logging to the console is supported.
> * Likewise, not all servers may support logging to user sessions.
> * Likewise, not all servers may support a user-accessible filesystem.
> * RFC 5424 states that the severity and protocol values are not normative.
> * It's not clear to me why this needs to be split into two modules. Is it
> so that other modules can define logging parameters but still be usable on
> a device without syslog?
> * "log-severity" defines a severity filter, not a severity, so its name is
> misleading.
> * Perhaps the "severity" type and the facility identities should have
> "reference" statements referring to RFC 5424, rather than referring to it
> in the description.
> * In section "8.2", "admisintrator" is a typo.
>
> I assume that the means of accessing the memory buffer and log files are
> out of scope of this data model.
>
> Alex
>
>
> From: netmod on behalf of Kent Watsen <
> kwat...@juniper.net>
> Sent: Wednesday, 14 December 2016 2:01 p.m.
> To: netmod@ietf.org
> Subject: [netmod] WG Last
Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
r your case could be
done through a vendor specific deviation statement.
* RFC 5424 states that the severity and protocol values are not normative.
[clyde] Is it that you are asking for RFC 5424 to be removed from the Normative
Reference section of the draft and added to the Informative section?
* It's not clear to me why this needs to be split into two modules. Is it
so that other modules can define logging parameters but still be usable on a
device without syslog?
[clyde] We were guided by an early Yang Dr.’s advice in the choice of two
modules – one for types and one for the model. I will defer to our mentor
Jürgen for his advice.
* "log-severity" defines a severity filter, not a severity, so its name is
misleading.
[clyde] Please suggest a better name.
* Perhaps the "severity" type and the facility identities should have
"reference" statements referring to RFC 5424, rather than referring to it in
the description.
[clyde] I will defer to our mentor Jürgen for his advice. We previously
followed his advice here.
* In section "8.2", "admisintrator" is a typo.
[clyde] This will be fixed in the next draft.
I assume that the means of accessing the memory buffer and log files are
out of scope of this data model.
[clyde] This draft covers syslog configuration only.
Thanks,
Clyde
Alex
From: netmod on behalf of Kent Watsen
Sent: Wednesday, 14 December 2016 2:01 p.m.
To: netmod@ietf.org
Subject: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11
This is a notice to start a two-week NETMOD WG last call for the document:
A YANG Data Model for Syslog Configuration
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-11
Please indicate your support or concerns by Tuesday, December 27, 2016.
We are particularly interested in statements of the form:
* I have reviewed this draft and found no issues.
* I have reviewed this draft and found the following issues: ...
As well as:
* I have implemented the data model in this draft.
* I am implementing the data model in this draft.
* I am considering to implement the data model in this draft.
* I am not considering to implement the data model in this draft.
Thank you,
NETMOD WG Chairs
___
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] WG Last Call for draft-ietf-netmod-syslog-model-11
I am considering to implement the data model in this draft. I have reviewed this draft and found the following issues. In approximately decreasing order of severity: * In the "selector-facility" choice statement the cases have misleading names - the case where no facility is matched is named "facility", and the case where specific facilities are matched is named "name". I suggest "no-facilities" and "specified-facilities", or similar. * I disagree with the premise of the "no-facilities" case, which is that it can be used to disable a log action, according to the description: description "This case specifies no facilities will match when comparing the syslog message facility. This is a method that can be used to effectively disable a particular log-action (buffer, file, etc)."; If an administrator wants to disable a log action they should do it by either removing it from the configuration, or by setting an "enabled" leaf to false. With that in mind, there is no reason for the "no-facilities" case to exist. * What is the behaviour of a selector if neither "no-facilities" nor "facility-list" is present? * In the "selector" grouping it is not clear how the facility and pattern conditions are combined to decide whether a message is selected. Must they both match the message, or is it sufficient for either one to match the message? * Not all servers have a console; there should be a feature to indicate whether logging to the console is supported. * Likewise, not all servers may support logging to user sessions. * Likewise, not all servers may support a user-accessible filesystem. * RFC 5424 states that the severity and protocol values are not normative. * It's not clear to me why this needs to be split into two modules. Is it so that other modules can define logging parameters but still be usable on a device without syslog? * "log-severity" defines a severity filter, not a severity, so its name is misleading. * Perhaps the "severity" type and the facility identities should have "reference" statements referring to RFC 5424, rather than referring to it in the description. * In section "8.2", "admisintrator" is a typo. I assume that the means of accessing the memory buffer and log files are out of scope of this data model. Alex ____________________ From: netmod on behalf of Kent Watsen Sent: Wednesday, 14 December 2016 2:01 p.m. To: netmod@ietf.org Subject: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 This is a notice to start a two-week NETMOD WG last call for the document: A YANG Data Model for Syslog Configuration https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-11 Please indicate your support or concerns by Tuesday, December 27, 2016. We are particularly interested in statements of the form: * I have reviewed this draft and found no issues. * I have reviewed this draft and found the following issues: ... As well as: * I have implemented the data model in this draft. * I am implementing the data model in this draft. * I am considering to implement the data model in this draft. * I am not considering to implement the data model in this draft. Thank you, NETMOD WG Chairs ___ 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] WG Last Call for draft-ietf-netmod-syslog-model-11
This is a notice to start a two-week NETMOD WG last call for the document: A YANG Data Model for Syslog Configuration https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-11 Please indicate your support or concerns by Tuesday, December 27, 2016. We are particularly interested in statements of the form: * I have reviewed this draft and found no issues. * I have reviewed this draft and found the following issues: ... As well as: * I have implemented the data model in this draft. * I am implementing the data model in this draft. * I am considering to implement the data model in this draft. * I am not considering to implement the data model in this draft. Thank you, NETMOD WG Chairs ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
