Re: [netmod] Éric Vyncke's No Objection on draft-ietf-netmod-yang-instance-file-format-19: (with COMMENT)

[Eric Vyncke (evyncke)]

Hello Balázs,

Thank you for your quick reply and your actions. My comments are non-blocking 
anyway ;-) see my replies prefixed with EV>

Regards

-éric

On 05/10/2021, 18:10, "iesg on behalf of Balázs Lengyel" 
 wrote:

Hello Eric,
Thank you for the thorough review. I used many of your comments to improve 
the draft. See my detailed answers below as BALAZS:
Regards Balazs

-Original Message-
From: Éric Vyncke via Datatracker  
Sent: 2021. október 5., kedd 13:27
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: Éric Vyncke's No Objection on 
draft-ietf-netmod-yang-instance-file-format-19: (with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-netmod-yang-instance-file-format-19: 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:
--

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be 
appreciated even if only for my own education), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Generic comment about the use of the word "file" (which means an object in 
a file system for me) rather than something more generic (no suggestion to offer
though) ?
BALAZS: In most cases we do actually mean an object in a file system. 
In some cases not: In UC6 Allowing YANG instance data to be carried within  
other IPC message formats. 
This is the exact reason while we differentiate between an 
instance-data-set and an instance-data-file. 
An instance-data-set may be contained in a file, but may be transferred in 
a protocol message.

EV> indeed, so, should the title be updated s/file/data set/ ?

-- Section 1 --
The first 2 sentences are quite repetitive.
BALAZS: The first sentence states that we need such data off-lie
The second sentence states that this offline data may be needed in 3 
different phases design, implementation or even later after the server and the 
YANG module is up and running, I just don't have access to it.
Reworded to clarify this.

EV> thanks

Is it about "offline delivery" or "exchange" ? At this point of reading the 
document, it is still unclear in my mind what it is about... The rest of the 
I-D made it clear.
BALAZS: The draft is only about defining a format for YANG instance data. 
Naturally once you have a data format it could be used both to deliver the 
information offline in a file or to exchange information using the format in an 
protocol message.
Most use-cases mentioned are about Offline delivery.
.

Unclear which UC is either implemented or potential (even with the 
appendix); could also add forward references to the appendix UC). Should the
implementation(s) be referenced if they are public ?
BALAZS:  As stated in section 1. Use cases are listed only as examples. 
This draft is only about defining a format for YANG Instance Data.
I know UC1,2,3 are already implemented by more than one company, but as 
this draft is only about the format, I don't think we should reference the 
implementations. 
Also, UC1 is already utilized in 2 other internet drafts.

EV> nice to know, next time, you may want to have an 'implementation status' 
section (to be removed by the RFC editor).

-- Section 1.1 --
Unsure why a "data set" should be named? The choice of words does not seem 
the best fit (even though if I have no suggestions).
BALAZS: Specific data sets need to be identified. What is it about? When 
was it prepared? 
EV> correct but it is also in the meta-data part (if not mistaken)
 I want a way to identify the specific data set. So, we give it a name (and 
a revision/timestamp).  This is why its named.
Any better suggestion?

-- Section 2 --
Like some other ADs, I wonder why "The context data part MUST... except" is 
not a "SHOULD" as there are exceptions.

What is the expected behaviour when the timestamp in the filename does not 
match the meta data ?
BALAZS: We are following RFC7950 in which YANG related file names are 
recommended with a SHOULD but not prescribed with a MUST.
Some people wanted to use separate timestamps when the 

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

[Roman Danyliw via Datatracker]

Roman Danyliw 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:
--

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

A syntax for an instance data file name is specified with normative language. 
However, this format is not explained is cited.

** Section 2. Editorial.
OLD
If the leaf "name" is present in the instance data header, its value
   SHOULD be used for the "instance-data-set-name"

NEW
If the leaf "name" is present in the instance data header, its value
   SHOULD be used for the "instance-data-set-name" in the filename.

** Section 2.

Description of the instance data set.  The description SHOULD
 contain information whether and how the data can change during
 the lifetime of the server

I found this definition of the description confusing as Figure 1 – 3 don’t seem
to describe “whether and how the data” will change.

** Section 2.1.1.  Per “The inline-yang-library anydata data node carries
instance data (conforming to ietf-yang-library@2019-01-04)”, please provide a
reference to “ietf-yang-library@2019-01-04”.

