Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-13.txt

[Warren Kumari]

On Wed, Feb 26, 2020 at 7:49 AM Rob Wilton (rwilton)  wrote:
>
> Hi Qin,
>
> Thanks for your work and timely updates on this document.
>
> Warren, I think that we are good to go for IETF LC with the -14 version.


Whoops, I had missed this; luckily Rob is on the ball and reminded me
/ pointed this out.

I have just requested IETF LC.

W

>
> Thanks,
> Rob
>
>
> > -Original Message-
> > From: Qin Wu 
> > Sent: 26 February 2020 12:28
> > To: Rob Wilton (rwilton) ; netmod@ietf.org
> > Subject: RE: I-D Action: draft-ietf-netmod-factory-default-13.txt
> >
> > -邮件原件-
> > 发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> > 发送时间: 2020年2月26日 18:03
> > 收件人: Qin Wu ; netmod@ietf.org
> > 主题: RE: I-D Action: draft-ietf-netmod-factory-default-13.txt
> >
> > Hi Qin,
> >
> > Please see inline ...
> >
> > > -Original Message-
> > > From: Qin Wu 
> > > Sent: 26 February 2020 01:15
> > > To: Rob Wilton (rwilton) ; netmod@ietf.org
> > > Subject: RE: I-D Action: draft-ietf-netmod-factory-default-13.txt
> > >
> > > Hi, Rob:
> > > -邮件原件-
> > > 发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> > > 发送时间: 2020年2月26日 2:02
> > > 收件人: Qin Wu ; netmod@ietf.org
> > > 主题: RE: I-D Action: draft-ietf-netmod-factory-default-13.txt
> > >
> > > Hi Qin,
> > >
> > > I think that you may have accidentally removed the RFC editor
> > > instructions in the YANG module that presumably we want to still keep?
> > >
> > > // RFC Ed.: update the date below with the date of RFC
> > publication
> > >   // and remove this note.
> > >   // RFC Ed.: replace  with actual RFC number and remove
> > > this
> > >   // note.
> > > [Qin]: My understanding is RFC Note is used to send a note to RFC
> > > Editor, after RFC Editor take action, the RFC Editor note should go
> > > away and will not stay in the YANG module any more.
> > > What do you suggest? Don't include "and remove this note" in the RFC
> > > Editor note?
> > [RW]
> > Apologies, I had read the diff the wrong way round.  Your instruction here
> > is fine, and no further change is required.
> > [Qin]: Good.
> >
> > >
> > > For the update to the security section, my concern wasn't so much
> > > about no longer being able to access a private key, but more that a
> > > client cannot rely on any private data being unrecoverable after the
> > factory-reset RPC.
> > > i.e. they can't just use the factory-reset RPC and then sell the
> > > device on ebay, with the assumption that all private data has been
> > > properly cleansed.
> > >
> > > OLD:
> > >
> > >
> > >The non-volatile storage is expected to be wiped clean and reset
> > > back
> > >to the factory default state, but there is no guarantee that the
> > > data
> > >is wiped according to any particular data cleansing standard, and
> > > the
> > >owner of the device MUST NOT rely on any temporary data (e.g.,
> > >including private keys) for recovery after the factory-reset RPC
> > > has
> > >been invoked.
> > >
> > > NEW:
> > >
> > >
> > >The non-volatile storage is expected to be wiped clean and reset
> > > back
> > >to the factory default state, but there is no guarantee that the
> > > data
> > >is wiped according to any particular data cleansing standard, and
> > > the
> > >owner of the device MUST NOT rely on any sensitive data (e.g.,
> > >private keys) being forensically unrecoverable from the device's
> > >   non-volatile storage after a factory-reset RPC has been
> > invoked.
> > >
> > > [Qin]: I am not lawyer, when you use the word "forensically". But the
> > > "factory-reset" RPC operation has been restricted by using the
> > > "default- deny-all" access control defined in RFC8341. I am not sure
> > > any end user can take advantage of factory-reset RPC as the client.
> > > Let me know if my understanding is correct.
> > >
> >
> > Your current text says, "users need to be aware that private keys might
> > not be recoverable after a factory-reset RPC".  But this isn't a security
> > consideration, this is just an inconvenience, and I believe the text is
> > section 2 is sufficient.
> >
> > My concern is entirely the other way around, i.e. "users need to be aware
> > that private information might still be recoverable after a factory-reset
> > RPC", because a factory-reset RPC does not guarantee that it won't be.
> > Section 2 recommends that security sensitive data be overwritten with 0's,
> > but this is only a SHOULD, and writing 0's doesn't meet the standard
> > industry requirements of ensuring that the data won't be subsequently
> > recoverable.
> >
> > When electronic equipment reaches the end of its useful life then normally
> > the company will ensure that all private data is destroyed from any media
> > before it can be resold.  E.g. in the US this might be done to the DoD
> > 5220.22 standard.
> >
> > I don't want clients using the factory-reset RPC to think that 

