Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)

2021-10-07 Thread Benjamin Kaduk 
Hi Balázs,

Replies inline as well (where needed)

On Thu, Oct 07, 2021 at 10:43:28AM +, Balázs Lengyel wrote:
> Hello Benjamin,
> Thank you for the thorough review. I used your comments to improve the draft. 
> See my detailed answers below as BALAZS:
> Regards Balazs
> 
> -Original Message-
> From: Benjamin Kaduk via Datatracker  
> Sent: 2021. október 7., csütörtök 6:55
> To: The IESG 
> Cc: draft-ietf-netmod-yang-instance-file-for...@ietf.org; 
> netmod-cha...@ietf.org; netmod@ietf.org; Kent Watsen ; 
> kent+i...@watsen.net
> Subject: Benjamin Kaduk's No Objection on 
> draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-netmod-yang-instance-file-format-20: 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/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Should we register media-types for the file formats being specified?
> 
> Section 2
> 
>Two formats are specified based on the XML and JSON YANG encodings.
>Later, as other YANG encodings (e.g., CBOR) are defined, further
>instance data formats may be specified.
> 
> I don't remember seeing a clear description of the specifics of these two 
> specified formats.  (I assume it's just "use the XML/JSON encoding for YANG 
> structures", but I don't remember that stated anywhere.)
> BALAZS: I added references to the relevant RFCs (7950, 7951, 8791) As the 
> model starts with a YAN structure, I included YANG Data Structure Extensions 
> RFC8791 too.

I was hoping for a statement like "The file formats are achieved by
applying the respective XML and JSON encoding rules for the YANG structure
included in this document."

>The name of the instance data file SHOULD be of the form:
> 
>   instance-data-set-name ['@' ( revision-date / timestamp ) ]
>  ( '.xml' / '.json' )
> 
> This looks (almost?  Not sure about '@' vs. "@".) like valid ABNF.  Do we 
> want to say that and reference RFC 5234 for the interpretation of the symbols?
> BALAZS: reference to ABNF added. Changed to double quotes.
> 
>If the leaf "name" is present in the instance data header, its value
>SHOULD be used for the "instance-data-set-name".  If the "revision-
>date" is present in the filename it MUST conform to the format of the
>revision-date leaf in the YANG model.  [...]
> 
> This seems unenforcable, and contrary to the Unix ethos.  Why is it necessary 
> to try to have consistency betwen the contents of the file and its name in 
> the file system, as opposed to letting the type and contents of a file speak 
> for itself regardless of the name in the file system?
> BALAZS: We use the convention of RFC7950: to use the name of the top YANG 
> construct 
> in the filename (there the module name here the structure name). 
> In practice this convention proved very useful. (There already exist some 
> implementations of the YANG instance data).
> A similar rule for YANG modules is enforced by many tools e.g., pyang and 
> confdc.

This is just a COMMENT, so I don't specifically object, even if it seems
surprising to me.

>Metadata, information about the data set itself SHOULD be included in
>the instance data set.  Some metadata items are defined in the YANG
>module "ietf-yang-instance-data", but other items MAY be used.
> 
>Metadata MUST include:
> 
>   -  Version of the YANG Instance Data format
> 
> Doesn't the latter (MUST) effectively make the former (SHOULD) also into a 
> "MUST"?
> BALAZS: Yes, I will change it to MUST. The format-version is a MUST either as 
> a default value 
> (not actually present according to YANG rules) or as an explicitly specified 
> value. 
> The other metadata items are only recommended (SHOULD).
> 
> Also, if this is actually mandatory, shouldn't that be reflected in the YANG 
> module?
> BALAZS: IN the YANG module leaf format-version has a default value. That 
> means that 
> either the default value or some explicitly set vale is always usable for

[netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-yang-instance-file-format-20: (with COMMENT)

2021-10-06 Thread Benjamin Kaduk via Datatracker 
Benjamin Kaduk has entered the following ballot position for
draft-ietf-netmod-yang-instance-file-format-20: 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/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/



--
COMMENT:
--

Should we register media-types for the file formats being specified?

Section 2

   Two formats are specified based on the XML and JSON YANG encodings.
   Later, as other YANG encodings (e.g., CBOR) are defined, further
   instance data formats may be specified.

I don't remember seeing a clear description of the specifics of these
two specified formats.  (I assume it's just "use the XML/JSON encoding
for YANG structures", but I don't remember that stated anywhere.)

   The name of the instance data file SHOULD be of the form:

  instance-data-set-name ['@' ( revision-date / timestamp ) ]
 ( '.xml' / '.json' )

This looks (almost?  Not sure about '@' vs. "@".) like valid ABNF.  Do
we want to say that and reference RFC 5234 for the interpretation of the
symbols?

   If the leaf "name" is present in the instance data header, its value
   SHOULD be used for the "instance-data-set-name".  If the "revision-
   date" is present in the filename it MUST conform to the format of the
   revision-date leaf in the YANG model.  [...]

This seems unenforcable, and contrary to the Unix ethos.  Why is it
necessary to try to have consistency betwen the contents of the file and
its name in the file system, as opposed to letting the type and contents
of a file speak for itself regardless of the name in the file system?

   Metadata, information about the data set itself SHOULD be included in
   the instance data set.  Some metadata items are defined in the YANG
   module "ietf-yang-instance-data", but other items MAY be used.

   Metadata MUST include:

  -  Version of the YANG Instance Data format

Doesn't the latter (MUST) effectively make the former (SHOULD) also into
a "MUST"?

Also, if this is actually mandatory, shouldn't that be reflected in the
YANG module?

Section 2.1.2

   import-only dependencies MAY be excluded from the leaf-list.  If they
   are excluded then the consumer of the instance data set has to apply
   the YANG language rules to resolve the imports.  An example of the

Do we want to say something like "Accordingly, recipients of the
instance data set must be prepared to perform this processing, absent
prior knowledge about the files they will be processing"?

Section 2.2.1

i...@acme.com

Unfortunately, acme.com is a real domain name; we should probably use a
BCP 32 name.  Likewise for urn:rdns:acme.com:oammodel:acme-system-ext,
etc.

Section 2.2.2

 
   true
   deny
   deny

Is there a  that should be set as well?  Or do we just
implicitly rely on the default from RFC 8341?

Section 3

 description
   "An arbitrary name for the YANG instance data set.  This
value is primarily used for descriptive purposes.  However,
when the instance data set is saved to a file, then the
filename MUST encode the name's value, per Section 3
of RFC .";

I think this requirement is currently stated in Section 2, not 3 (though
in my previous comment I suggest that the requirement should be
removed).

Section 4

(I wrote, then deleted as duplicate, essentially all of the same things
that Roman commented on.  Thanks for updating in response to his
comments.)

   The document does not specify any method to influence the behavior of
   a server.

A few of the listed use cases seem to involve loading configuration into
a server, which could perhaps be considered to influence the behavior of
the server in question.

   The header part is not security sensitive with one possible
   exception.  If the URI method is used for specification of the
   content schema and the URI includes a username and/or a password, the
   instance data file needs to be handled securely as mentioned below.

In the terminology of RFC 3986 this is the "userinfo subcomponent", as
in "the URI includes a userinfo subcomponent".

NITS

Section 2.2.1, 2.2.2

It's a bit challenging to get the  of the file to be much
older than the  of the YANG modules it uses.



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

Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT)

2021-07-28 Thread Benjamin Kaduk 
On Mon, Jul 19, 2021 at 12:12:09PM -0400, Christian Hopps wrote:
> 
> 
> > On Jul 17, 2021, at 7:24 PM, Benjamin Kaduk  wrote:
> > 
> > On Sat, Jul 17, 2021 at 07:17:09PM -0400, Christian Hopps wrote:
> >> 
> >> 
> >>> On Jul 17, 2021, at 6:14 PM, Benjamin Kaduk  wrote:
> >>> 
> >>> So, when we refine the coord-accuracy and height-accuracy for an
> >>> instantiation of the grouping, what does that mean?
> >> 
> >> It’s supposed to mean the accuracy of the measurement that is recorded in 
> >> the grouping. So if the coord-accuracy is .1 and the measurement is 
> >> lat/long then the accuracy is within 1/10 of a decimal degree. if the 
> >> measurement is in cart coordinates the accuracy would be 100cm. I don’t 
> >> think we need to make this anymore complex than that. Is there some text 
> >> you would like to see to make that clearer?
> > 
> > The accuracy of the measurement with respect to what?  The coordinate
> > system, or the actual physical object?
> 
> I really don’t see how this could be so confusing.
> 
> This grouping is a location, the accuracy applies to the contained location 
> data. Consider asking this question about some other field like the lat/long 
> — it doesn’t make sense.

It's confusing because there's a type mismatch between what the actual
words on the page say and what you're describing in the email thread.

> I can’t say for sure, but I think you’ve discarded the obvious here and are 
> getting pedantic about something that’s not actually confusing.
>
> Finally, as we (the IETF) are not geo location experts, we had this grouping 
> reviewed by actual industry experts (thanked in the acknowledgment section) 
> and they had no issue with these fields. I would be very hesitant to change 
> what they reviewed as correct at this point based on pedantic musings.

I'm confident that the actual fields in the model can provide the needed
information.  We just need to clearly describe what information they are
conveying.

So, if we look at the

OLD:

 leaf geodetic-datum {
   type string {
 pattern '[ -@\[-\^_-~]*';
   }
   description
 "A geodetic-datum defining the meaning of latitude,
  longitude and height. The default when the
  astronomical body is 'earth' is 'wgs-84' which is
  used by the Global Positioning System (GPS). The
  ASCII value SHOULD have upper case converted to lower
  case and not include control characters (i.e., values
  32..64, and 91..126). The IANA registry further
  restricts the value by converting all spaces (' ') to
  dashes ('-')";
   [...]
 leaf coord-accuracy {
   type decimal64 {
 fraction-digits 6;
   }
   description
 "The accuracy of the latitude longitude pair for
  ellipsoidal coordinates, or the X, Y and Z components
  for Cartesian coordinates. When coord-accuracy is
  specified, it overrides the geodetic-datum implied
  accuracy.";
 }

this is indicating that the geodetic datum has some intrinsic default for
accuracy of latitude/longitude (not quoted, there is also some default for
height accuracy intrinsic to the geodetic datum).

If I were holding the pen, I might consider things like the following

NEW1:
 leaf geodetic-datum {
   type string {
 pattern '[ -@\[-\^_-~]*';
   }
   description
 "A geodetic-datum defining the meaning of latitude,
  longitude and height. The default when the
  astronomical body is 'earth' is 'wgs-84' which is
  used by the Global Positioning System (GPS). The
  ASCII value SHOULD have upper case converted to lower
  case and not include control characters (i.e., values
  32..64, and 91..126). The IANA registry further
  restricts the value by converting all spaces (' ') to
  dashes ('-')";
  The specification for the geodetic-datum indicates
  how accurately it models the astronomical body in
  question, both for the "horizontal" latitude/longitude
  coordinates and for height coordinates, typically as a
  maximum deviation across the entire astronomical object.

NEW2:
 leaf coord-accuracy {
   type decimal64 {
 fraction-digits 6;
   }
   description

Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT)

2021-07-17 Thread Benjamin Kaduk 
On Sat, Jul 17, 2021 at 07:17:09PM -0400, Christian Hopps wrote:
> 
> 
> > On Jul 17, 2021, at 6:14 PM, Benjamin Kaduk  wrote:
> > 
> > So, when we refine the coord-accuracy and height-accuracy for an
> > instantiation of the grouping, what does that mean?
> 
> It’s supposed to mean the accuracy of the measurement that is recorded in the 
> grouping. So if the coord-accuracy is .1 and the measurement is lat/long then 
> the accuracy is within 1/10 of a decimal degree. if the measurement is in 
> cart coordinates the accuracy would be 100cm. I don’t think we need to make 
> this anymore complex than that. Is there some text you would like to see to 
> make that clearer?

The accuracy of the measurement with respect to what?  The coordinate
system, or the actual physical object?

And, if the concept here is that "I made a measurement, and my measurement
device reported a value to 1/10 of a decimal degree", that would typically
correspond to a "precision" rather than an "accuracy"
(https://en.wikipedia.org/wiki/Accuracy_and_precision).

In either case, I think that "accuracy of the measurement recorded in the
grouping" is a qualitatively different concept of "accuracy" than the
listed accuracy of the geodetic-datum, which (AIUI) relates to the maximum
deviation between the model of the object used by the coordinate system and
the actual physical object.  So it's not really clear that we should be
talking the one "overriding" the other.

-Ben

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

Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT)

2021-07-17 Thread Benjamin Kaduk 
On Sat, Jul 17, 2021 at 02:38:55PM -0400, Christian Hopps wrote:
> 
> Benjamin Kaduk  writes:
> 
> > Hi Christian,
> >
> > Sorry for the very delayed reply (and thanks to Rob for the nudge).
> >
> > On Wed, May 26, 2021 at 06:04:58PM -0400, Christian Hopps wrote:
> >>
> >> Benjamin Kaduk via Datatracker  writes:
> >>
> >> > Benjamin Kaduk has entered the following ballot position for
> >> > draft-ietf-netmod-geo-location-08: 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 DISCUSS and COMMENT positions.
> >> >
> >> >
> >> > The document, along with other ballot positions, can be found here:
> >> > https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/
> >> >
> >> >
> >> >
> >> > --
> >> > DISCUSS:
> >> > --
> >> >
> >> > I think we lack sufficient precision (forgive the pun) in how we talk
> >> > about "accuracy" and "precision".  Are the leafs that claim to specify
> >> > "accuracy" specifying a precision?  If so, the precision of a specific
> >> > measurement, the precision of the measurements that led to the creation
> >> > of the coordinate frame, or something else?  Are they doing so in
> >> > relative terms (e.g., percentage) or absolute terms (e.g., degrees and
> >> > meters)?  (There are "units" directives only for "height-accuracy" and
> >> > not the others.)  How can we we say that we'll have 16 fraction-digits of
> >> > precision for lat/long when the maximum accuracy we can say that a
> >> > geodetic-system has only gives us 6 fraction-digits for coord-accuracy?
> >> > When we say that the "precision of this measurement is indicated by the
> >> > reference-frame" is that the same thing as the relevant "-accuracy"
> >> > nodes, or something else?
> >>
> >> Yes, the geodesic-datum is what defines the values and their accuracy. For 
> >> the
> >> precision in the value we choose the fractional digits based on what might 
> >> be
> >> needed, but not to prescribe anything. For decimal degrees e.g., we only 
> >> need
> >> 100s values the rest can be left to the fractional portion.
> >
> > Unfortunately, even your description here still doesn't help me understand
> > what the intended semantics of these values are.
> >
> > To help illustrate my confusion, here are a few possible things that could
> > be what is intended to be conveyed:
> >
> > - the geodetic-datum description of the object has been measured to be
> >   within a known delta of the actual object being described, at all points
> >   on the object that the coordinate system can describe
> >
> > - the geodetic-datum description of the object is capable of determining
> >   relative differences between points on the object to within a particular
> >   delta of precision, but those individual coordinate values may be farther
> >   than that delta from the actual point on the object that was referred to
> >
> > - the values that are reported in this YANG module reflect measurements
> >   that were made and are known to be within some delta of the coordinate
> >   system's value that they are reported as
> >
> > - the values that are reported in this YANG module reflect measurements
> >   thare are known to be distinguishable from other measurements to within
> >   some delta of other measurements relative to that coordinate system, even
> >   though the actual position being indicated may diverge from the reported
> >   value by more than that delta
> >
> > - the values that are reported in this YANG module reflect measurements
> >   that were made and are known to be within some delta of the actual point
> >   on the object that the coordinates refer to
> >
> > - the values that are reported in this YANG module reflect measurements
> >   that were and are known to be distinguishable from other measurem

Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT)

2021-07-17 Thread Benjamin Kaduk 
Hi Christian,

Sorry for the very delayed reply (and thanks to Rob for the nudge).

On Wed, May 26, 2021 at 06:04:58PM -0400, Christian Hopps wrote:
> 
> Benjamin Kaduk via Datatracker  writes:
> 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-netmod-geo-location-08: 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 DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > I think we lack sufficient precision (forgive the pun) in how we talk
> > about "accuracy" and "precision".  Are the leafs that claim to specify
> > "accuracy" specifying a precision?  If so, the precision of a specific
> > measurement, the precision of the measurements that led to the creation
> > of the coordinate frame, or something else?  Are they doing so in
> > relative terms (e.g., percentage) or absolute terms (e.g., degrees and
> > meters)?  (There are "units" directives only for "height-accuracy" and
> > not the others.)  How can we we say that we'll have 16 fraction-digits of
> > precision for lat/long when the maximum accuracy we can say that a
> > geodetic-system has only gives us 6 fraction-digits for coord-accuracy?
> > When we say that the "precision of this measurement is indicated by the
> > reference-frame" is that the same thing as the relevant "-accuracy"
> > nodes, or something else?
> 
> Yes, the geodesic-datum is what defines the values and their accuracy. For 
> the precision in the value we choose the fractional digits based on what 
> might be needed, but not to prescribe anything. For decimal degrees e.g., we 
> only need 100s values the rest can be left to the fractional portion.

Unfortunately, even your description here still doesn't help me understand
what the intended semantics of these values are.

To help illustrate my confusion, here are a few possible things that could
be what is intended to be conveyed:

- the geodetic-datum description of the object has been measured to be
  within a known delta of the actual object being described, at all points
  on the object that the coordinate system can describe

- the geodetic-datum description of the object is capable of determining
  relative differences between points on the object to within a particular
  delta of precision, but those individual coordinate values may be farther
  than that delta from the actual point on the object that was referred to

- the values that are reported in this YANG module reflect measurements
  that were made and are known to be within some delta of the coordinate
  system's value that they are reported as

- the values that are reported in this YANG module reflect measurements
  thare are known to be distinguishable from other measurements to within
  some delta of other measurements relative to that coordinate system, even
  though the actual position being indicated may diverge from the reported
  value by more than that delta

- the values that are reported in this YANG module reflect measurements
  that were made and are known to be within some delta of the actual point
  on the object that the coordinates refer to

- the values that are reported in this YANG module reflect measurements
  that were and are known to be distinguishable from other measurements of
  points on that object within some delta, but the actual distance from the
  measured point to the point on the object indicated by the reported
  coordinates may be larger than that delta

In short, there are at least three classes of things at play here: the
actual object itself, the coordinate system used to model the object, and
values reported in the YANG module (which are assumed to ultimately derive
from some form of measurement).  To talk about accuracy or precision
implies a relationship between elements of two of those classes, and I
don't even know which of those classes you're trying to talk about.

> > --
> > COMMENT:
> > --
> >
> > (I support Roman's Discuss.)
> >
> > Why do we only de

Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-nmda-diff-09: (with COMMENT)

2021-07-15 Thread Benjamin Kaduk 
Hi Andy,

On Mon, Jul 12, 2021 at 03:42:30PM -0700, Andy Bierman wrote:
> On Thu, Jul 8, 2021 at 2:45 PM Benjamin Kaduk via Datatracker <
> nore...@ietf.org> wrote:
> 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-netmod-nmda-diff-09: 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 DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/
> >
> >
> >
> > --
> > COMMENT:
> > --
> >
> > Thanks to Alexey Melnikov for the secdir review.
> >
> > I'm not experienced enough with YANG to know whether or how problematic
> > it is that the "anydata subtree-filter" node contents are described by
> > reference to the NETCONF specification, which has a particular (XML)
> > representation of YANG data and does not give a clear presentation of
> > the abstract YANG structure/semantics to be used.  Is it possible to use
> > the filter-spec choice option when, for example, RESTCONF is used with
> > JSON encoding?
> >
> >
> 
> There is not a standard specification for subtree filtering using JSON
> encoding
> instead of XML. RESTCONF has its own somewhat compatible filtering
> mechanism.
> It would require a new NETCONF work item to officially expand subtree
> filtering
> to support JSON.  (Unofficially, there is RFC for JSON encoding of YANG
> data and an
> implementation could map the RFC 6241 text to JSON).

Okay, this sounds a little familiar now that you mention it.

Should we mention in a comment of some form that this filtering mechanism
is currently only usable with the XML encoding?

> 
> 
> > Section 4
> >
> >o  report-origin: When set, this parameter indicates that origin
> >   metadata should be included as part of RPC output.  When this
> >   parameter is omitted, origin metadata in comparisons that involve
> >is by default omitted.
> >
> > Why is it important to complicate the semantics of this parameter with a
> > dependence on the datastore?  It seems like it would be simpler to get
> > this effect by having clients specify report-origin when the target is
> > not .  Note that changing the semantics would require text
> > changes in subsequent parts of the document for consistency.  (If
> > retaining the current semantics, please clarify whether "comparisons
> > that involve " applies when operational is source, target,
> > or either.)
> >
> >
> IMO NMDA is way too complicated, so I cannot argue with that complaint.
> The origin attribute only applies to the  datastore.
> I think it is not allowed to appear elsewhere.

Ah, I see what you are saying now (on second read): the "origin" being
reported is the origin attribute of the data in the datastore being
compared, but only the  datastore will every have that
attribute available.  The text here would be a lot more clear if it
reminded the reader that the origin attribute has such a limited scope,
perhaps:

o report-origin: data in the  datastore has an associated
  "origin" attribute that indicates the origin of the reported value.  When
  set, this parameter indicates that the origin metadata should be included
  as part of the RPC output.  It has no effect when the target datastore is
  anything other than .  When this parameter is omitted, the
  origin metadata is omitted from the RPC output.

> 
> Section 9
> >
> > In addition to noting that the "compare" RPC is sensitive and should be
> > restricted to authorized parties, I suggest to reiterate that the
> > "compare" operation should not provide a mechanism to work around access
> > control on other nodes -- that is, a result should only be returned if
> > the requestor would be allowed to access both the "source" and "target"
> > trees independently of the RPC.  In particular, even a "no-matches"
> > output should not be returned, as that might provide a way to determine
> > the structure of the datastore even without accessing it.
> >
> 
> Fortunately the access control model (NACM) is per server and not per
> dat

[netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-nmda-diff-09: (with COMMENT)

2021-07-08 Thread Benjamin Kaduk via Datatracker 
Benjamin Kaduk has entered the following ballot position for
draft-ietf-netmod-nmda-diff-09: 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 DISCUSS and COMMENT positions.


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



--
COMMENT:
--

Thanks to Alexey Melnikov for the secdir review.

I'm not experienced enough with YANG to know whether or how problematic
it is that the "anydata subtree-filter" node contents are described by
reference to the NETCONF specification, which has a particular (XML)
representation of YANG data and does not give a clear presentation of
the abstract YANG structure/semantics to be used.  Is it possible to use
the filter-spec choice option when, for example, RESTCONF is used with
JSON encoding?

Section 4

   o  report-origin: When set, this parameter indicates that origin
  metadata should be included as part of RPC output.  When this
  parameter is omitted, origin metadata in comparisons that involve
   is by default omitted.

Why is it important to complicate the semantics of this parameter with a
dependence on the datastore?  It seems like it would be simpler to get
this effect by having clients specify report-origin when the target is
not .  Note that changing the semantics would require text
changes in subsequent parts of the document for consistency.  (If
retaining the current semantics, please clarify whether "comparisons
that involve " applies when operational is source, target,
or either.)

Section 9

In addition to noting that the "compare" RPC is sensitive and should be
restricted to authorized parties, I suggest to reiterate that the
"compare" operation should not provide a mechanism to work around access
control on other nodes -- that is, a result should only be returned if
the requestor would be allowed to access both the "source" and "target"
trees independently of the RPC.  In particular, even a "no-matches"
output should not be returned, as that might provide a way to determine
the structure of the datastore even without accessing it.

We might also incorporate by reference the security considerations for
subtree filtering (RFC 6241) and xpath filtering (RFC 6991).

NITS

Section 1

   an unusually long time to do so.  This can be the case due to certain
   conditions not being met, certain parts of the configuration not
   propagating because considered inactive, resource dependencies not
   being resolved, or even implementation errors in corner conditions.

"because considered inactive" seems like an incomplete clause; maybe
"because they are considered inactive"?

Section 4

   o  differences: This parameter contains the list of differences.
  Those differences are encoded per YANG-Patch data model defined in

s/YANG-Patch/the YANG-Patch/
I'd also consider s/per/according to/, since this is not exactly a
logic-driven deduction but rather more of a new requirement.

Section 6

   for the management of interfaces defined in [RFC8343].  The excerpt
   of the data model whose instantiation is the basis of the comparison
   is as follows:

I feel like this phrasing is a little misleading, as not only is the
following snippet only a subset of the nodes contained within "container
interfaces" but the descriptions have been greatly abbreviated as well.
Perhaps we could say something about "for the purposes of understanding
the subsequent example, the following subset of the [RFC8343] data model
is provided".

   Accept: application/yang-d

(I believe this truncated header field was already noted by another
reviewer.)



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

[netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT)

2021-05-19 Thread Benjamin Kaduk via Datatracker 
Benjamin Kaduk has entered the following ballot position for
draft-ietf-netmod-geo-location-08: 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 DISCUSS and COMMENT positions.


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



--
DISCUSS:
--

I think we lack sufficient precision (forgive the pun) in how we talk
about "accuracy" and "precision".  Are the leafs that claim to specify
"accuracy" specifying a precision?  If so, the precision of a specific
measurement, the precision of the measurements that led to the creation
of the coordinate frame, or something else?  Are they doing so in
relative terms (e.g., percentage) or absolute terms (e.g., degrees and
meters)?  (There are "units" directives only for "height-accuracy" and
not the others.)  How can we we say that we'll have 16 fraction-digits of
precision for lat/long when the maximum accuracy we can say that a
geodetic-system has only gives us 6 fraction-digits for coord-accuracy?
When we say that the "precision of this measurement is indicated by the
reference-frame" is that the same thing as the relevant "-accuracy"
nodes, or something else?


--
COMMENT:
--

(I support Roman's Discuss.)

Why do we only define velocity in terms of north/east/up, when we could
be in x/y/z coordinates where there is no clear "north" or "east"?

It would have been helpful for the shepherd review to point to the
thread at
https://mailarchive.ietf.org/arch/msg/netmod/dA9olZfEVa3clGdfvNYEFXUEMJw/
that attempted to discuss the feedback from the yangdoctor review -- the
mail with the review itself got no direct replies.

Section 2.1

   In addition to the "geodetic-datum" value, we allow refining the
   coordinate and height accuracy using "coord-accuracy" and "height-

My understanding is that "refine" is a YANG keyword, and the current
module/tree structure does not seem consistent with this description
referring to use of the YANG keyword (since we can just set new values
directly without needing to "refine" the YANG structure itself).  A
different word here might be appropriate.

   Finally, we define an optional feature which allows for changing the
   system for which the above values are defined.  This optional feature
   adds an "alternate-system" value to the reference frame.  This value
   is normally not present which implies the natural universe is the
   system.  The use of this value is intended to allow for creating
   virtual realities or perhaps alternate coordinate systems.  The
   definition of alternate systems is outside the scope of this
   document.

This paragraph doesn't really convince me that we need to include the
"alternate-system" capability in the proposed-standard version of this
YANG module at this time.

Section 2.3

   meters per second.  The values "v-north" and "v-east" are relative to
   true north as defined by the reference frame for the astronomical
   body, "v-up" is perpendicular to the plane defined by "v-north" and
   "v-east", and is pointed away from the center of mass.

When I read this I wondered if the "plane defined by v-north and v-east"
was taken at the initial snapshot position, or continuously updated with
the effect of v-north and v-east drift.  Given the stated application,
it's unlikely that it actually would matter, though, so it's not clear
that we should change the text to cover it.

Section 3

  and 91..126). The IANA registry further restricts the
  value by converting all spaces (' ') to dashes ('-')";

Is there a reason why we shouldn't disallow spaces via the regex (and
obviate the need for special processing at IANA)?

Section 5.1.2

The following subsection suggests that there is a "heading" field in the
W3C structure/API, but I don't see one listed in Figure 1.

Section 6.1

What are suitable references for the "me" and "mola-vik-1" geoedtic
systems?  I do not see how just the listed descriptions provide a "clear
definition" even for the two coordinate values latitude/longitude.

Section 7

Thanks for using the template for security considerations for YANG
models!  I think that since some of the portions of the template do not
ap

Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-factory-default-14: (with COMMENT)

2020-04-27 Thread Benjamin Kaduk 
Hi Qin,

The new updates look good, thanks.

-Ben

On Sun, Apr 26, 2020 at 02:52:15AM +, Qin Wu wrote:
> Hi, Ben:
> -邮件原件-
> 发件人: Benjamin Kaduk [mailto:ka...@mit.edu] 
> 发送时间: 2020年4月25日 3:37
> 收件人: Qin Wu 
> 抄送: The IESG ; draft-ietf-netmod-factory-defa...@ietf.org; 
> netmod-cha...@ietf.org; netmod@ietf.org; Kent Watsen 
> 主题: Re: Benjamin Kaduk's No Objection on 
> draft-ietf-netmod-factory-default-14: (with COMMENT)
> 
> On Thu, Apr 23, 2020 at 04:54:37AM +, Qin Wu wrote:
> > Hi, Ben:
> > Thanks for your valuable comments, see reply inline below.
> > -邮件原件-
> > 发件人: Benjamin Kaduk via Datatracker [mailto:nore...@ietf.org]
> > 发送时间: 2020年4月23日 9:39
> > 收件人: The IESG 
> > 抄送: draft-ietf-netmod-factory-defa...@ietf.org; 
> > netmod-cha...@ietf.org; netmod@ietf.org; Kent Watsen 
> > ; kent+i...@watsen.net
> > 主题: Benjamin Kaduk's No Objection on 
> > draft-ietf-netmod-factory-default-14: (with COMMENT)
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-netmod-factory-default-14: 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-factory-default/
> > 
> > 
> > 
> > --
> > COMMENT:
> > --
> > 
> > While many of the secdir reviewer's complaints stem from the YANG security 
> > considerations boilerplate, it still seems like it would be worth some form 
> > of response to the review.
> > 
> > [Qin]: You are correct, we authors also bring up the discussion on 
> > sec-review comment on YANG security consideration boilerplate to netmod 
> > list. I have sent my response to the sec-review, Thanks for kindly reminder.
> > 
> > Section 1
> > 
> >This document defines a method to reset a server to its factory
> >default content.  The reset operation may be used, e.g., when the
> >existing configuration has major errors so re-starting the
> >configuration process from scratch is the best option.
> > 
> >A "factory-reset" RPC is defined.  When resetting a device, all
> >previous configuration settings will be lost and replaced by the
> >factory default content.
> > 
> > nit: these two paragraphs talk about the same thing, but the next paragraph 
> > is a different thing.  It may be better to combine these two in to a single 
> > paragraph.
> > [Qin]:The format of this section is to first introduce what method we 
> > proposed? And then introduce what this method look like, or two key 
> > components for this method, i.e., one new factory-reset RPC and one new 
> > factory datastore.
> 
> If the first pargaraph is trying to introduce everything, then it should 
> mention both the RPC and the datastore.  Right now, I only see it talking 
> about the RPC (well, the "reset operation"), and thus it does not seem like a 
> general introduction as opposed to an introduction specific to the RPC.
> 
> [Qin]: I see your point, a few clarification: YANG data model will include 
> RPC definition and datastore definition and A device MAY implement the 
> "factory-reset" RPC without
>implementing the "factory-default" datastore. In addition, we want to 
> avoid duplicated text in both abstraction and introduction. Based on this 
> clarification, I propose the following change:
> OLD TEXT:
> "
>This document defines a method to reset a server to its factory
>default content.  The reset operation may be used, e.g., when the
>existing configuration has major errors so re-starting the
>configuration process from scratch is the best option.
> 
>A "factory-reset" RPC is defined.  When resetting a device, all
>previous configuration settings will be lost and replaced by the
>factory default content.
> 
>A "factory-default" read-only datastore is defined, that contains the
>data to replace the contents of implemented read-write conventional
>configuration datastores at reset.  This datastore can also

Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-factory-default-14: (with COMMENT)

2020-04-24 Thread Benjamin Kaduk 
On Thu, Apr 23, 2020 at 04:54:37AM +, Qin Wu wrote:
> Hi, Ben:
> Thanks for your valuable comments, see reply inline below.
> -邮件原件-
> 发件人: Benjamin Kaduk via Datatracker [mailto:nore...@ietf.org] 
> 发送时间: 2020年4月23日 9:39
> 收件人: The IESG 
> 抄送: draft-ietf-netmod-factory-defa...@ietf.org; netmod-cha...@ietf.org; 
> netmod@ietf.org; Kent Watsen ; kent+i...@watsen.net
> 主题: Benjamin Kaduk's No Objection on draft-ietf-netmod-factory-default-14: 
> (with COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-netmod-factory-default-14: 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-factory-default/
> 
> 
> 
> --
> COMMENT:
> --
> 
> While many of the secdir reviewer's complaints stem from the YANG security 
> considerations boilerplate, it still seems like it would be worth some form 
> of response to the review.
> 
> [Qin]: You are correct, we authors also bring up the discussion on sec-review 
> comment on YANG security consideration boilerplate to netmod list. I have 
> sent my response to the sec-review, 
> Thanks for kindly reminder.
> 
> Section 1
> 
>This document defines a method to reset a server to its factory
>default content.  The reset operation may be used, e.g., when the
>existing configuration has major errors so re-starting the
>configuration process from scratch is the best option.
> 
>A "factory-reset" RPC is defined.  When resetting a device, all
>previous configuration settings will be lost and replaced by the
>factory default content.
> 
> nit: these two paragraphs talk about the same thing, but the next paragraph 
> is a different thing.  It may be better to combine these two in to a single 
> paragraph.
> [Qin]:The format of this section is to first introduce what method we 
> proposed? And then introduce what this method look like, or two key 
> components for this method, i.e., one new factory-reset RPC and one new 
> factory datastore.

If the first pargaraph is trying to introduce everything, then it should
mention both the RPC and the datastore.  Right now, I only see it talking
about the RPC (well, the "reset operation"), and thus it does not seem like
a general introduction as opposed to an introduction specific to the RPC.

> I prefer to keep as it is. Maybe we could tweak the first paragraph a little 
> bit as follows:
> "
>This document defines a method to reset a server to its factory
>default content.  This method may be used, e.g., when the
>existing configuration has major errors so re-starting the
>configuration process from scratch is the best option.
> "
>A "factory-default" read-only datastore is defined, that contains the
>data to replace the contents of implemented read-write conventional
>configuration datastores at reset.  [...]
> 
> Can I suggest instead:
> 
> % A "factory-default" read-only datastore is defined, that reflects what the 
> % conventional read-write datastores would be overwritten with in the case of 
> % a factory-reset operation.
> [Qin]: Looks equivalent, but I think the original one is more clear.

To me the phrase "the data to replace the contents of [...] at reset" is
awkward, but your opinion as author trumps mine, here.

> Section 2
> 
>   All security
>sensitive data (i.e., private keys, passwords, etc.)  SHOULD be
>overwritten with zeros or a pattern before deletion.  [...]
> 
> I might suggest instead:
> 
> % When this process includes security-sensitive data such as cryptographic 
> keys or passwords, it is RECOMMENDED to perform the deletion in a manner as  
> thorough as possible (e.g., overwriting the physical storage medium with 
> zeros and/or random bits) to reduce the risk of the sensitive material being 
> recoverable.
> 
> [Qin]: Sounds reasonable to me, thanks.
> It's probably worth noting that since this is only dymanically generated 
> files, any cryptographic keys that are part of the factory-installed image 
> will be retained (such as an IDevID certificate).
>

[netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-factory-default-14: (with COMMENT)

2020-04-22 Thread Benjamin Kaduk via Datatracker 
Benjamin Kaduk has entered the following ballot position for
draft-ietf-netmod-factory-default-14: 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-factory-default/



--
COMMENT:
--

While many of the secdir reviewer's complaints stem from the YANG security
considerations boilerplate, it still seems like it would be worth some form
of response to the review.

Section 1

   This document defines a method to reset a server to its factory
   default content.  The reset operation may be used, e.g., when the
   existing configuration has major errors so re-starting the
   configuration process from scratch is the best option.

   A "factory-reset" RPC is defined.  When resetting a device, all
   previous configuration settings will be lost and replaced by the
   factory default content.

nit: these two paragraphs talk about the same thing, but the next paragraph
is a different thing.  It may be better to combine these two in to a single
paragraph.

   A "factory-default" read-only datastore is defined, that contains the
   data to replace the contents of implemented read-write conventional
   configuration datastores at reset.  [...]

Can I suggest instead:

% A "factory-default" read-only datastore is defined, that reflects what the
% conventional read-write datastores would be overwritten with in the case of
% a factory-reset operation.

Section 2

  All security
   sensitive data (i.e., private keys, passwords, etc.)  SHOULD be
   overwritten with zeros or a pattern before deletion.  [...]

I might suggest instead:

% When this process includes security-sensitive data such as cryptographic
% keys or passwords, it is RECOMMENDED to perform the deletion in as
% thorough a manner as possible (e.g., overwriting the physical storage
% medium with zeros and/or random bits) to reduce the risk of the sensitive
% material being recoverable.

It's probably worth noting that since this is only dymanically generated
files, any cryptographic keys that are part of the factory-installed image
will be retained (such as an IDevID certificate).

Section 3

   Following the guidelines for defining Datastores in the appendix A of
   [RFC8342], this document introduces a new optional datastore resource
   named "factory-default" that represents a preconfigured initial
   configuration that can be used to initialize the configuration of a

nit/soapbox: "preconfigured initial configuration" feels like an awkward
wording to me; perhaps "pre-set initial configuration" or "fixed initial
configuration"?

Section 4

description
  "This read-only datastore contains the factory default
  configuration for the device used to replace the contents
  of the read-write conventional configuration datastores
  during a 'factory-reset' RPC operation.";

nit: the grammar here is off; maybe "for the device that will be used"?
(Or some adaptation of my proposed text from earlier.)

Section 6

If the factory-default configuration is an "open" one, then performing the
reset could leave the device (and thus the network!) vulnerable to attack
until it is properly configured.  The rtgdir reviewer's comments seem
related to this.

An attacker that could somehow cause the factory-reset to be performed would
cause the loss of running state/crypto keys that would potentially require a
lot of operator effort to recover (in addition to the more immediate DoS
issues).

There is some discussion in draft-ietf-anima-bootstrapping-keyinfra about
attacks that are possible when a device is restored to its factory default
state; it might be worth trying to incorporate some of that discussion in
some manner (whether inline or by reference).

   The "factory-reset" RPC can prevent any further management of the
   device if the session and client config are included in the factory
   default contents.

I'm not sure this is 100% correct.  If the factory default config overwrites
this items, then yes, it will prevent further management.  But we also say
to delete dynamic files from nonvoliatile storage, which at least to me
seems like it could include this class of items and cause the same symptoms
even if the configuration items in question are not included in the factory
default contents.



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

[netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-module-tags-10: (with COMMENT)

2020-03-15 Thread Benjamin Kaduk via Datatracker 
Benjamin Kaduk has entered the following ballot position for
draft-ietf-netmod-module-tags-10: 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-module-tags/



--
COMMENT:
--

Thank you for addressing my Discuss (and comment) points!



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

Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS and COMMENT)

2020-01-31 Thread Benjamin Kaduk 
Sorry for letting this sit so long; I must have missed it somewhere (and
thanks Alissa for the reminder!)

On Fri, May 03, 2019 at 01:48:45PM -0400, Christian Hopps wrote:
> 
> 
> > On Apr 11, 2019, at 9:49 AM, Benjamin Kaduk via Datatracker 
> >  wrote:
> > 
> > --
> > DISCUSS:
> > --
> > 
> > I think this document does introduce new security considerations,
> > specifically the ability for one user to remove ("mask") tags from being
> > visible to other users.  A malicious user could interfere with the
> > operations of other users/entities, especially in the case mentioned in
> > an example where multiple semi-independent clients use tags to indicate
> > modules to avoid that may be broken.
> 
> So here was the thinking on this, since this document doesn't define any 
> actions or behaviors based on tags (or the lack of them) it's hard to talk 
> about what the security considerations would be. However, it is expected that 
> to be useful users (or future specifications) *will* define behaviors based 
> on tag use. The security section does talk about this case:
> 
> "
>Users of the tag-meta data may define various actions to be taken
>based on the tag meta-data.  These actions and their definitions are
>outside the scope of this document.  Users will need to consider the
>security implications of any actions they choose to define.
> "
> 
> Which I believe covered this. For example, if an RFC were to define a 
> behavior based on the tag presence then it would need to talk about the 
> security concerns with that behavior.

In some sense it covers this, but my Discuss is more about the
somewhat-subtle point involving somewhat "long-range" interactions that it
doesn't seem reasonable to expect people specifying tags to think about
without help.

> If this doesn't adequately cover your concern though, do you have a bit of 
> suggested text we could add?

I'd suggest to add another clause at the end of the paragraph you quoted:
", including the potential for a tag to get 'masked away' by another user."

> > --
> > COMMENT:
> > --
> 
> > 
> > Section 2
> > 
> > Similarly to Alissa's DISCUSS, perhaps "registered prefix" is better
> > than "standard prefix".
> > 
> > Section 2.4
> > 
> > Similarly, "future registration" or "future use" seem to be better fits
> > for the intended sentiment.
> > 
> > Section 3.2
> > 
> > I may be misreading, but this seems to be encouraging implementations to
> > add new ietf:-prefixed tags that are not necessarily registered or
> > specified in IETF-consensus documents.
> > 
> > Section 7.2
> > 
> >   This registry allocates prefixes that have the standard prefix
> >   "ietf:".  [...]
> > 
> > The registry name just talks about "tags"; are we really allocating
> > *prefix*es?
> > 
> 
> Fixed these, thanks.

Thanks!

-Ben

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

Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-artwork-folding-11: (with DISCUSS and COMMENT)

2020-01-20 Thread Benjamin Kaduk 
Hi Kent!

On Tue, Jan 21, 2020 at 01:05:38AM +, Kent Watsen wrote:
> Hi Ben,
> 
> Erik and I addressed the regression issue raised below, and made a few other 
> minor improvements to the non-normative `rfcfold` script.
> 
> Here is a direct link to the diff: 
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-artwork-folding-12.txt 
> 
> 
> Please let us know if there are anymore improvements to be made.
> 
> Thanks!
> Kent (and Erik)

I don't see any further improvements; this looks really nice now.
(I assume Erik was consulted about the Acknowledgments change (and trust
the RFC Editor to spell "Acknowledgments" according to house style) that's
also part of the -12.)

I'm updating my position in the datatracker now.

-Ben

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

[netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-artwork-folding-11: (with DISCUSS and COMMENT)

2020-01-09 Thread Benjamin Kaduk via Datatracker 
Benjamin Kaduk has entered the following ballot position for
draft-ietf-netmod-artwork-folding-11: 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-artwork-folding/



--
DISCUSS:
--

Thank you for the updates in the -10 and -11; the content looks a lot better and
I am not uncomfortable about publishing as Informational (vs. BCP)!

That said, I think the edits to the script have introduced a regression:

 # ensure input file doesn't contain the fold-sequence already
 if [[ -n "$("$SED" -n '/\\$/{N;s/\\\n[ ]*\\/&/p}' "$infile")" ]]

Unfortunately, I'm not sure this gets all cases, since the 'N' command
reads a line and prevents it from being considered as the first half of the
wrapped sequence:

kaduk$:~/git/openssl$ cat /tmp/a
this is a line\
another line\
\that wraps
kaduk$:~/git/openssl$ cat /tmp/b
this is a line
another line\
\that wraps
kaduk$:~/git/openssl$ sed -n '/\\$/{N;s/\\\n[ ]*\\/&/p}' < /tmp/a
kaduk$:~/git/openssl$ sed -n '/\\$/{N;s/\\\n[ ]*\\/&/p}' < /tmp/b
another line\
\that wraps


--
COMMENT:
--

A few other comments from reviewing the version of the script in the -11:

When processing input, it's perhaps more robust to check $# before assigning $2
to a named parameter.

 printf "Exit status code: 1 on error, 0 on success, 255 on no-op."

Interesting to have no newline here but two on the next line's printf, but I
guess it might be at the column limit already.

(The quotes on 'Error'/'Warning'/'Debug' in err()/warn()/dbg() are noops.)

   # warn if a non-GNU sed utility is used
   "$SED" --version < /dev/null 2> /dev/null \
   | grep GNU > /dev/null 2>&1 || \

`grep -q` should be usable instead of `grep >/dev/null`


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

[netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-yang-data-ext-04: (with COMMENT)

2019-12-03 Thread Benjamin Kaduk via Datatracker 
Benjamin Kaduk has entered the following ballot position for
draft-ietf-netmod-yang-data-ext-04: 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-yang-data-ext/



--
COMMENT:
--

Section 1

   The "yang-data" extension from [RFC8040] has been copied here,
   renamed to "structure", and updated to be more flexible.  There is no

The Gen-Art reviewer had a good comment on this that should be acted
upon.

Section 2

   This does not mean a YANG data structure has to be used as a top-
   level protocol message or other top-level data structure.

I was confused by this until I got through Section 4, which (I think!)
clarified that I need a top-level extension directive to "declare the
named structure", but this is saying that once the structure is
declared, it can be placed anywhere in the tree as a "node of structure
type".  Perhaps we could add a few words here to clarify, e.g., "YANG
data structure, once defined," or "A YANG data structure can be used as
any other data type, in the rest of the module"?

Section 3

Do we need to say anything about how the child s under
structure/augment-structure get printed?  (I assume they get the same
handling as for the datastore tree, but could be wrong.)

   The new sections, including spaces conventions is:

   structure :

(I see four spaces between the column the paragraph starts in and the
column the "structure" keyword starts in, not two.)

   [augment-structure]
   [...]
 The sub-statements of this extension MUST follow the ABNF
  rules below, where the rules are defined in RFC 7950:

[status-stmt]
[description-stmt]
[reference-stmt]
1*(data-def-stmt / case-stmt)

Comparing to RFC 7950's augment-stmt, we see that when-stmt and
if-feature-stmt are not present; would those be used externally to the
augment-structure declaration if needed?

Section 6

I might consider adding a note that the data being modelled might have
its own security considerations, but there's a pretty good case that
this is already covered in RFC 7950 and thus would be redundant here.

Appendix A.1

Using last+first as the only naming options (and the list keys) is
perhaps a bit unfortunate, given, e.g.,
https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
(which has been popularized several times on varous social-media sites
over the years).
I suppose it still suffices for the purposes of this example, though.

Appendix A.3, A.4

As Alexey notes, maybe have two address entries in the example so that the 
reader sees
the encoding of the list structure?


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

Re: [netmod] [Last-Call] Yangdoctors last call review of draft-ietf-netmod-factory-default-07

2019-11-28 Thread Benjamin Kaduk 
On Wed, Nov 27, 2019 at 06:35:24AM -0800, Carl Moberg via Datatracker wrote:
> Reviewer: Carl Moberg
> Review result: Ready with Nits
> 
> This is my YANG doctors review of the ietf-factory-default.yang module as
> part of draft-ietf-netmod-factory-default-07.
> 
> The module cleanly passes validation using the YANG validator site and
> I have successfully loaded it into one NETCONF server implementation.
> 
> This module is ready with a cosmetic nit and a suggestion.
> 
> I suggest fixing the following textual nit:
> 
> OLD
>configuration datastores (i.e., , ) to
>their factory default content.";
> 
> NEW:
>configuration datastores (i.e. , , and
>) to their factory default content.";

FWIW, the RFC style guide wants both comma and space after "i.e." (and
comma before it, as well, when not enclosed in a parenthetical).

-Ben

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

Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-artwork-folding-09: (with DISCUSS and COMMENT)

2019-09-10 Thread Benjamin Kaduk 
On Thu, Sep 05, 2019 at 10:02:03PM +, Kent Watsen wrote:
> Hi Ben,
> 
> Thank you for your review.  Comments below.
> 
> Update @ https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-10 
> <https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-10>
> 
> Kent // as co-author
> 
> 
> > On Sep 5, 2019, at 2:07 AM, Benjamin Kaduk via Datatracker 
> >  wrote:
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-netmod-artwork-folding-09: 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-artwork-folding/
> > 
> > 
> > 
> > --
> > DISCUSS:
> > --
> > 
> > I think the procedures described herein are incomplete without a footer
> > to terminate the un-folding process.  Otherwise, it seems that the
> > described algorithms would leave the two-line header for the second and
> > subsequent instances of folded text in a single document.  (If we tried
> > to just blindly remove all instances of the header without seeking
> > boundaries, then we would misreconstruct content when different folding
> > algorithms are used in the same document with the single-backslash
> > algorithm occurring first.)
> 
> Are you referring to when an RFC contains multiple inclusions and one is
> trying to unfold them all at once?   That's not the intention here, as

Yes, that was what I was thinking; sorry for missing or misinterpreting the
notes in Sections 7.2/8.2.

> noted in paragraph 3 in both sections 7.2 and 8.2.  FWIW, this sounds
> like the framing problem that the WG discussed with the conclusion that
> extracting from plain-text is dead, now that XML is the required
> submission format, and XML provides a superior framing mechanism than any
> footer we could add.
> 
> BTW, yes, each text inclusion in a single RFC may independently be folded
> using either the '\' or '\\' strategy, with the recommendation that '\'
> always be tried first and '\\' only used when '\' fails.
> 
> If referring to a single text content instance, could you provide an
> example illustrating the concern?
> 
> 
> 
> 
> > I don't think it's proper to refer to a script that requires bash
> > specifically as a "POSIX shell script".  I did not attmept to check
> > whether any bash-specific features are used or this requirements stems
> > solely from the shebang line, though.
> 
> I just changed "POSIX" to "Bash" in the title for Appendix A.
> 
> Not that it matters, but "--posix" is passed into `bash` on the first
> line of the script  ;)
> 
> 
> 
> > I think the shell script does need to use double-quotes around some
> > variable expansions, especially "$infile" and "$outfile", to work
> > properly for filenames containing spaces.  We do quote "$infile" when
> > we're checking that it exists, just not (most of the time) when we
> > actually use it!
> 
> Updated.
> 
> 
> 
> > In addition to the above, I also share Alissa's (and Mirja's) concerns,
> > but feel that Discuss is more appropriate than Abstain, so we can
> > discuss what the best way to get this content published is.  For it's
> > fine content, and we should see it published; it's just not immediately
> > clear to me what the right way to do so is.
> 
> Agreed.   For now, I've changed it to Informational, but I think there
> remains a discussion around if the draft should be re-rerun through the
> IAB stream.   My responses today to Alissa's Abstain and Suresh Discuss
> dig into this.  Is it okay to use those threads for this item?

Please do; this point was mostly intended to make sure that we didn't
inadvertently approve the document while those discussions were still going
on.

> 
> > --
> > COMMENT:
> > --
> > 
> > Section 4.1
> > 
> >   Automated folding of long lines is needed in order to support draft
> &

[netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-artwork-folding-09: (with DISCUSS and COMMENT)

2019-09-05 Thread Benjamin Kaduk via Datatracker 
Benjamin Kaduk has entered the following ballot position for
draft-ietf-netmod-artwork-folding-09: 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-artwork-folding/



--
DISCUSS:
--

I think the procedures described herein are incomplete without a footer
to terminate the un-folding process.  Otherwise, it seems that the
described algorithms would leave the two-line header for the second and
subsequent instances of folded text in a single document.  (If we tried
to just blindly remove all instances of the header without seeking
boundaries, then we would misreconstruct content when different folding
algorithms are used in the same document with the single-backslash
algorithm occurring first.)

I don't think it's proper to refer to a script that requires bash
specifically as a "POSIX shell script".  I did not attmept to check
whether any bash-specific features are used or this requirements stems
solely from the shebang line, though.

I think the shell script does need to use double-quotes around some
variable expansions, especially "$infile" and "$outfile", to work
properly for filenames containing spaces.  We do quote "$infile" when
we're checking that it exists, just not (most of the time) when we
actually use it!

In addition to the above, I also share Alissa's (and Mirja's) concerns,
but feel that Discuss is more appropriate than Abstain, so we can discuss
what the best way to get this content published is.  For it's fine
content, and we should see it published; it's just not immediately clear
to me what the right way to do so is.


--
COMMENT:
--

Section 4.1

   Automated folding of long lines is needed in order to support draft
   compilations that entail a) validation of source input files (e.g.,
   XML, JSON, ABNF, ASN.1) and/or b) dynamic generation of output, using
   a tool that doesn't observe line lengths, that is stitched into the
   final document to be submitted.

I don't think the intended meaning of "source input files" will be clear
to all readers just from this text.  Some discussion of how RFCs can
consider source code, data structures, generated output, etc., that have
standalone representations and natural formats, and the need to display
their contents in the RFC format that has different requirements might
be helpful context for this paragraph and the next.

Section 7.1.2

For some reason my mental model of "RFC style" does not use the word
"really" in this way, and prefers alternatives like "very" or
"exceptionally".  (Also in Section 8.1.2.)

Section 7.2.1

   1.  Determine where the fold will occur.  This location MUST be
   before or at the desired maximum column, and MUST NOT be chosen
   such that the character immediately after the fold is a space ('
   ') character.  For forced foldings, the location is between the

This is a rather awkward natural line break.  I suggest an RFC Editor
note to make sure that the punctuation around the space character all
appears on the same line.

   3.  On the following line, insert any number of space (' ')
   characters.

I'm not sure I'd characterize the procedure as "complete" when it leaves
the value of the output subject to implementation choice such as this.
(Note that the next paragraph talks about the resulting "arbitrary
number of space" characters, and would presumably also need to be
adjusted if this text was adjusted.)
We also don't seem to bound this number of spaces to be fewer than the
target line length, which only matters in some weirdly pedantic sense.

Section 7.2.2

   Scan the beginning of the text content for the header described in
   Section 7.1.1.  If the header is not present, starting on the first
   line of the text content, exit (this text contents does not need to
   be unfolded).

I'm not sure I understand what "starting on the first line of the text
content" is intended to mean.  (Also in 8.2.2.)

Section 8.2.1

   If this text content needs to and can be folded, insert the header
   described in Section 8.1.1, ensuring that any additional printable
   characters surrounding the header do not result in a line exceeding
   the desired maximum.

We discussed above some cases when text could not be folded using the
algorit

[netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS and COMMENT)

2019-04-11 Thread Benjamin Kaduk via Datatracker 
Benjamin Kaduk has entered the following ballot position for
draft-ietf-netmod-module-tags-07: 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-module-tags/



--
DISCUSS:
--

I think this document does introduce new security considerations,
specifically the ability for one user to remove ("mask") tags from being
visible to other users.  A malicious user could interfere with the
operations of other users/entities, especially in the case mentioned in
an example where multiple semi-independent clients use tags to indicate
modules to avoid that may be broken.


--
COMMENT:
--

Section 2

Similarly to Alissa's DISCUSS, perhaps "registered prefix" is better
than "standard prefix".

Section 2.4

Similarly, "future registration" or "future use" seem to be better fits
for the intended sentiment.

Section 3.2

I may be misreading, but this seems to be encouraging implementations to
add new ietf:-prefixed tags that are not necessarily registered or
specified in IETF-consensus documents.

Section 7.2

   This registry allocates prefixes that have the standard prefix
   "ietf:".  [...]

The registry name just talks about "tags"; are we really allocating
*prefix*es?


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

Re: [netmod] Genart last call review of draft-ietf-netmod-module-tags-06

2019-03-08 Thread Benjamin Kaduk 
Going up to a more general topic (and ignoring the particulars here):

On Wed, Mar 06, 2019 at 05:50:00PM -0500, Christian Hopps wrote:
> Thanks for the review! Comments inline.
> 
> > On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies 
> >  wrote:
> > 
> > 
> > Minor issues:
> > Abstract/s1: I would judge that RFC 8407 ought to be normative since it is
> > updated.
> 
> RFC8407 is a BCP not a Standard though so I don't think it's appropriate to 
> make it normative.

I'm confused by this statement.  BCPs are considered to be standards-track,
and a reference from a PS document to a BCP is not considered a downref.
Is the objection that "best current practices" are just that (practices)
and not part of a mandatory protocol specification?

We do have BCP 195 (RFC 7525), "Recommendations for Secure Use of Transport
Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", which
are indeed recommendations and best practices for use of TLS in general,
and as such can apply to anything using TLS, even existing deployed systems
and protocols.  But we can also have new protocols that say "it is
mandatory to comply with the behavior described in RFC 7525", and to me
that is a normative part of the spec.

So I'd like a better understanding of your stance here.

Thanks,

Ben

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

Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-schema-mount-11: (with COMMENT)

2018-10-15 Thread Benjamin Kaduk 
On Mon, Oct 15, 2018 at 09:33:09AM +0200, Martin Bjorklund wrote:
> Hi,
> 
> Benjamin Kaduk  wrote:
> > On Wed, Oct 10, 2018 at 03:35:28PM +0200, Martin Bjorklund wrote:
> > > Hi,
> > > 
> > > Benjamin Kaduk  wrote:
> > > > Benjamin Kaduk has entered the following ballot position for
> > > > draft-ietf-netmod-schema-mount-11: 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-schema-mount/
> > > > 
> > > > 
> > > > 
> > > > --
> > > > COMMENT:
> > > > --
> > > > 
> > > > Whenever we introduce a new namespace "sub-hierarchy" there is some 
> > > > level
> > > > of risk about surpirses with respect to the security properties of the
> > > > combined system.  I appreciate that the mounted schemas are "jailed" 
> > > > into
> > > > their own subtree except for the specific exceptions for XPath access,
> > > > which helps a lot.  But there may still be potential for surprise with
> > > > respect to, e.g., access control on mounted schemas, if an administrator
> > > > previously assumed that such controls would only be needed at the
> > > > top-level.  The document itself doesn't give me a great picture of to 
> > > > what
> > > > extent these risks and the possible consequences of the new nested
> > > > structure have been considered; I'd be happy to hear if they've been
> > > > thought about a lot already and the conclusion was that the situation 
> > > > is so
> > > > boring that nothing needs to be mentioned in the document.
> > > 
> > > The intention was that this is covered in Section 7, Interaction with
> > > the Network Configuration Access Control Model (NACM).
> > > 
> > > But it is probably a good idea to explicitly mention this in the
> > > Security Considerations section as well (together with your last point
> > > below).  So maybe add a paragraph at the end of Section 11:
> > > 
> > >   It is important to take the security considerations for all nodes in
> > >   the mounted schemas into account, and control access to these nodes
> > >   by using the mechanism described in Section 7.
> > 
> > I guess this addresses my concern; thanks.
> > 
> > > > Section 3.3
> > > > 
> > > >If multiple mount points with the same name are defined in the same
> > > >module - either directly or because the mount point is defined in a
> > > >grouping and the grouping is used multiple times - then the
> > > >corresponding "mount-point" entry applies equally to all such mount
> > > >points.
> > > > 
> > > > Does this mean that the multiple mount points must serve the same
> > > > data/contents, or just that they must use the same schema?
> > > > (Is this related to "inline" vs. "shared-schema"?)
> > > 
> > > No, this document intentionally doesn't assume anything about the
> > > source of the instance data (as explained in section 1).  So the
> > > answer is that they just use the same schema.
> > > 
> > > > Section 3.4
> > > > 
> > > > So this means that there can be multiple
> > > > ietf-yang-schema-mount:schema-mounts:mount-point nodes at different
> > > > locations in the hierarchy?  When I was first reading the document, the
> > > > design seemed fairly clean with just a single list of mount-points at 
> > > > the
> > > > "top-level" that tracks everything, but this kind of recursion seems 
> > > > like
> > > > it would make implementation potentially quite complex.  What kind of
> > > > implementat

Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-schema-mount-11: (with COMMENT)

2018-10-11 Thread Benjamin Kaduk 
On Wed, Oct 10, 2018 at 03:35:28PM +0200, Martin Bjorklund wrote:
> Hi,
> 
> Benjamin Kaduk  wrote:
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-netmod-schema-mount-11: 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-schema-mount/
> > 
> > 
> > 
> > --
> > COMMENT:
> > --
> > 
> > Whenever we introduce a new namespace "sub-hierarchy" there is some level
> > of risk about surpirses with respect to the security properties of the
> > combined system.  I appreciate that the mounted schemas are "jailed" into
> > their own subtree except for the specific exceptions for XPath access,
> > which helps a lot.  But there may still be potential for surprise with
> > respect to, e.g., access control on mounted schemas, if an administrator
> > previously assumed that such controls would only be needed at the
> > top-level.  The document itself doesn't give me a great picture of to what
> > extent these risks and the possible consequences of the new nested
> > structure have been considered; I'd be happy to hear if they've been
> > thought about a lot already and the conclusion was that the situation is so
> > boring that nothing needs to be mentioned in the document.
> 
> The intention was that this is covered in Section 7, Interaction with
> the Network Configuration Access Control Model (NACM).
> 
> But it is probably a good idea to explicitly mention this in the
> Security Considerations section as well (together with your last point
> below).  So maybe add a paragraph at the end of Section 11:
> 
>   It is important to take the security considerations for all nodes in
>   the mounted schemas into account, and control access to these nodes
>   by using the mechanism described in Section 7.

I guess this addresses my concern; thanks.

> > Section 3.3
> > 
> >If multiple mount points with the same name are defined in the same
> >module - either directly or because the mount point is defined in a
> >grouping and the grouping is used multiple times - then the
> >corresponding "mount-point" entry applies equally to all such mount
> >points.
> > 
> > Does this mean that the multiple mount points must serve the same
> > data/contents, or just that they must use the same schema?
> > (Is this related to "inline" vs. "shared-schema"?)
> 
> No, this document intentionally doesn't assume anything about the
> source of the instance data (as explained in section 1).  So the
> answer is that they just use the same schema.
> 
> > Section 3.4
> > 
> > So this means that there can be multiple
> > ietf-yang-schema-mount:schema-mounts:mount-point nodes at different
> > locations in the hierarchy?  When I was first reading the document, the
> > design seemed fairly clean with just a single list of mount-points at the
> > "top-level" that tracks everything, but this kind of recursion seems like
> > it would make implementation potentially quite complex.  What kind of
> > implementation experience do we have that can replace my half-informed
> > suppositions about complexity?
> 
> I agree with you that multiple levels of mounting probably can be
> complex.  But there is nothing in the design of schema mount that
> prohibits this.  In fact, it "falls out for free" from the design.
> 
> A 2-level example is a physical device with LNEs
> (draft-ietf-rtgwg-lne-model) which has NIs
> (draft-ietf-rtgwg-ni-model).
> 
> > Section 4
> > 
> >Therefore, schema mount also allows for such references.  For every
> >mount point in the "shared-schema" case, it is possible to specify a
> >leaf-list named "parent-reference" that contains zero or more XPath
> >1.0 expressions.  [...]
> > 
> > editorial: """the "shared-schema" case""" reads oddly to me; it might be
> > clearer to refer to schemas mounted using "shared-schema&

[netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-schema-mount-11: (with COMMENT)

2018-10-09 Thread Benjamin Kaduk 
Benjamin Kaduk has entered the following ballot position for
draft-ietf-netmod-schema-mount-11: 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-schema-mount/



--
COMMENT:
--

Whenever we introduce a new namespace "sub-hierarchy" there is some level
of risk about surpirses with respect to the security properties of the
combined system.  I appreciate that the mounted schemas are "jailed" into
their own subtree except for the specific exceptions for XPath access,
which helps a lot.  But there may still be potential for surprise with
respect to, e.g., access control on mounted schemas, if an administrator
previously assumed that such controls would only be needed at the
top-level.  The document itself doesn't give me a great picture of to what
extent these risks and the possible consequences of the new nested
structure have been considered; I'd be happy to hear if they've been
thought about a lot already and the conclusion was that the situation is so
boring that nothing needs to be mentioned in the document.

Section 3.3

   If multiple mount points with the same name are defined in the same
   module - either directly or because the mount point is defined in a
   grouping and the grouping is used multiple times - then the
   corresponding "mount-point" entry applies equally to all such mount
   points.

Does this mean that the multiple mount points must serve the same
data/contents, or just that they must use the same schema?
(Is this related to "inline" vs. "shared-schema"?)

Section 3.4

So this means that there can be multiple
ietf-yang-schema-mount:schema-mounts:mount-point nodes at different
locations in the hierarchy?  When I was first reading the document, the
design seemed fairly clean with just a single list of mount-points at the
"top-level" that tracks everything, but this kind of recursion seems like
it would make implementation potentially quite complex.  What kind of
implementation experience do we have that can replace my half-informed
suppositions about complexity?

Section 4

   Therefore, schema mount also allows for such references.  For every
   mount point in the "shared-schema" case, it is possible to specify a
   leaf-list named "parent-reference" that contains zero or more XPath
   1.0 expressions.  [...]

editorial: """the "shared-schema" case""" reads oddly to me; it might be
clearer to refer to schemas mounted using "shared-schema" instead.  As in,
"""For every mount point under "shared-schema", [...]"""

Can we get a reference added for XPath?

It's still a little unclear to me exactly how a node in the mounted tree
constructs an XPath expression to refer to the parent-reference nodes, but
I did not read very far down the reference chain and maybe this is going to
be clear to a practitioner without any more text in the document.
Basically, do I need to know where I am mounted in order to construct
references to nodes in the parent?

Section 7

NACM "can be used" to control access to mounted nodes.  Is there a risk
that administrators will be "unpleasantly surprised" by mounted nodes by
default not receiving access control, in cases when access control is
already configured at the top level?

Section 9

Should the top-level module description be using the RFC 8174 boilerplate
instead of thet 2119 boilerplate?

Should the requirement for servers that mount any schema to also mount
ietf-yang-library under the mountpoint be mentioned somewhere other than
the description for the 'inline' and 'shared-schema' containers (i.e., in
the discussion text)?

Section 11

We should probably also have some bland statement about how "the security
considerations for mounted schemas continue to apply to the nodes in the
mounted tree".


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

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

2018-09-28 Thread Benjamin Kaduk 
Hi Mahesh,

On Wed, Sep 26, 2018 at 11:25:37AM -0700, Mahesh Jethanandani wrote:
> Hi Benjamin,
> 
> > On Sep 26, 2018, at 10:31 AM, Benjamin Kaduk  wrote:
> > 
> > Benjamin Kaduk 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:
> > --
> > 
> > I think this is good work to have, overall, and the document pretty easy to 
> > read.
> > That said, I think the Security Considerations need to be expanded a bit 
> > more before
> > this document get published:
> > 
> >  Write operations (e.g., )
> >   to these data nodes without proper protection can have a negative
> >   effect on network operations.
> > 
> > I think the effects can be on more than just *network* operations, there
> > can be negative effects for end systems that (e.g.) experience DoS attacks
> > that would otherwise have been blocked, receive maliciously crafted packets
> > that trigger application bugs, are used as part of (e.g.) UDP amplification
> > attacks, etc.
> 
> How about this?
> 
> OLD:
>Write operations (e.g., )
>to these data nodes without proper protection can have a negative
>effect on network operations.
> 
> 
> NEW:
>Write operations (e.g., )
>to these data nodes without proper protection can have a negative
>effect on network operations and end systems. The end systems, for
>example, can experience DoS attacks that would otherwise have been blocked,
>and receive maliciously crafted packets that trigger applications bugs.

That looks great; thanks!

> > 
> >  /acls/acl/aces: This list specifies all the configured access
> >  control entries on the device.  Unauthorized write access to this
> >  list can allow intruders to access and control the system.
> >  Unauthorized read access to this list can allow intruders to spoof
> >  packets with authorized addresses thereby compromising the system.
> 
> Back in July we went through this section, and here was the change that was 
> proposed, that Steve had accepted. Since they were provided for the current 
> version of the draft (-19), they were not applied till we had received all 
> the reviews. Were you looking for changes in addition to this?
> 
> OLD:
>   /acls/acl/aces: This list specifies all the configured access
>   control entries on the device.  Unauthorized write access to this
>   list can allow intruders to access and control the system.
>   Unauthorized read access to this list can allow intruders to spoof
>   packets with authorized addresses thereby compromising the system.
> 
> 
> NEW:
>   /acls/acl/aces: This list specifies all the configured access
>   control entries on the device.  Unauthorized write access to this
>   list can allow intruders to modify the entries so as to permit traffic
>   that should not be permitted, or deny traffic that should be permitted.
>   The former may result in a DoS attack, or compromise the device.
>   The latter may result in a DoS attack. The impact of an unauthorized 
>   read access to the list will allow the attacker to determine which rules
>   are in effect, to better craft an attack.

Ah, I was just looking at the -19 as-is and didn't read to the end of the
secdir thread.  This text is also good; I'll clear my discuss.

> 
> > 
> > I agree with the secdir reviewer that "the system" needs to be clarified,
> > and that the consequences of unauthorized write and read access need to be
> > more clearly described.
> > His proposed text is much better than the present text, though there are
> > other ways to convey the needed information.
> > 
> > 
> > --
> > COMMENT:
> > --
> > 
> > I tried

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

2018-09-26 Thread Benjamin Kaduk 
It looks like I was thinking of the review of draft-ietf-opsawg-nat-yang,
not this one -- sorry for the mixup!  (And thanks for spotting the issue!)

-Benjamin

On Wed, Sep 26, 2018 at 02:39:23PM -0700, Alissa Cooper wrote:
> This is in the -19:
> 
> /*
> * Logging actions for a packet
> */
>identity log-action {
>  description
>"Base identity for defining the destination for logging actions";
>}
> 
>identity log-syslog {
>  base log-action;
>  description
>"System log (syslog) the information for the packet";
>}
> 
>identity log-none {
>  base log-action;
>  description
>"No logging for the packet";
>}
> Is there a more recent version?
> 
> Thanks,
> Alissa
> 
> > On Sep 26, 2018, at 2:25 PM, Benjamin Kaduk  wrote:
> > 
> > Just on the logging point...
> > 
> > On Wed, Sep 26, 2018 at 02:20:49PM -0700, Alissa Cooper wrote:
> >> 
> >> Sec 5:
> >> 
> >> In this section or elsewhere it would be nice to see a sentence noting that
> >> this YANG model allows the configuration of packet logging, which if used 
> >> would
> >> additionally warrant protections against unauthorized log access and a logs
> >> retention policy.
> > 
> > My understanding is that this was removed entirely from the document in
> > response to the secdir review.  Could you double-check which version you
> > were looking at, or if the current version still is problematic?
> > 
> > Thanks,
> > 
> > Benjamin
> 

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

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

2018-09-26 Thread Benjamin Kaduk 
Just on the logging point...

On Wed, Sep 26, 2018 at 02:20:49PM -0700, Alissa Cooper wrote:
> 
> Sec 5:
> 
> In this section or elsewhere it would be nice to see a sentence noting that
> this YANG model allows the configuration of packet logging, which if used 
> would
> additionally warrant protections against unauthorized log access and a logs
> retention policy.

My understanding is that this was removed entirely from the document in
response to the secdir review.  Could you double-check which version you
were looking at, or if the current version still is problematic?

Thanks,

Benjamin

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

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

2018-09-26 Thread Benjamin Kaduk 
Benjamin Kaduk 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:
--

I think this is good work to have, overall, and the document pretty easy to 
read.
That said, I think the Security Considerations need to be expanded a bit more 
before
this document get published:

  Write operations (e.g., )
   to these data nodes without proper protection can have a negative
   effect on network operations.

I think the effects can be on more than just *network* operations, there
can be negative effects for end systems that (e.g.) experience DoS attacks
that would otherwise have been blocked, receive maliciously crafted packets
that trigger application bugs, are used as part of (e.g.) UDP amplification
attacks, etc.

  /acls/acl/aces: This list specifies all the configured access
  control entries on the device.  Unauthorized write access to this
  list can allow intruders to access and control the system.
  Unauthorized read access to this list can allow intruders to spoof
  packets with authorized addresses thereby compromising the system.

I agree with the secdir reviewer that "the system" needs to be clarified,
and that the consequences of unauthorized write and read access need to be
more clearly described.
His proposed text is much better than the present text, though there are
other ways to convey the needed information.


--
COMMENT:
--

I tried to call out the editorial nits as such; there are a couple non-editorial
comments embedded within.

Section 1

   The match criteria allows for definition of packet headers and
   metadata, all of which must be true for the match to occur.

nit: Is this missing a word like "contents"?

   The matching of filters and actions in an ACE/ACL are triggered only
   after application/attachment of the ACL to an interface, VRF, vty/tty
   session, QoS policy, routing protocols amongst various other config
   attachment points.

nit: I think the end of this list needs some clarification/termination,
like "and routing protocols, amongst"

Section 3

  The
   match criteria allows for definition of packet headers or metadata,
   if supported by the vendor.  [...]

(same nit as above re "contents")

   Metadata matching applies to fields associated with the packet, but
   not in the packet header such as input interface, packet length, or
   source or destination prefix length.  The actions can be any sort of

nit: comma after "not in the packet header"

Section 4.1

nit: The feature match-on-udp and -icmp descriptions should probably use
the plural "headers" to match the other features' descriptions.

The mixed- features seem to implicitly assume that if features X and
Y are individually supported, then the combination is also supported.  I
could imagine that there might exist hardware for which that assumption is
not true, but don't know if there actually is any such hardware or it's
common enough to be worth caring about here.

   grouping acl-counters {
 leaf matched-packets {
  [...]
  An implementation should provide this counter on a
  per-interface per-ACL-entry if possible.

nit: missing "basis"?  (Also in subsequent instances.)

Section A.1

It's unclear that using a...@newco.com (in particular, the @newco.com part)
in an example is reasonable; @newco.example would be better.


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