** Section 4.  Please note the risk of using same-schema-as-file, especially if
these configs are not integrity protected or received from outside sources. 
Per https://, there are the risks of loading remote content.  Section 7 of
RFC3986 is a good reference.  Per file://, there are things list directory
traversal.

** Section 4.  Per “The header part is not security sensitive with one possible
exception … the URI method”, I’m not sure that such a strong statement can be
made given the lack of application context.  For example, the description leaf
in the header could include sensitive information, say ‘Latest test router
config for new super secret Aqua-Violet flying car project’.  This text needs
to either have a caution that that this header is "unprotected so do not put in
sensitive information unless this file is protected", or clarify that more in
the header than the URI could be sensitive.

** Section 4.  Thanks for the language trying to create equivalency between the
protections of the file and the YANG store that would house it on a live
system.  Recommend making this text clear to say this applies to both at rest
and in motion data.

OLD
The same kind of handling should be applied, that would be
   needed for the result of a read operation returning the same data.

NEW (roughly)
The same kind of handling should be applied to this file at rest and in transit
that would be needed for the result of a read operation returning the same
data.  These in-transit protection mechanisms will also mitigate integrity
issues when transporting the file.



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

[netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-20.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : YANG Instance Data File Format
Authors : Balazs Lengyel
  Benoit Claise
Filename: draft-ietf-netmod-yang-instance-file-format-20.txt
Pages   : 28
Date: 2021-10-05

Abstract:
   There is a need to document data defined in YANG models at design
   time, implementation time or when a live server is unavailable.  This
   document specifies a standard file format for YANG instance data,
   which follows the syntax and semantics of existing YANG models, and
   annotates it with metadata.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format-20

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-20


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

[netmod] Reply to Lars Eggert's comments on draft-ietf-netmod-yang-instance-file-format-19

[Balázs Lengyel]

Hello,
This is our reply to Lar's Eggert's comments. The original comments can be 
read at 
https://datatracker.ietf.org/iesg/agenda/documents/#draft-ietf-netmod-yang-instance-file-format_lars-eggert.
Thanks for the review. I used most of your suggestions to improve the draft.
See detailed replies as "BALAZS:" below.
Regards Balazs

=
All comments below are about very minor potential issues that you may choose 
to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3.2. , paragraph 4, nit:
> ance data; the instance data itself is is contained only in the 
> 'content-data
> ^
Possible typo: you repeated a word.
BALAZS: Will be corrected.

Section 3.2. , paragraph 5, nit:
> ove if the module gets changed // in anyway during reviews or RFC editor 
> proc
>   ^
Did you mean "in any way"?
BALAZS: Yes, will be corrected.

Section 3.2. , paragraph 19, nit:
>  data file needs to be handled in a secure way as mentioned below. The secur
>^^^
Consider replacing this phrase with the adverb "securely" to avoid wordiness.
BALAZS: Will be corrected.

Section 5.2. , paragraph 1, nit:
>  v08 - v09 * Removed reference to similar to get reply * Introduced artwork
>^
Typo. Did you mean "too similar to"?
BALAZS: Earlier the format was described as similar to the response of aNETCONF 
get operation. Updated it to make it more understandable.

These URLs in the document did not return content:
 * https://datatracker.ietf.org/wg/netmodf/






smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Éric Vyncke's No Objection on draft-ietf-netmod-yang-instance-file-format-19: (with COMMENT)

[Balázs Lengyel]

Hello Eric,
Thank you for the thorough review. I used many of your comments to improve the 
draft. See my detailed answers below as BALAZS:
Regards Balazs

-Original Message-
From: Éric Vyncke via Datatracker  
Sent: 2021. október 5., kedd 13:27
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: Éric Vyncke's No Objection on 
draft-ietf-netmod-yang-instance-file-format-19: (with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-netmod-yang-instance-file-format-19: 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:
--

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be 
appreciated even if only for my own education), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Generic comment about the use of the word "file" (which means an object in a 
file system for me) rather than something more generic (no suggestion to offer
though) ?
BALAZS: In most cases we do actually mean an object in a file system. 
In some cases not: In UC6 Allowing YANG instance data to be carried within  
other IPC message formats. 
This is the exact reason while we differentiate between an instance-data-set 
and an instance-data-file. 
An instance-data-set may be contained in a file, but may be transferred in a 
protocol message.

-- Section 1 --
The first 2 sentences are quite repetitive.
BALAZS: The first sentence states that we need such data off-lie
The second sentence states that this offline data may be needed in 3 different 
phases design, implementation or even later after the server and the YANG 
module is up and running, I just don't have access to it.
Reworded to clarify this.

Is it about "offline delivery" or "exchange" ? At this point of reading the 
document, it is still unclear in my mind what it is about... The rest of the 
I-D made it clear.
BALAZS: The draft is only about defining a format for YANG instance data. 
Naturally once you have a data format it could be used both to deliver the 
information offline in a file or to exchange information using the format in an 
protocol message.
Most use-cases mentioned are about Offline delivery.
.

Unclear which UC is either implemented or potential (even with the appendix); 
could also add forward references to the appendix UC). Should the
implementation(s) be referenced if they are public ?
BALAZS:  As stated in section 1. Use cases are listed only as examples. This 
draft is only about defining a format for YANG Instance Data.
I know UC1,2,3 are already implemented by more than one company, but as this 
draft is only about the format, I don't think we should reference the 
implementations. 
Also, UC1 is already utilized in 2 other internet drafts.