[netmod] Changing responsible AD for draft-ietf-netmod-factory-default

[Warren Kumari]

Hi there all,

I have just reassigned the responsible AD for
draft-ietf-netmod-factory-default from Ignas to myself.

Rob Wilton (the incoming Management AD, CCed) will be doing the actual
"work" part of this, I'm primarily acting as a proxy / clicking the
buttons in the datatracker.

Please welcome Rob into his new role,
W
-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

Re: [netmod] [Technical Errata Reported] RFC7950 (5784)

[Warren Kumari]

On Wed, Jul 17, 2019 at 9:29 AM Per Hedeland  wrote:
>
> On 2019-07-17 14:34, Juergen Schoenwaelder wrote:
> > Its the first half of the sentence in my copy of RFC 7950.
>
> It believe that there is a problem with English language both in Qin's
> understanding of the original text (which is correct also in my
> opinion) and in his explanation of his (mis)understanding...
>
> > I propose to reject this errata.
>
> I agree, in particular since the suggested change is IMHO no actual
> improvement. It seems the problem is in understanding the "subject to"
> construct, which is perhaps not obvious to *all* non-native English
> readers, but I can't think of a replacement that wouldn't result in an
> unecessarily complex text.

Hi all,

#include  // Not a YANG person.

I spent some time trying to decide between Hold for Document Update,
and Rejected. I've decided on Rejected, but if and when we decide to
update this, it may be worth addressing the text anyway.


W

>
> > /js
> >
> > On Wed, Jul 17, 2019 at 12:02:21PM +, Qin Wu wrote:
> >> Hi, Juergen and Rob:
> >> The condition to apply " Leading and trailing zeros are prohibited ",is 
> >> the second half sentence, i.e.,"there MUST be at least one digit before 
> >> and after the decimal point".
>
> It seems that you have it almost backwards... "The rule is A subject
> to the rule B" means that rule A should be applied, except when it
> will violate rule B.
>
> >> One digit before the decimal point and one digit after the decimal point 
> >> at the same time cover 0.500?, I still don't get it.
>
> It's a very good example. With unconditional application of "Leading
> and trailing zeros are prohibited", we end up with .5 - but then we
> violate "there MUST be at least one digit before and after the decimal
> point", so we need to back out the removal of the leading zero, and
> end up with 0.5.
>
> >> Maybe I am wrong, but this is not a big deal.
>
> Hopefully the above helps...
>
> --Per
>
> >> -Qin
> >> -®öŸö-
> >> Ñöº: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> >> Ñ öô: 2019t7 17å 18:29
> >> 6öº: Qin Wu 
> >> „ : Rob Wilton (rwilton) ; ibagd...@gmail.com; 
> >> war...@kumari.net; netmod@ietf.org; RFC Errata System 
> >> 
> >> ;˜: Re: [netmod] RE: [Technical Errata Reported] RFC7950 (5784)
> >>
> >> The text starts with the general case and says "Leading and trailing zeros 
> >> are prohibited", which seems to cover 0.5000 (which must be 
> >> represented as 0.5.
> >>
> >> /js
> >>
> >> On Wed, Jul 17, 2019 at 09:42:38AM +, Qin Wu wrote:
> >>> I realized my proposed changes also have some flaw and may need to be 
> >>> tweaked.
> >>>
> >>> My question is should trailing zeros in  0.5  be allowed? I didn t 
> >>> see the original text prohibit this.
> >>> Yes, the original text is correct, but it excludes some exception cases, 
> >>> such as  0.5 , if my understanding is correct.
> >>> Ñöº: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> >>> Ñ öô: 2019t7 17å 17:20
> >>> 6öº: Qin Wu ; Juergen Schoenwaelder
> >>> 
> >>> „ : ibagd...@gmail.com; war...@kumari.net; netmod@ietf.org; RFC Errata
> >>> System 
> >>> ;˜: RE: [netmod] T
> : [Technical Errata Reported] RFC7950 (5784)
> >>>
> >>> Hi Qin,
> >>>
> >>> I also find the current RFC text quite understandable and correct.
> >>>
> >>> The  and  is required to disallow  .0  and  0.  as valid canonical forms. 
> >>>  I.e. in the canonical form there MUST always be at least one digit 
> >>> (which could be 0) before the decimal point and then must be at least one 
> >>> digit (which could be 0) after the decimal point.  Otherwise, there must 
> >>> be no leading or trailing 0 s.  So, none of   .0 ,  0. ,  00.0 ,  0.00  
> >>> and  00.00  are in the canonical form, and should be represented as  0.0  
> >>> instead; similarly none of  .1 ,  1. ,  01.0 ,  1.00  and  01.00  are in 
> >>> the canonical form and should be represented as  1.0  instead.
> >>>
> >>> Thanks,
> >>> Rob
> >>>
> >>>
> >>> From: netmod mailto:netmod-boun...@ietf.org>>
> >>> On Behalf Of Qin Wu
> >>> Sent: 17 July 2019 09:59
> >>> To: Juergen Schoenwaelder
> >>> mailto:j.schoenwaelder@jacobs-un
> >>> iversity.de>>
> >>> Cc: ibagd...@gmail.com;
> >>> war...@kumari.net;
> >>> netmod@ietf.org; RFC Errata System
> >>> mailto:rfc-edi...@rfc-editor.org>>
> >>> Subject: [netmod] T
> : [Technical Errata Reported] RFC7950 (5784)
> >>>
> >>>
> >>> Understand, the problem lies at "and" that is used in " one digit before 
> >>> and after the decimal point ", that is to say it only focus on the case 
> >>> that has two digits, one is before decimal point, the other digit is 
> >>> after decimal such as "5.06", but doesn't cover the case where "one digit 
> >>> before or after the decimal point ", that s why I think the case 0.50 
> >>> is not covered. We should prohibit trailing zeros in  0.500 .
> >>>
> >>> 

