> On Mar 15, 2024, at 19:13, Per Andersson (perander)
> wrote:
>
> Christian Hopps on Friday, March 15, 2024 20:10:
>>> On Mar 15, 2024, at 13:26, mohamed.boucad...@orange.com wrote:
>>>
>>> Re-,
>>> I’m not sure to agree with your last state
> On Mar 15, 2024, at 13:26, mohamed.boucad...@orange.com wrote:
>
> Re-,
> I’m not sure to agree with your last statement, Andy.
> The reality is that the OLD reco is inducing many cycles and waste of time
> for no obvious technical reason: see an example
>
Jürgen Schönwälder writes:
I wonder which problem we are solving with adding more little rules.
Perhaps a future version of YANG will do away with prefixes but until
this happens, I do not think we need to add more rules about how to
choose prefixes. The original intend was that they are
Jan Lindblad writes:
Med, author team,
Thank you for taking the time to get this work done, and well done!
This is one of those fundamental bricks that saves time and improves
quality for the entire YANG community.
I read the -09 version and like what I see. I have a couple of minor
Balázs Lengyel writes:
Hello Andy,
I assume you are referring to the sentence “A new module revision MAY
contain NBC changes” from the versioning draft.
IMHO the authors agree that NBC changes are bad. They should be
allowed but discouraged.
That's what "SHOULD NOT" means.
Would a
Speaking as someone who at one point worked for an operator trying to use YANG to actuall
configure a large network (services and devices), and also having interacted with the
openconfig folks over the years. I find your perspective, if I understand it, that being
too "loose" with things will
Nice. I think this a fine way forward with or without step 2. I say leave out
the 2 years (or any) deadline, and let people argue over how and when to do
step 2 for however long it takes.
Given the questions already raised on this thread, we should probably add
explicit guidance to
Randy Presuhn writes:
30+ years of tradition (and BCP) not permitting types to be changed
after they've been published, I suppose, motivated by our total lack
of control over unpublished usage of these types after their definitions
have been published.
If there were actually something wrong
Randy Presuhn writes:
Hi -
Let me get this straight. WG A standardized types X and Y years ago,
and support for these has presumably been implemented in some number
of tools, which in turn have been used to develop some unknowable
number of products, whose deployment is even more
ge blast radius (not saying
it's wrong), and perhaps most importantly is also outside of LSR WG control. :)
Thanks,
Chris.
[wg-member]
> Thanks,
> Acee
>
> On 4/5/22, 9:33 AM, "Christian Hopps" wrote:
>
>If they are new leaf values why not use the correct n
If they are new leaf values why not use the correct no-zone variant, what's the
harm in doing it right? It has a nice side effect of basically restricting the
base spec zone values to no-zone only. :)
Thanks,
Chris.
[wg member]
> On Apr 4, 2022, at 12:30, Acee Lindem (acee)
> wrote:
>
> In
> On Jan 4, 2022, at 6:26 AM, Jürgen Schönwälder
> wrote:
>
> On Tue, Jan 04, 2022 at 11:01:16AM +, tom petch wrote:
>>
>> Well, consistency with what? For me that is the protocol RFC that is the
>> starting point and having YANG module authors going off in another
>> direction, albeit
> On Dec 18, 2021, at 11:33 AM, Andy Bierman wrote:
>
> Thank you for caring about backward compatibility and stability.
>
I guess I left as implicit in my question of whether we could do something to
fix it, that that "could" implied a fix wouldn't break things. I certainly care
about
> On Dec 18, 2021, at 7:59 AM, Carsten Bormann wrote:
>
> On 2021-12-18, at 09:20, Eliot Lear wrote:
>>
>> Still it seems like the right thing to do, in order to fall into line with
>> the target language spec.
>
> But that’s not what YANG was designed for.
> YANG is a data modeling
> On Jul 17, 2021, at 6:14 PM, Benjamin Kaduk wrote:
>
> 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
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
> draf
Lars Eggert via Datatracker writes:
Lars Eggert has entered the following ballot position for
draft-ietf-netmod-geo-location-10: Abstain
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
Francesca Palombini writes:
Hi Chris,
Inline.
I've posted a new version with the updated IANA registry changes.
https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/10/
Thanks,
Chris.
Thanks,
Francesca
On 27/05/2021, 00:04, "Christian Hopps" wrote:
I didn’t think you were actually looking for a non-xml solution, but as you
mentioned in an earlier mail there’s my org-rfc setup which makes all this yang
stuff pretty simple. The source of the YANG module is in the single org-mode
formatted draft source, along with support for YANG validation
Sorry missed a couple in previous reply.
Christian Hopps writes:
Benjamin Kaduk via Datatracker writes:
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.
Yes, there was even a
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
Francesca Palombini via Datatracker writes:
Francesca Palombini 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
Roman Danyliw via Datatracker writes:
--
DISCUSS:
--
** Section 3. leaf astronomical-body. The content of this field appears to be
"An astronomical body as
Martin Duke via Datatracker writes:
--
COMMENT:
--
(2.2) "For the standard location choice latitude and longitude are specified as
fractions of decimal
John Scudder via Datatracker writes:
Nits:
I think this document has the fewest nits per page of any document I’ve ever
reviewed (kudos!), but there are still a few.
I believe I have benefited by being an early tester for Rob Wilton's automated
grammar checker. :)
I've fixed the
Murray Kucherawy via Datatracker writes:
I support Lars' and Francesca's DISCUSS positions.
The shepherd writeup says: "There are no known implementations known to the
Shepherd. No vendors have indicated their plan to implement the specification.
It was originally forwarded to support DT's
Erik Kline via Datatracker writes:
--
COMMENT:
--
[[ questions ]]
[ section 2.1 ]
* Is WGS-84 still the default for geodetic-datum when
Well you were right, ipv4-address is used all over the place and it probably
shouldn't have been. Chalk another one up to sticking to the rules even when it
harms us.
Thanks,
Chris.
Ladislav Lhotka writes:
On 09. 05. 21 1:26, Christian Hopps wrote:
How did we end up with "ipv4-ad
How did we end up with "ipv4-address" being a zoned IPv4 address and having to use the
non-obvious "ipv4-address-no-zone" type to get the IPv4 address type used by everyone,
everywhere?
I see that OpenConfig chose the opposite meaning for the "obvious" names (i.e., you want zoned
addresses
Linda Dunbar via Datatracker writes:
Summary:
This draft describes the Geo-location object for YANG. The document is written
very clear. I don't see any problem., except for one question:
The "pattern ’[ -@\[-\^_-~]*’" is used by leaf astronomical-body and container
geodetic-system. Why not
> On Apr 19, 2021, at 4:14 PM, Erik Kline wrote:
>
>
>
> Are the vector components expected to be accessed by name in applications, or
> is it possible some applications might have to handle a 3-tuple of doubles?
By name only.
Thanks,
Chris.
>
> I only ask this super-nitty question
Just posted this new version.
> On Apr 13, 2021, at 6:08 AM, Rob Wilton (rwilton) wrote:
>
> Hi Chris,
>
>> -Original Message-
>> From: Christian Hopps mailto:cho...@chopps.org>>
>> Sent: 13 April 2021 03:38
>> To: Rob Wilton (rwilton) mailto:
> On Mar 7, 2021, at 3:48 PM, Rob Wilton (rwilton) wrote:
>
> Hi Chris,
>
> Apologies for the delayed AD review of this document.
>
> I found that this document to be interesting, enlightening, and well written,
> so thank you.
>
>
> I only have a few minor comments, the rest are
You did, and I missed that change. I've updated and posted a new version.
Thanks,
Chris.
> On Dec 3, 2020, at 5:02 AM, tom petch wrote:
>
> From: netmod on behalf of Christian Hopps
>
> Sent: 02 December 2020 11:31
>
> This update addresses a few remaining nits i
etwork Modeling WG of the IETF.
>
>Title : A YANG Grouping for Geographic Locations
>Author : Christian Hopps
> Filename: draft-ietf-netmod-geo-location-06.txt
> Pages : 25
> Date: 2020-12-02
>
ernet-dra...@ietf.org wrote:
>
>
> 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 : A YANG Grouping for Geographic Locations
> Author :
-05?
> Type in my opinion is more reusable building block.
>
> -Qin
> 发件人: Christian Hopps [mailto:cho...@chopps.org <mailto:cho...@chopps.org>]
> 发送时间: 2020年7月31日 0:38
> 收件人: Juergen Schoenwaelder <mailto:j.schoenwael...@jacobs-university.de>>
> 抄送: Chri
I received specific external feedback from the geo experts to just use a number
instead of a type. I think they may have been thinking that it would be easier
to redefine the values meaning for different systems.
Thanks,
Chris.
> On Jul 30, 2020, at 12:23 PM, Juergen Schoenwaelder
> wrote:
>
> On Jul 7, 2020, at 8:30 AM, Juergen Schoenwaelder
> wrote:
>
> On Tue, Jul 07, 2020 at 08:27:19AM -0400, Christian Hopps wrote:
>>
>> Mentioned in the earlier mail
>>
>> instead of
>>
>>"decimal64"
> On Jul 7, 2020, at 8:18 AM, Juergen Schoenwaelder
> wrote:
>
> On Tue, Jul 07, 2020 at 07:53:19AM -0400, Christian Hopps wrote:
>>
>> So do you think it's enough to just use decimal64, and not justify it's use
>> over strings?
>
> I do not know
you probably wouldn't
want to be using XML or JSON).
Thanks,
Chris.
>
> /js
>
> On Tue, Jul 07, 2020 at 07:06:20AM -0400, Christian Hopps wrote:
>> I received feedback in my YANG doctor review (thanks Mahesh) regarding the
>> use of decimal64 for most of the values in
I received feedback in my YANG doctor review (thanks Mahesh) regarding the use
of decimal64 for most of the values in the geo location grouping
(https://tools.ietf.org/html/draft-ietf-netmod-geo-location-04). In my
comparison sections I note that some precision (at the very extremes) may be
An action is defined as being something bound to a node. Talking about actions
that aren't bound to a node is talking about RPCs AFAICT. In the server it just
comes down to passing the bound node data in to the function or not. Defining
"unbound actions" to replace RPCs is just different syntax
> On Mar 28, 2020, at 8:36 AM, tom petch wrote:
>
>> A wholesale lack of YANG reference clauses; perhaps half a dozen needed
> I can see 2 places I might could put these, in the "astronomical-body" leaf
> that references the IAU and in the "geodetic-system" for the default value.
> We are
> On Mar 27, 2020, at 1:09 PM, tom petch wrote:
>
> Kent
>
> Not Ready
>
> I thought that so obvious that it was not worth saying:-)
>
> e.g.
> IANA considerations does not register the namespace so there is no module
Will add.
> Security Considerations does not use template (which other
> On Mar 26, 2020, at 2:46 PM, Kent Watsen wrote:
>
> Dear All,
>
> This WGLC has received zero responses, which is insufficient to progress the
> document at this time. The WGLC is therefore being extended for another
> week, now ending April 1st (the day before our Virtual Meeting on
Kent Watsen writes:
Authors, Contributors, WG,
As part of the WGLC, are you aware of any IPR that applies to
draft-ietf-netmod-geo-location?
"No, I'm not aware of any IPR that applies to this draft"
Thanks,
Chris.
signature.asc
Description: PGP signature
Hi netmod,
I pointed our external/expert reviewers to the new version (-02 at the time,
-03 are editorial changes), and received a positive response that things looked
good. I believe that was all we were waiting for before a WGLC..
Thanks,
Chris.
> On Feb 17, 2020, at 4:42 PM, Randy Presuhn
> wrote:
>
> Hi -
>
> On 2/17/2020 11:47 AM, Christian Hopps wrote:
>>> On Feb 17, 2020, at 11:51 AM, Randy Presuhn
>>> wrote: Hi - On 2/17/2020 3:15 AM,
>>> Christian Hopps wrote: ...
>>&g
> On Feb 17, 2020, at 12:09 PM, Schönwälder, Jürgen
> wrote:
>
> IANA assigned
> +tags must conform to Net-Unicode as defined in RFC 5198 and they shall
> +not need normalization.
Seems good to me. Changed locally.
Thanks,
Chris.
___
netmod
> On Feb 17, 2020, at 11:51 AM, Randy Presuhn
> wrote:
>
> Hi -
>
> On 2/17/2020 3:15 AM, Christian Hopps wrote:
> ...
> > BTW, I did look at the "SHOULD be avoided" (occurs twice that I saw) once
> > dealing with LFs and CRs which l
exey Melnikov ; netmod@ietf.org; Joel
>> Jaeggli ; Christian Hopps ; The IESG
>>
>> Subject: Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-
>> module-tags-07: (with DISCUSS)
>>
>> Rob,
>>
>> I think there are two related issues here:
>>
> On Feb 14, 2020, at 1:05 PM, Randy Presuhn
> wrote:
>
> Hi -
>
> On 2/14/2020 3:21 AM, Christian Hopps wrote:
>> How about I add this to the description of "typedef tag" in the module:
>>
>>description
>> "A ta
ut a registered prefix
- SHOULD NOT be treated as invalid.";
+ SHOULD NOT be treated as invalid. For the purposes of comparison
+ non-ascii strings should use 'NFC' (RFC5198) normalization";
}
Thanks,
Chris.
> On Feb 14, 2020, at 6:06 AM, Christian Hopps
For the record this one is 3 years and counting. For a list of tags.
> On Feb 14, 2020, at 6:01 AM, Christian Hopps wrote:
>
> I was not approaching this discuss with this level of change in mind. How
> many years does it take to get a YANG model even one as simple as this
ion method that SHOULD be used? Or is
> the onus on the client to use sensible (i.e. already normalized) values, and
> if so, does that need to be stated?
>
> Thanks,
> Rob
>
>
>> -Original Message-
>> From: iesg On Behalf Of Alexey Melnikov
>> S
> On Feb 13, 2020, at 8:10 AM, Alexey Melnikov wrote:
>
> Hi Christian,
>
> On Thu, Feb 13, 2020, at 12:30 AM, Christian Hopps wrote:
>> The intent in the document is to place as few restrictions on tags as
>> possible to allow for future-proofing and organic gr
The intent in the document is to place as few restrictions on tags as possible
to allow for future-proofing and organic growth of use both within and outside
of SDOs. For standard tags we trust IANA (and the human behind the process) to
make the call on whether a tag is already present. :)
wrote:
>
>
>
>> On Jan 22, 2020, at 6:40 AM, Christian Hopps wrote:
>>
>>
>> I've just submitted a YANG module draft and received what i think to be a
>> bogus validation error:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-yang-isis-reverse-metr
I've just submitted a YANG module draft and received what i think to be a bogus
validation error:
https://datatracker.ietf.org/doc/draft-ietf-lsr-yang-isis-reverse-metric/
It's saying it can't find the ietf-isis module. Has anyone else experienced
this issue with referencing draft modules?
> On Oct 4, 2019, at 4:17 AM, Rob Wilton (rwilton) wrote:
>
> Hi Chris, Mahesh,
>
>> -Original Message-
>> From: Christian Hopps
>> Sent: 03 October 2019 20:50
>> To: Mahesh Jethanandani
>> Cc: Christian Hopps ; Rob Wilton (rwilton)
&g
;> updated on a device equivalently to module tags.
>>
>> I'm currently thinking that the second choice might be a better approach at
>> this time, but wanted to check whether you or the WG had an opinion.
>>
>> Thanks,
>> Rob
>>
>>
>>
>
> On Oct 3, 2019, at 11:30 AM, Rob Wilton (rwilton) wrote:
>
> Hi Chris,
>
>> -Original Message-
>> From: Christian Hopps
>> Sent: 03 October 2019 16:16
>> To: Rob Wilton (rwilton)
>> Cc: Christian Hopps ; netmod@ietf.org
>> Subject: R
dule in the non-NMDA case.
Thanks,
Chris.
>
> Thanks,
> Rob
>
>> -Original Message-
>> From: netmod On Behalf Of Christian Hopps
>> Sent: 25 September 2019 17:19
>> To: netmod@ietf.org
>> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-mod
ing WG of the IETF.
>
>Title : YANG Module Tags
>Authors : Christian Hopps
> Lou Berger
> Dean Bogdanovic
> Filename: draft-ietf-netmod-module-tags-09.txt
> Pages :
Or just let it proceed as NMDA only.
Thanks,
Chris.
> On Jul 27, 2019, at 5:54 PM, Joel Jaeggli wrote:
>
> Folks Ignas,
>
> draft-ietf-netmod-module-tags, currently in IESG review is in need of a
> a fairly significant edit, notably the addition of an appendix covering
> the nmda state. It
> On Jun 25, 2019, at 3:58 AM, Martin Bjorklund wrote:
>
> Ladislav Lhotka wrote:
>> Kent Watsen writes:
>>
>>> Hi Michal,
I agree, but these valid data were correctly printed into invalid
data. I do not think printing is allowed to change the validity of
data.
>>> The
The intention was for a location node to be required if the
container was present. Apparently this will only work if "container
geo-lcoation" is a presence container. I'm not even sure that's all that smart
of a requirement (e.g., maybe someone just wants to indicate the
reference-frame for
> On May 3, 2019, at 8:08 AM, tom petch wrote:
>
> - Original Message -
> From: "Mikael Abrahamsson"
> To: "Randy Presuhn"
> Cc:
> Sent: Thursday, May 02, 2019 12:35 PM
>
>> On Wed, 1 May 2019, Randy Presuhn wrote:
>>
>>> Hi -
>>>
>>> On 5/1/2019 12:46 PM, Mikael Abrahamsson
> On Apr 11, 2019, at 9:30 AM, Alvaro Retana via Datatracker
> wrote:
>
> Alvaro Retana has entered the following ballot position for
> draft-ietf-netmod-module-tags-07: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the
> On Apr 11, 2019, at 9:49 AM, Benjamin Kaduk via Datatracker
> wrote:
>
> --
> DISCUSS:
> --
>
> I think this document does introduce new security
and-prefix-length still specifies an IP address if you remove the
> prefix length.
>
> Alex
>
> ________
> From: netmod on behalf of Christian Hopps
>
> Sent: Wednesday, 3 April 2019 7:52 a.m.
> To: Martin Bjorklund
> Cc: netmod@ietf.
> On Apr 2, 2019, at 2:27 PM, Martin Bjorklund wrote:
>
> "Rob Wilton (rwilton)" wrote:
>> Hi Acee,
>>
>> Having re-read the thread, I think that "ip-address-prefix" is going
>> to be confusing, since I had incorrectly assumed that the type being
>> defined was an IP prefix, but as you have
> On Apr 1, 2019, at 1:29 PM, Martin Bjorklund wrote:
>
> Hi,
>
> The request was for a combined type that contains both an ip address
> *and* a prefix length in one value. Hence the name
> "ip-address-and-prefix-length" :)
>
> I know that this type is convenient, esp. if you use it for
I will move this reference to normative, I was confused.
Thanks,
Chris.
Benjamin Kaduk writes:
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, 2
).
..."
I've been waiting to publish corrections until after the GenART review is done.
Thanks,
Chris.
With Regards,
Rohit
-Original Message-
From: Rohit R Ranade
Sent: 21 February 2019 14:14
To: 'Christian Hopps'
Cc: Joel Jaeggli ; ibagd...@gmail.com;
netmod-cha...@ietf.org
es themselves are normative only in the sense
that they are being reserved. Again, maybe I’m wrong. I’d prefer to be told so
and then I’ll just move the reference.
I guess I don’t understand things well enough is all. Can you be specific about
the objections with each of the 3 references?
Thanks,
Chris.
regarded as valid prefixes.
> https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
> <https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml>
> On Thu, 7 Mar 2019 at 18:28, Andy Bierman <mailto:a...@yumaworks.com>> wrote:
>
>
&g
Christian Hopps wrote:
Thanks for the review! Comments inline.
> On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies <
ietf-secretariat-re...@ietf.org> wrote:
>
> Reviewer: Elwyn Davies
> Review result: Almost Ready
>
> If I read correctly, the YANG def
Andy Bierman writes:
I strongly agree that a prefix SHOULD be present, not MUST be present.
I also think the 3 standard prefixes will be insufficient over time.
(Having every organization on the planet except IETF share the prefix
"vendor:"
seems a bit short-sighted)
Sounds like you are a
Thanks for the review! Comments inline.
> On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies
> wrote:
>
> Reviewer: Elwyn Davies
> Review result: Almost Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF
William Lupton writes:
On Tue, 5 Mar 2019 at 14:05, Martin Bjorklund wrote:
Christian Hopps wrote:
>
> William Lupton writes:
>
> >> The intent was "ascii-printable". Would be nice if there was an easier
> > way to specify this. :)
> >
>
ll work too (its the range between the UTF code points, which in this case are the ascii
values), but then that reference is also where i got the "#x22" hex format from that
Martin said was invalid. :)
Thanks,
Chris.
On Mon, 4 Mar 2019 at 20:20, Christian Hopps wrote:
Marti
Check it out: https://github.com/choppsv1/org-rfc-export
If you are an Emacs user, especially one who is familiar with/uses Org Mode, I
think you'll like this.
I've been working on an org mode exporter for writing RFCs. As it's now in
MELPA (package: ox-rfc) I figured it was a good time to
Martin Bjorklund writes:
Hi,
Just some quick comments on the YANG:
However, it seems libxml2's regexp engine requires both "[" and "^" to
be escaped:
'[-0-9a-z "#\[\]' +
'!$%&()*+,./:;<=>?@\\\^_`{|}~]+';
This expression isn't wrong, but it seems to me that these characters
: YANG Geo Location
Author : Christian Hopps
Filename: draft-chopps-netmod-geo-location-01.txt
Pages : 22
Date: 2019-03-02
Abstract:
This document defines a generic geographical location object YANG
grouping
tributes of location they are
describing something else. Orientation, etc, are covered with KML though.
Thanks,
Chris.
Kent // contributor
On Feb 27, 2019, at 9:39 PM, Christian Hopps wrote:
FYI.
Begin forwarded message:
From: internet-dra...@ietf.org <mailto:internet-dra...@ietf.o
om the on-line Internet-Drafts
> directories.
>
>
>Title : YANG Geo Location
>Author : Christian Hopps
> Filename: draft-chopps-netmod-geo-location-00.txt
> Pages : 17
> Date: 2019-02
the values that designers, implementers and
users may can use. As a result of this choice, designers, implementers and
users are free to add any structure they may find useful to their own tag
values.
Thanks,
Chris.
Christian Hopps writes:
The document does *not* create ways for specif
The document does *not* create ways for specifying names for objects. Its a way
to associate meta-data with an implemented yang module. Even says this right at
the start of the abstract.
The body of the document does *not* fail to specify the syntax. As you even
quoted:
All
e document development
time, it's not an appropriate change to consider at this very late stage in the
process.
Thanks,
Chris.
>
> With Regards,
> Rohit
>
> -Original Message-
> From: Christian Hopps [mailto:cho...@chopps.org]
> Sent: 18 February 2019 14:57
> To: Rohit
to how I
will use these tags. On the whole, I like the idea and thank you and the
co-authors for documenting this.
Thanks!
Chris.
With Regards,
Rohit R
-Original Message-
From: Christian Hopps [mailto:cho...@chopps.org]
Sent: 16 February 2019 00:27
To: Rohit R Ranade
Cc: Christian Hopps ; Jo
Hi Robert,
I've adopted all your suggestion.
Thanks for the review!
Chris.
> On Feb 13, 2019, at 7:04 AM, Robert Wilton wrote:
>
> Reviewer: Robert Wilton
> Review result: Ready with Nits
>
> I have reviewed this document as part of the YANG doctors directorate's
> ongoing effort to review
> On Feb 13, 2019, at 6:04 AM, Rohit R Ranade wrote:
>
> Editorial Comments:
> 1. Section 1, refers to RFC6020 for Yang Module, but since this document
> uses Yang Version 1.1, I feel it should refer to RFC7950
> 2. Section 4.3, " removed with using normal configuration", can use "removed
tf:standard-defined (or sdo-defined?)
If we make these changes, we have to revise the current
"ietf:network-service". Maybe "ietf:network-service-protocol".
/martin
Christian Hopps wrote:
Juergen Schoenwaelder writes:
> On Wed, Feb 13, 2019 at 08:37:59AM -0500, Christ
Juergen Schoenwaelder writes:
On Wed, Feb 13, 2019 at 08:37:59AM -0500, Christian Hopps wrote:
Juergen Schoenwaelder writes:
But, ietf:element is too generic to assign the meaning "RFC8199 module classification of element" which is
what "rfc8199-element" is suppos
Juergen Schoenwaelder writes:
> The 'rfc8199-' part in some of the tags does look to me like an
> attempt to scope 'service', 'element' etc. If this is being used, you
> will see that labels will use ad-hoc forms of scoping. The networking
> vocabulary is small and reuse of terms with
Juergen Schoenwaelder writes:
On Wed, Feb 13, 2019 at 04:00:01AM -0500, Christian Hopps wrote:
In any case this is general purpose meta-data after all, while some data may be
immediately recognizable (e.g., ietf:routing) other data may require looking at
a specification to determine it's
Juergen Schoenwaelder writes:
On Tue, Feb 12, 2019 at 03:50:08PM -0800, Joel Jaeggli wrote:
Joel Jaeggli has requested publication of draft-ietf-netmod-module-tags-04 as
Proposed Standard on behalf of the NETMOD working group.
Please verify the document's state at
So I would now have a new tags server to store tags associated with the modules
for each of my actual servers in my network?
This seems a bit convoluted to me, and I haven’t heard anyone say what the
problem is with the servers storing the tags associated with their modules,
there are obvious
1 - 100 of 161 matches
Mail list logo