-- Section 1.1 --
Unsure why a "data set" should be named? The choice of words does not seem the 
best fit (even though if I have no suggestions).
BALAZS: Specific data sets need to be identified. What is it about? When was it 
prepared? 
 I want a way to identify the specific data set. So, we give it a name (and a 
revision/timestamp).  This is why its named.
Any better suggestion?

-- Section 2 --
Like some other ADs, I wonder why "The context data part MUST... except" is not 
a "SHOULD" as there are exceptions.

What is the expected behaviour when the timestamp in the filename does not 
match the meta data ?
BALAZS: We are following RFC7950 in which YANG related file names are 
recommended with a SHOULD but not prescribed with a MUST.
Some people wanted to use separate timestamps when the instance-data-set is 
created and when it is put into an instance-data-file.
This draft does not prescribe an expected behavior of the tools, it just 
defines the format.

-- Section 2.1 --
There is a "SHOULD" so when are exceptions/deviations acceptable ?
BALAZS: Based on your and Murray's comments, this will be changed to MUST.

The description of "simplified" is really too simple ;-)
BALAZS: Added  "only the module name and revision-date is used "

I would also appreciate that the order of the list matches the following 
sub-sections order.
BALAZS: OK, updated.

Thank you for using RFC 8792.

-- Section 4 --
Did the authors think about adding the party creating the file and adding an 
optional signature 

Re: [netmod] Network Modeling (netmod) WG Virtual Meeting: 2021-10-12

[Kent Watsen]

Folks,

Attached is a Calendar invite for next week’s virtual interim on System 
Configuration.

FWIW, the selected time slot scored the highest on the Doodle poll.   Everyone 
except one (Frank) could make it, with a couple being “if need be” (thank you!)

Slides have been prepared summarizing the on-list discussion to guide the 
discussion.   The slides primarily regard objectives, but necessarily consider 
solution options, pointing out those that are viable and why others aren’t.

Cheers!
Kent


BEGIN:VCALENDAR
CALSCALE:GREGORIAN
VERSION:2.0
X-WR-CALNAME:NETMOD Virtual Interim on System Configuration
METHOD:PUBLISH
PRODID:-//Apple Inc.//macOS 11.5.2//EN
BEGIN:VTIMEZONE
TZID:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
DTSTART:20070311T02
TZNAME:EDT
TZOFFSETTO:-0400
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
DTSTART:20071104T02
TZNAME:EST
TZOFFSETTO:-0500
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
TRANSP:OPAQUE
DTEND;TZID=America/New_York:20211012T12
UID:271A473F-BA2A-4674-BF25-9EE7763EEE68
DTSTAMP:20211005T151336Z
LOCATION:https://ietf.webex.com/ietf/j.php?MTID=mf0cca6ee36dd3c9cb9e78b2
 f47696534
SEQUENCE:1
CONFERENCE:https://ietf.webex.com/ietf/j.php?MTID=mf0cca6ee36dd3c9cb9e78
 b2f47696534
X-APPLE-TRAVEL-ADVISORY-BEHAVIOR:AUTOMATIC
SUMMARY:NETMOD Virtual Interim on System Configuration
LAST-MODIFIED:20211005T151336Z
CREATED:20211005T151237Z
DTSTART;TZID=America/New_York:20211012T10
BEGIN:VALARM
UID:6AFDA437-6560-444C-9462-F5F4B09D1FE9
X-APPLE-DEFAULT-ALARM:TRUE
TRIGGER:-PT30M
ACTION:AUDIO
ATTACH;VALUE=URI:Chord
X-WR-ALARMUID:6AFDA437-6560-444C-9462-F5F4B09D1FE9
END:VALARM
END:VEVENT
END:VCALENDAR



