Clyde
Weeell; I still think that we may regret having so many features and so
many possible combinations; For me, it is not a question of whether
they are there in the wild but whether it is right to have such a
complex model; a bit like ABNF where all sorts of things are possible
but sometimes a short sentence can replace lines of meta-syntactic
language. As I said before, rough consensus will prevail, whether I am
in the rough or not.
Some minor editorial remarks
The names are still lengthy giving a line length I count as 76 which
exceeds what the RFC Editor normally allows ( 72). e.g., one of many,
(except that my MUA is going to mangle this example)
" | | +--rw severity-operator? enumeration
{selector-sevop-"
s.1 'draft'
s.3 I think that this example is fine, but would put it in a
non-Normative Appendix with a reference thereto - else people will take
it literally and you will get the same identity appearing many times
(well, that will still occur with an Appendix but at least we can say
you got it wrong).
s.4.1 'Copyright (c) 2015 '
s.4.2 'Copyright (c) 2015 '
s..4.2 The description of log-buffer confuses me. 'The buffer is
circular in nature" so there is only one of them; but it is a list keyed
on 'name' so there are lots of them. " "This leaf configures the amount
number of log messages that can be stored in the local memory logging
buffer." so there is only one of them. Or....?
s.5 I think it wrong to put the e-mail addresses in the RFC; editors
yes, acknowledgements no. If you are going to do that, then take me out
of the list.
s.6
" prefix: ietf-syslog-types reference: RFC XXXX"
suggest
" prefix: ietf-syslog-types
reference: RFC XXXX
"
Tom Petch
----- Original Message -----
From: "Clyde Wildes (cwildes)" <cwil...@cisco.com>
To: "t.petch" <ie...@btconnect.com>
Cc: "netmod WG" <netmod@ietf.org>; "Kiran Koushik Agrahara Sreenivasa
(kkoushik)" <kkous...@cisco.com>; "Martin Bjorklund" <m...@tail-f.com>
Sent: Monday, April 04, 2016 10:12 PM
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-07.txt
> Tom,
>
> I took an action item in the Netmod review of the item-syslog model to
ask you if you are ok with the resulting draft published as a result
Martin's and your comments.
>
> https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-07
>
> Diffs from v6 to v7:
>
>
https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-netmod-
syslog-model-07.txt
>
> Please comment.
>
> Thanks,
>
> Clyde
>
>
>
> On 4/2/16, 4:54 AM, "t.petch" <ie...@btconnect.com> wrote:
>
> >---- Original Message -----
> >From: "Kiran Koushik Agrahara Sreenivasa (kkoushik)"
> ><kkous...@cisco.com>
> >Cc: "t.petch" <ie...@btconnect.com>; <netmod@ietf.org>
> >Sent: Monday, March 28, 2016 9:55 PM
> >
> >Hi Andy
> >
> >We did solicit and incorporate feature support from at least 5+
vendors
> >for this model.
> >The model represents a minimal common feature set. They are also
> >hierarchical as Clyde noted below.
> >
> >Thanks
> >Kiran
> >
> ><tp>
> >
> >If I remember my mathematical teminology, I prefer a highest common
> >factor, to which augmentations can be applied, whereas others prefer
a
> >lowest common denominator, partitioned by features.
> >
> >I do not doubt that everything you model is there in implementations
but
> >I prefer a widely, preferably universal, core which can then be added
> >to.
> >
> >It is a judgement call rather than an engineering one, a matter of
> >philosophy even, so I leave it up to rough consensus.
> >
> >Tom Petch
> >
> >From: Andy Bierman <a...@yumaworks.com<mailto:a...@yumaworks.com>>
> >Date: Monday, March 28, 2016 at 3:32 PM
> >To: "Clyde Wildes (cwildes)"
> ><cwil...@cisco.com<mailto:cwil...@cisco.com>>
> >Cc: "t.petch" <ie...@btconnect.com<mailto:ie...@btconnect.com>>,
> >"netmod@ietf.org<mailto:netmod@ietf.org>"
> ><netmod@ietf.org<mailto:netmod@ietf.org>>, Kiran Koushik Agrahara
> >Sreenivasa <kkous...@cisco.com<mailto:kkous...@cisco.com>>
> >Subject: Re: [netmod] I-D Action:
draft-ietf-netmod-syslog-model-07.txt
> >
> >On Mon, Mar 28, 2016 at 12:57 PM, Clyde Wildes (cwildes)
> ><cwil...@cisco.com<mailto:cwil...@cisco.com>> wrote:
> >Tom,
> >
> >I understand your concern with the complexity of the model. That
said,
> >as we progressed we encountered some vendors and some IETF RFC
authors
> >who requested that a particular feature of interest be included. We
felt
> >that we had to make features that were not implemented by two or more
> >vendors a YANG feature to gain acceptance. Which is preferred in this
> >case: augmentation to add features; deviation not-supported
statements
> >to remove features; or the use of feature statements? During early
model
> >development our YANG doctor advisor advocated using feature.
> >
> >I read your post on "features - a Cartesian explosion" post. Note
that
> >in the case of the latest ietf-syslog model four of the features are
> >nested such that they are not encountered unless a higher level
feature
> >is enabled.
> >
> >What would your preference be:
> >- remove the feature statements and ask vendors to supply deviation
> >statements for those leaves not implemented
> >- remove all leaves conditioned by feature and ask vendors to supply
> >annotated models with augmentation
> >- leave things as they are
> >
> >It sounds like B would be your preference?
> >
> >
> >I agree with Tom.
> >IMO if the functionality is not supported by at least 2 vendors then
> >remove it from the standard. The vendor can write a module
> >that augments the base module.
> >
> >
> >
> >Thanks,
> >
> >Clyde
> >
> >
> >
> >Andy
> >
> >
> >
> >
> >
> >On 3/28/16, 10:09 AM, "t.petch"
> ><ie...@btconnect.com<mailto:ie...@btconnect.com>> wrote:
> >
> >>
> >>----- Original Message -----
> >>From: "Clyde Wildes (cwildes)"
> ><cwil...@cisco.com<mailto:cwil...@cisco.com>>
> >>To: <netmod@ietf.org<mailto:netmod@ietf.org>>
> >>Cc: "Martin Bjorklund" <m...@tail-f.com<mailto:m...@tail-f.com>>;
> >"t.petch"
> >><ie...@btconnect.com<mailto:ie...@btconnect.com>>; "Kiran Koushik
> >Agrahara Sreenivasa (kkoushik)"
> >><kkous...@cisco.com<mailto:kkous...@cisco.com>>
> >>Sent: Sunday, March 20, 2016 7:53 PM
> >>
> >>> Hi,
> >>>
> >>> This revision incorporates feedback from Martin Bjorklunk (19
> >>comments) and Tom Petch (10 comments). Thanks to both of you for
your
> >>valuable feedback!
> >>>
> >>> Regarding Tom's comment - "4.1 What a lot of features? Again,
makes
> >>things more complex, more error prone - are they all really
needed?":
> >We
> >>started the draft two years ago and it has evolved from feedback
> >>received from all of the folks that appear in the Acknowledgements
> >>section. Please review the current draft where I believe that I
address
> >>all of your comments except possibly this one. The tradeoff is to
leave
> >>the feature specific functionality out of the draft and leave it to
the
> >>implementations to add back through augmentation. That said most of
the
> >>features that are called out have been implemented by at least two
> >>vendors, but not all, leading to the feature designation.
> >>
> >>Clyde
> >>
> >>Yeeees; I did a separate post on the topic thinking that an
implementor
> >>might share my concerns about the large number of possible
variations
> >in
> >>an implementation when there were a large number of features, that
> >>perhaps there should be guidelines about it, but it did not get any
> >>traction. It is one those issues where I think, in a year or two's
> >>time, others might share my concern, but not yet:-(.
> >>
> >>I don't doubt that the variation exists and needs modelling, just
that
> >>such use of 'features' may have unfortunate consequences - but I
have
> >no
> >>alternative suggestion.
> >>
> >>Tom Petch
> >>
> >>> Thanks,
> >>>
> >>> Clyde
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