Re: [netmod] [Technical Errata Reported] RFC7950 (5807)

[Warren Kumari]

[ - RFC Ed (for clutter), + Benoit (who verified
https://www.rfc-editor.org/errata/eid4794) ]

I'm trying to go through and clean up the outstanding Ops and
Management Errata. I'm completely, 100% not a YANG / netmod person (I
cannot even spell YANG!), but I *think* that this Errata should be
verified, yes? This isn't changing what was decided when the WG
published this, it is simply correcting / clarifying the text.

The Errata criteria are here:
https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/

One of the big ones is that we only use Errata to fix actual errors,
not change anything that was WG consensus at the time:
"Changes that modify the working of a protocol to something that might
be different from the intended consensus when the document was
approved should be either Hold for Document Update or Rejected.
Deciding between these two depends on judgment. Changes that are
clearly modifications to the intended consensus, or involve large
textual changes, should be Rejected. In unclear situations, small
changes can be Hold for Document Update."

Again, I'm not a NetMod person, so looking for clear advice here...

W

On Tue, Aug 13, 2019 at 7:26 AM RFC Errata System
 wrote:
>
> The following errata report has been submitted for RFC7950,
> "The YANG 1.1 Data Modeling Language".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5807
>
> --
> Type: Technical
> Reported by: Jernej Tuljak 
>
> Section: 7.21.5.
>
> Original Text
> -
>o  If the "when" statement is a child of a "uses", "choice", or
>   "case" statement, then the context node is the closest ancestor
>   node to the node with the "when" statement that is also a data
>   node.  If no such node exists, the context node is the root node.
>   The accessible tree is tentatively altered during the processing
>   of the XPath expression by removing all instances (if any) of the
>   nodes added by the "uses", "choice", or "case" statement.
>
> Corrected Text
> --
>o  If the "when" statement is a child of a "uses", "choice", or
>   "case" statement, then the context node is the closest ancestor
>   node to the node with the "when" statement that is also a data
>   node, rpc, action or notification.  If no such node exists, the
>   context node is the root node. The accessible tree is tentatively
>   altered during the processing of the XPath expression by removing
>   all instances (if any) of the nodes added by the "uses",
>   "choice", or "case" statement.
>
> Notes
> -
> Similar to verified errata 4794 (https://www.rfc-editor.org/errata/eid4794) 
> but covers the "uses", "choice" and "case" corner case (instead of 
> "augment"). If the node for which the "when" statement is defined is within 
> an rpc, action or notification, the context node also needs to be inside that 
> rpc, action or notification. There are published IETF modules, which rely on 
> this to be true, such as "ietf-netconf-nmda@2019-01-07" in RFC8526 
> (https://tools.ietf.org/html/rfc8526) at schema node id 
> "/ncds:get-data/ncds:input/ncds:origin-filters". Original text assigns the 
> context node to the root node, if no data node ancestor is found. "rpc", 
> "action" and "notification" are not data nodes and are represented by nodes 
> that are descendants of the root node, as described in Section 6.4.1.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> --
> Title   : The YANG 1.1 Data Modeling Language
> Publication Date: August 2016
> Author(s)   : M. Bjorklund, Ed.
> Category: PROPOSED STANDARD
> Source  : Network Modeling
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

Re: [netmod] [Editorial Errata Reported] RFC7950 (5642)

[Warren Kumari]

On Thu, Feb 21, 2019 at 1:53 PM Andy Bierman  wrote:
>
>
>
> On Thu, Feb 21, 2019 at 10:33 AM Martin Bjorklund  wrote:
>>
>> Andy Bierman  wrote:
>> > On Thu, Feb 21, 2019 at 10:07 AM Peter Loborg 
>> > wrote:
>> >
>> > >
>> > >
>> > > Your example is fine – but the gammar is ch14 specifies something
>> > > different:
>> > >
>> > >
>> > >
>> > > enum-stmt   = enum-keyword sep string optsep
>> > >
>> > >  (";" /
>> > >
>> > >   "{" stmtsep
>> > >
>> > >   ;; these stmts can appear in any order
>> > >
>> > >   *if-feature-stmt
>> > >
>> > >   [value-stmt]
>> > >
>> > >   [status-stmt]
>> > >
>> > >   [description-stmt]
>> > >
>> > >   [reference-stmt]
>> > >
>> > >"}") stmtsep
>> > >
>> > >
>> > >
>> > > It clearly states  string, not quoted-string. These two have the 
>> > > following
>> > > rules:
>> > >
>> > >
>> > >
>> > > quoted-string   = (DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)
>> > >
>> > >
>> > >
>> > > string  = < an unquoted string, as returned by >
>> > >
>> > >  < the scanner, that matches the rule >
>> > >
>> > >  < yang-string >
>> > >
>> > >
>> > >
>> >
>> >
>> > The text in 9.6.4 is correct.
>> > The ABNF is wrong.
>>
>> No, the ABNF is correct.  The ABNF doens't handle concatenation etc.
>> The idea is that the scanner handles quotes and concatenation and
>> returns a "string".
>>
>
>
> OK -- it is confusing that the rule quoted-string exists, but it
> is only for key and leaf-list predicates.

Hi all,

I'm trying to go through and do some cleanup of the dangling Errata.
I'm *certainly* not an expert here, and so am relying on y'all.
>From what I've been able to figure out, the consensus is that this
Errata should be rejected, yes?
W


>
>
>>
>>
>> /martin
>>
>
> Andy
>
>>
>>
>>
>> >
>> >
>> >
>> > > …and in 6.1.3 we can read that:
>> > >
>> > >An unquoted string is any sequence of characters that does not
>> > >
>> > >contain any space, tab, carriage return, or line feed characters, a
>> > >
>> > >single or double quote character, a semicolon (";"), braces ("{" or
>> > >
>> > >"}"), or comment sequences ("//", "/*", or "*/").
>> > >
>> > >
>> > >
>> > >Note that any keyword can legally appear as an unquoted string.
>> > >
>> > >
>> > >
>> > > Since the section so clearly writes about single quoted strings and 
>> > > double
>> > > quoted strings, there can unfortunately be no interpretation that would
>> > > allow “identifier” to be called an unquoted string – even though it 
>> > > follows
>> > > the rules about limited character contents.
>> > >
>> > >
>> > >
>> > > Hence – this is not a matter of opinion – it’s a matter of reading what’s
>> > > actually written in the RFC.
>> > >
>> > >
>> > >
>> > > But on the subject of opinion…
>> > >
>> > >
>> > >
>> > >   enum "This is also legal";   // should definitely always be illegal
>> > >
>> > >
>> > >
>> > > …as we cannot create a language binding to enum constructs in any major
>> > > programming languages.
>> > >
>> > >
>> > >
>> >
>> > There are many aspects of YANG that do not map directly to programming
>> > languages,
>> > such as allowing '.' in identifiers.
>> >
>> >
>> >
>> > > Br,
>> > >
>> > 

Re: [netmod] [Technical Errata Reported] RFC7950 (5617)

[Warren Kumari]

On Wed, Jan 30, 2019 at 5:45 AM Ladislav Lhotka  wrote:

> Hi,
>
> this erratum should be rejected. It is a substantial technical change of
> the
> spec, and section 9.9.2 doesn't indicate any possibility of using deref().
>
>
Yup, while it might be a good idea, it isn't an errata, and would need a
-bis or similar
W



> Lada
>
> On Wed, 2019-01-30 at 02:35 -0800, RFC Errata System wrote:
> > The following errata report has been submitted for RFC7950,
> > "The YANG 1.1 Data Modeling Language".
> >
> > --
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata/eid5617
> >
> > --
> > Type: Technical
> > Reported by: Marek Michalak, Pawel Koch 
> >
> > Section: 14
> >
> > Original Text
> > -
> > path-arg= absolute-path / relative-path
> >
> > Corrected Text
> > --
> > path-arg= deref-expr / path-str
> >
> > deref-expr  = deref-function-invocation *WSP "/" *WSP
> >   relative-path
> >
> > path-str= absolute-path / relative-path
> >
> > deref-function-invocation = deref-keyword *WSP
> > "(" *WSP path-str *WSP ")"
> >
> > deref-keyword   = %s"deref"
> >
> > Notes
> > -
> > This is to allow path statement to contain also "deref" function
> invocation
> > which is supported by pyang and Cisco compiler but for now is not
> supported by
> > i.e. yanglint validator because of above statement which does not allow
> for
> > it.
> >
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --
> > RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> > --
> > Title   : The YANG 1.1 Data Modeling Language
> > Publication Date: August 2016
> > Author(s)   : M. Bjorklund, Ed.
> > Category: PROPOSED STANDARD
> > Source  : Network Modeling
> > Area: Operations and Management
> > Stream  : IETF
> > Verifying Party : IESG
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Warren Kumari's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

[Warren Kumari]

On Wed, Sep 26, 2018 at 6:32 PM Mahesh Jethanandani 
wrote:

>
>
> > On Sep 26, 2018, at 1:49 PM, Warren Kumari  wrote:
> >
> > Warren Kumari has entered the following ballot position for
> > draft-ietf-netmod-acl-model-19: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > Be ye not afraid -- this DISCUSS is easily cleared, but sufficiently
> important
> > that I thought it worth making, and making sure it didn't slip through
> the
> > cracks.
> >
> > The description for match-on-ipv4 says: "The device can support matching
> on
> > IPv4 headers.", but the description for 'match-on-tcp', 'match-on-udp',
> > 'match-on-icmp' say: "The device can support  headers." I
> really
> > think that these need to be "The device can support matching on
> 
> > headers.”
>
> Ok.
>
>

Discuss cleared.



> >
> >
> > --
> > COMMENT:
> > --
> >
> > Section 1:
> > "In case a vendor supports it, metadata matches apply to fields
> associated with
> > the packet but not in the packet header such as input interface or
> overall
> > packet length". I don't have a suggested replacement, but seeing as this
> is
> > introductory text, I figured it was aimed at people not familiar with how
> > forwarding / filtering works. I'm slightly concerned that some people
> will get
> > confused, because almost all protocols include a "packet length" in the
> header.
> > Perhaps just dropping the "or overall packet length"? (Yes, we could get
> into
> > a long thing on protocol packet length, and overall length, etc, but
> that's
> > likely to not be helpful in the document).
>
> I am not sure what the concern is. The "overall packet length" being
> referred to is not the “packet length” in the header field. It is the
> length of the packet as received over the wire. Is that the clarification
> you were looking for in the document?
>

Yup, perfect.

People often seem to forget this -- the surrounding text is all
introductory, and so I was concerned that the audience would see that, and
think: "But the packet length is in the header", and miss the distinction
that L3 packet length != L2 packet lenght, etc.


>
> >
> > Section 2:
> > Nit: "It is very important that model can be used easily by
> > applications/attachments." models.
>
> Ok.
>
> >
> > Section 3:
> > "Packet header matching applies to fields visible in the packet such as
> address
> > or CoS or port numbers." CoS isn't expanded, and isn't in the well known
> > acronyms list. RFC2474 perhaps?
>
> It is in Section 1 and 1.1.
>

Doh! Sorry.



>
> >
> > Section 3:
> > "These include features such as "Device can support ethernet headers" or
> > "Device can support of IPv4 headers". "can support of" makes no sense.
> Also, I
> > *think* Ethernet is uppercase. This is a nit.
>
> Will
> s/support/match on/
>
>
Win!

Thank you for accepting the suggestions in the spirit they were offered.
W



> Thanks.
>
> >
> >
>
> Mahesh Jethanandani
> mjethanand...@gmail.com
>
>
>
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Warren Kumari's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

[Warren Kumari]

Warren Kumari has entered the following ballot position for
draft-ietf-netmod-acl-model-19: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/



--
DISCUSS:
--

Be ye not afraid -- this DISCUSS is easily cleared, but sufficiently important
that I thought it worth making, and making sure it didn't slip through the
cracks.

The description for match-on-ipv4 says: "The device can support matching on
IPv4 headers.", but the description for 'match-on-tcp', 'match-on-udp',
'match-on-icmp' say: "The device can support  headers." I really
think that these need to be "The device can support matching on 
headers."


--
COMMENT:
--

Section 1:
"In case a vendor supports it, metadata matches apply to fields associated with
the packet but not in the packet header such as input interface or overall
packet length". I don't have a suggested replacement, but seeing as this is
introductory text, I figured it was aimed at people not familiar with how
forwarding / filtering works. I'm slightly concerned that some people will get
confused, because almost all protocols include a "packet length" in the header.
 Perhaps just dropping the "or overall packet length"? (Yes, we could get into
a long thing on protocol packet length, and overall length, etc, but that's
likely to not be helpful in the document).

Section 2:
Nit: "It is very important that model can be used easily by
applications/attachments." models.

Section 3:
"Packet header matching applies to fields visible in the packet such as address
or CoS or port numbers." CoS isn't expanded, and isn't in the well known
acronyms list. RFC2474 perhaps?

Section 3:
"These include features such as "Device can support ethernet headers" or
"Device can support of IPv4 headers". "can support of" makes no sense. Also, I
*think* Ethernet is uppercase. This is a nit.


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

Re: [netmod] Alexey Melnikov's No Objection on draft-ietf-netmod-syslog-model-23: (with COMMENT)

[Warren Kumari]

On Wed, Mar 7, 2018 at 9:17 AM, Benoit Claise <bcla...@cisco.com> wrote:
> Hi Alexey, Warren,
>>
>> Alexey Melnikov has entered the following ballot position for
>> draft-ietf-netmod-syslog-model-23: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/
>>
>>
>>
>> --
>> COMMENT:
>> --
>>
>> Thank you for this document.
>>
>> I also prefer for TCP to be documented, if used in real world.
>
> I've seen this comment in Warren's comment at
> https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ballot/#warren-kumari.
> However, I can't find his ballot in email.

That's because of my cunning plan of not clicking the Send Mail button.

I'd viewed my comments as just informational / preferences and not
worth cluttering up people's mail.

> So let me reply to both of you here.
>
> This was discussed on the NETMOD mailing list. See subject "I-D Action:
> draft-ietf-netmod-syslog-model-19.txt"
> The fact is that RFC 6587 is now historic, implying a historic downref.
>
> I'm in favor to publish the document as it is right now, whose 00 WG doc.
> version dates from Nov 2014.

SGTM!
W

> Augmenting a YANG module, if TCP is required, is not that hard.
>
> Regards, Benoit
>>
>>
>> Some minor comments:
>>
>> 1) Please add a Normative Reference for the file: URI RFC (RFC 8089) when
>> you
>> mention it for the first time.
>>
>> 2) On page 19:
>>
>> Example: compare->equals and action->no-match means
>> messages that have a severity that is not equal to the
>> specified severity will be logged.";
>>
>> Do you mean "action->block" instead of "action->no-match"?
>>
>> 3) When logging to file: how is the file name constructed from the name
>> file:
>> URI if multiple files are preserved by the system? E.g. if the log file is
>> rotated daily and 5 last files are preserved, how does each individual
>> filename
>> look? If I understood how this is used, this needs more clarification.
>>
>> 4) Nit: on page 18, typo in "spectify"
>>
>>
>> .
>>
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

[netmod] Warren Kumari's No Objection on charter-ietf-netmod-08-02: (with COMMENT)

[Warren Kumari]

Warren Kumari has entered the following ballot position for
charter-ietf-netmod-08-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-netmod/



--
COMMENT:
--

This seems clear to me. 
Not sure if this is the place to address this, but the milestones seem,
um, aggressive... :-)


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