> On Oct 4, 2021, at 1:05 PM, IESG Secretary  wrote:
> 
> The Network Modeling (netmod) WG will hold
> a virtual interim meeting on 2021-10-12 from 10:00 to 12:00 America/New_York 
> (14:00 to 16:00 UTC).
> 
> Agenda:
> Slides will be presented to guide the discussion.
> 
> Information about remote participation:
> https://ietf.webex.com/ietf/j.php?MTID=mf0cca6ee36dd3c9cb9e78b2f47696534
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] [OPSAWG] Francesca Palombini's Discuss on draft-ietf-opsawg-l3sm-l3nm-16: (with DISCUSS and COMMENT)

[Rob Wilton (rwilton)]

Carsten & Med,

Thanks for raising this.  I agree with the errata, but this will need to be 
hold for doc update, because we cannot create a different revision of a YANG 
module through the errata process.

Thanks,
Rob


From: iesg  On Behalf Of Francesca Palombini
Sent: 05 October 2021 15:12
To: Carsten Bormann ; mohamed.boucad...@orange.com
Cc: draft-ietf-opsawg-l3sm-l...@ietf.org; ops...@ietf.org; 
opsawg-cha...@ietf.org; The IESG ; netmod@ietf.org
Subject: Re: [OPSAWG] Francesca Palombini's Discuss on 
draft-ietf-opsawg-l3sm-l3nm-16: (with DISCUSS and COMMENT)

Thanks Carsten for noticing this! I did overlook completely that bps was being 
used as bytes per seconds... Thanks Med for clarifying in this document and for 
opening errata https://www.rfc-editor.org/errata/eid6703 . The OPS ADs are on 
it, I am sure.

Francesca

From: Carsten Bormann mailto:c...@tzi.org>>
Date: Tuesday, 5 October 2021 at 09:05
To: mohamed.boucad...@orange.com 
mailto:mohamed.boucad...@orange.com>>
Cc: Francesca Palombini 
mailto:francesca.palomb...@ericsson.com>>, 
The IESG mailto:i...@ietf.org>>, 
draft-ietf-opsawg-l3sm-l...@ietf.org
 
mailto:draft-ietf-opsawg-l3sm-l...@ietf.org>>,
 opsawg-cha...@ietf.org 
mailto:opsawg-cha...@ietf.org>>, 
ops...@ietf.org 
mailto:ops...@ietf.org>>, 
netmod@ietf.org 
mailto:netmod@ietf.org>>
Subject: Re: [OPSAWG] Francesca Palombini's Discuss on 
draft-ietf-opsawg-l3sm-l3nm-16: (with DISCUSS and COMMENT)
Hi Med,

> I confirm that what I meant is "bits per second" to align with rfc8299#6.12.1.

Ah.

> I'm actually for more explicit units similar to what we are using in another 
> active spec:

As long as there is this confusion in YANG units, that is the only way that 
makes sense.
One little tweak I'd have for that spec:

> ==
>  enum bit-ps {
>value 2;
>description
>  "Bits per Second (bit/s).";
>  }
>  enum byte-ps {
>value 3;
>description
>  "Bytes per second (Byte/s).";

Maybe use the actual ISO/IEC 8 notation here: B/s.
(For those that don't know how ISO/IEC 8 allocates "B" for byte, the legend 
"Bytes per second" is unambiguous.)

>  }
> ==
>
> However, we are in a territory where we are trying to map as much to the 
> above service model and hence use the same labels for the units.
>
> FWIW, RFC8466 used to have the following:
>
> =
>  leaf pbs {
>type uint64;
>units "bps";
>description
>  "Peak Burst Size.  It is measured in bytes per
>   second.";
>  }
> =
>
> ...which is weird.

This is really errata land, as "bps" is used as the kitchen slang for "bit/s" 
in all other cases (along with "mbps" for Mbit/s, shudder).

> This is why we don't blindly inherit that draft-ietf-opsawg-l2nm and went for 
> the following:
>
>  leaf pbs {
>type uint64;
>units "bytes per second";
>description
>  "Peak Burst Size.";
>  }

I think this would also benefit from "Bytes per Second (B/s)".

Grüße, Carsten

>
> Cheers,
> Med
>
>> -Message d'origine-
>> De : Carsten Bormann mailto:c...@tzi.org>>
>> Envoyé : lundi 4 octobre 2021 17:50
>> À : BOUCADAIR Mohamed INNOV/NET 
>> mailto:mohamed.boucad...@orange.com>>
>> Cc : Francesca Palombini 
>> mailto:francesca.palomb...@ericsson.com>>; 
>> The IESG
>> mailto:i...@ietf.org>>; 
>> draft-ietf-opsawg-l3sm-l...@ietf.org;
>>  opsawg-
>> cha...@ietf.org; 
>> ops...@ietf.org; 
>> netmod@ietf.org
>> Objet : Re: [OPSAWG] Francesca Palombini's Discuss on draft-ietf-opsawg-
>> l3sm-l3nm-16: (with DISCUSS and COMMENT)
>>
>> On 2021-10-04, at 13:34, 
>> mohamed.boucad...@orange.com wrote:
>>>
>>> bytes per second (bps),
>>
>> Whoa.
>>
>> I know that the IETF doesn't usually care about precision in these things,
>> but "bps" is kitchen slang for "bit/s", so this is very confusing.
>>
>> (Given that we have done the work in RFC 8428 and 8798, I'd rather see
>> that we use it, instead of creating more confusion at each further step.
>> We do have ms and B/s in RFC 8798, because people using SenML asked for
>> that.)
>>
>> Grüße, Carsten
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a 

Re: [netmod] [OPSAWG] Francesca Palombini's Discuss on draft-ietf-opsawg-l3sm-l3nm-16: (with DISCUSS and COMMENT)

[Francesca Palombini]

Thanks Carsten for noticing this! I did overlook completely that bps was being 
used as bytes per seconds… Thanks Med for clarifying in this document and for 
opening errata https://www.rfc-editor.org/errata/eid6703 . The OPS ADs are on 
it, I am sure.

Francesca

From: Carsten Bormann 
Date: Tuesday, 5 October 2021 at 09:05
To: mohamed.boucad...@orange.com 
Cc: Francesca Palombini , The IESG 
, draft-ietf-opsawg-l3sm-l...@ietf.org 
, opsawg-cha...@ietf.org 
, ops...@ietf.org , netmod@ietf.org 

Subject: Re: [OPSAWG] Francesca Palombini's Discuss on 
draft-ietf-opsawg-l3sm-l3nm-16: (with DISCUSS and COMMENT)
Hi Med,

> I confirm that what I meant is "bits per second" to align with rfc8299#6.12.1.

Ah.

> I'm actually for more explicit units similar to what we are using in another 
> active spec:

As long as there is this confusion in YANG units, that is the only way that 
makes sense.
One little tweak I’d have for that spec:

> ==
>  enum bit-ps {
>value 2;
>description
>  "Bits per Second (bit/s).";
>  }
>  enum byte-ps {
>value 3;
>description
>  "Bytes per second (Byte/s).";

Maybe use the actual ISO/IEC 8 notation here: B/s.
(For those that don’t know how ISO/IEC 8 allocates “B” for byte, the legend 
“Bytes per second” is unambiguous.)

>  }
> ==
>
> However, we are in a territory where we are trying to map as much to the 
> above service model and hence use the same labels for the units.
>
> FWIW, RFC8466 used to have the following:
>
> =
>  leaf pbs {
>type uint64;
>units "bps";
>description
>  "Peak Burst Size.  It is measured in bytes per
>   second.";
>  }
> =
>
> ...which is weird.

This is really errata land, as “bps” is used as the kitchen slang for “bit/s” 
in all other cases (along with “mbps” for Mbit/s, shudder).

> This is why we don't blindly inherit that draft-ietf-opsawg-l2nm and went for 
> the following:
>
>  leaf pbs {
>type uint64;
>units "bytes per second";
>description
>  "Peak Burst Size.";
>  }

I think this would also benefit from “Bytes per Second (B/s)”.

Grüße, Carsten

>
> Cheers,
> Med
>
>> -Message d'origine-
>> De : Carsten Bormann 
>> Envoyé : lundi 4 octobre 2021 17:50
>> À : BOUCADAIR Mohamed INNOV/NET 
>> Cc : Francesca Palombini ; The IESG
>> ; draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg-
>> cha...@ietf.org; ops...@ietf.org; netmod@ietf.org
>> Objet : Re: [OPSAWG] Francesca Palombini's Discuss on draft-ietf-opsawg-
>> l3sm-l3nm-16: (with DISCUSS and COMMENT)
>>
>> On 2021-10-04, at 13:34, mohamed.boucad...@orange.com wrote:
>>>
>>> bytes per second (bps),
>>
>> Whoa.
>>
>> I know that the IETF doesn’t usually care about precision in these things,
>> but “bps” is kitchen slang for “bit/s”, so this is very confusing.
>>
>> (Given that we have done the work in RFC 8428 and 8798, I’d rather see
>> that we use it, instead of creating more confusion at each further step.
>> We do have ms and B/s in RFC 8798, because people using SenML asked for
>> that.)
>>
>> Grüße, Carsten
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Éric Vyncke's No Objection on draft-ietf-netmod-yang-instance-file-format-19: (with COMMENT)

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-netmod-yang-instance-file-format-19: 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:
--

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Generic comment about the use of the word "file" (which means an object in a
file system for me) rather than something more generic (no suggestion to offer
though) ?

-- Section 1 --
The first 2 sentences are quite repetitive.

Is it about "offline delivery" or "exchange" ? At this point of reading the
document, it is still unclear in my mind what it is about... The rest of the
I-D made it clear.

Unclear which UC is either implemented or potential (even with the appendix);
could also add forward references to the appendix UC). Should the
implementation(s) be referenced if they are public ?

-- Section 1.1 --
Unsure why a "data set" should be named? The choice of words does not seem the
best fit (even though if I have no suggestions).

-- Section 2 --
Like some other ADs, I wonder why "The context data part MUST... except" is not
a "SHOULD" as there are exceptions.

What is the expected behaviour when the timestamp in the filename does not
match the meta data ?

-- Section 2.1 --
There is a "SHOULD" so when are exceptions/deviations acceptable ?

The description of "simplified" is really too simple ;-)

I would also appreciate that the order of the list matches the following
sub-sections order.

Thank you for using RFC 8792.

-- Section 4 --
Did the authors think about adding the party creating the file and adding an
optional signature in the file itself?

== NITS ==

-- Section 1 --
The first 2 sentences are quite repetitive. Missing "." At the end of the 1st §

Why is "Factory Default Setting" capitalised ?

-- Section 1.2 --
Why using the future tense "shall be" rather than "are" ?

-- Section 2.1.1 and others --
Suggest to warn the reader that the examples are further in the text in a
different section.

-- Section 6 --
A "," is missing.



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

Re: [netmod] Murray Kucherawy's No Objection on draft-ietf-netmod-yang-instance-file-format-19: (with COMMENT)

[Benoit Claise]

Hi Murray,

On 10/4/2021 8:25 PM, Murray Kucherawy via Datatracker wrote:

Murray Kucherawy has entered the following ballot position for
draft-ietf-netmod-yang-instance-file-format-19: 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:
--

The shepherd writeup is incomplete with respect to the first question.

All of the SHOULDs in Section 2 leave me wondering under what conditions one
might legitimately deviate from what they are saying.  Since SHOULD offers a
choice, I recommend making this more clear.

The draft mentions some SHOULD related to the file name.
    Ex: The name of the instance data file SHOULD be of the form:
For those SHOULD, we followed the RFC 7950, 
https://datatracker.ietf.org/doc/html/rfc7950#section-5.2, which also 
used SHOULD


For this instance ...
To properly understand and use an instance data set, the user needs to 
know the content-schema. One of the following methods SHOULD be used:

... I don't recall why we have a SHOULD here. History I guess.
A MUST seems more appropriate and we propose to change to a MUST.

Regards, Benoit

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

Re: [netmod] [OPSAWG] Francesca Palombini's Discuss on draft-ietf-opsawg-l3sm-l3nm-16: (with DISCUSS and COMMENT)

[Carsten Bormann]

Hi Med,

> I confirm that what I meant is "bits per second" to align with rfc8299#6.12.1.

Ah.

> I'm actually for more explicit units similar to what we are using in another 
> active spec: 

As long as there is this confusion in YANG units, that is the only way that 
makes sense.
One little tweak I’d have for that spec:

> ==
>  enum bit-ps {
>value 2;
>description
>  "Bits per Second (bit/s).";
>  }
>  enum byte-ps {
>value 3;
>description
>  "Bytes per second (Byte/s).";

Maybe use the actual ISO/IEC 8 notation here: B/s.
(For those that don’t know how ISO/IEC 8 allocates “B” for byte, the legend 
“Bytes per second” is unambiguous.)

>  }
> ==
> 
> However, we are in a territory where we are trying to map as much to the 
> above service model and hence use the same labels for the units.
> 
> FWIW, RFC8466 used to have the following:
> 
> =
>  leaf pbs {
>type uint64;
>units "bps";
>description
>  "Peak Burst Size.  It is measured in bytes per
>   second.";
>  }
> =
> 
> ...which is weird.

This is really errata land, as “bps” is used as the kitchen slang for “bit/s” 
in all other cases (along with “mbps” for Mbit/s, shudder).

> This is why we don't blindly inherit that draft-ietf-opsawg-l2nm and went for 
> the following: 
> 
>  leaf pbs {
>type uint64;
>units "bytes per second";
>description
>  "Peak Burst Size.";
>  }

I think this would also benefit from “Bytes per Second (B/s)”.

Grüße, Carsten

> 
> Cheers,
> Med
> 
>> -Message d'origine-
>> De : Carsten Bormann 
>> Envoyé : lundi 4 octobre 2021 17:50
>> À : BOUCADAIR Mohamed INNOV/NET 
>> Cc : Francesca Palombini ; The IESG
>> ; draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg-
>> cha...@ietf.org; ops...@ietf.org; netmod@ietf.org
>> Objet : Re: [OPSAWG] Francesca Palombini's Discuss on draft-ietf-opsawg-
>> l3sm-l3nm-16: (with DISCUSS and COMMENT)
>> 
>> On 2021-10-04, at 13:34, mohamed.boucad...@orange.com wrote:
>>> 
>>> bytes per second (bps),
>> 
>> Whoa.
>> 
>> I know that the IETF doesn’t usually care about precision in these things,
>> but “bps” is kitchen slang for “bit/s”, so this is very confusing.
>> 
>> (Given that we have done the work in RFC 8428 and 8798, I’d rather see
>> that we use it, instead of creating more confusion at each further step.
>> We do have ms and B/s in RFC 8798, because people using SenML asked for
>> that.)
>> 
>> Grüße, Carsten
> 
> 
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> 

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

Re: [netmod] [OPSAWG] Francesca Palombini's Discuss on draft-ietf-opsawg-l3sm-l3nm-16: (with DISCUSS and COMMENT)

[mohamed.boucadair]

Hi Carsten,

I confirm that what I meant is "bits per second" to align with rfc8299#6.12.1.

I'm actually for more explicit units similar to what we are using in another 
active spec: 

==
  enum bit-ps {
value 2;
description
  "Bits per Second (bit/s).";
  }
  enum byte-ps {
value 3;
description
  "Bytes per second (Byte/s).";
  }
==

However, we are in a territory where we are trying to map as much to the above 
service model and hence use the same labels for the units.

FWIW, RFC8466 used to have the following:

=
  leaf pbs {
type uint64;
units "bps";
description
  "Peak Burst Size.  It is measured in bytes per
   second.";
  }
=

...which is weird. This is why we don't blindly inherit that 
draft-ietf-opsawg-l2nm and went for the following: 

  leaf pbs {
type uint64;
units "bytes per second";
description
  "Peak Burst Size.";
  }

Cheers,
Med

> -Message d'origine-
> De : Carsten Bormann 
> Envoyé : lundi 4 octobre 2021 17:50
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : Francesca Palombini ; The IESG
> ; draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg-
> cha...@ietf.org; ops...@ietf.org; netmod@ietf.org
> Objet : Re: [OPSAWG] Francesca Palombini's Discuss on draft-ietf-opsawg-
> l3sm-l3nm-16: (with DISCUSS and COMMENT)
> 
> On 2021-10-04, at 13:34, mohamed.boucad...@orange.com wrote:
> >
> > bytes per second (bps),
> 
> Whoa.
> 
> I know that the IETF doesn’t usually care about precision in these things,
> but “bps” is kitchen slang for “bit/s”, so this is very confusing.
> 
> (Given that we have done the work in RFC 8428 and 8798, I’d rather see
> that we use it, instead of creating more confusion at each further step.
> We do have ms and B/s in RFC 8798, because people using SenML asked for
> that.)
> 
> Grüße, Carsten


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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