Re: [netmod] On prefixes again RE: IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

[Christian Hopps]

> 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 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 
>>> herehttps://mailarchive.ietf.org/arch/msg/teas/eknpfAZIb9gX7GvUN1UoByCf5e4/
>>> Let’s save the authors time with a clear guidance:
>>>• Pick ietf- or iana- as a function of the module
>> 
>> I disagree with this guidance.
> 
> Can you explain your motivation?

Well first, what has been state earlier in the thread. But basically they add 
almost no value and gratuitously extend what is supposed to be a short 
identifier.

Thanks,
Chris.

> 
> 
> --
> Per


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

Re: [netmod] On prefixes again RE: IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

[Christian Hopps]

> 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 
> herehttps://mailarchive.ietf.org/arch/msg/teas/eknpfAZIb9gX7GvUN1UoByCf5e4/
>  Let’s save the authors time with a clear guidance:
> • Pick ietf- or iana- as a function of the module

I disagree with this guidance.

Thanks,
Chris.

> • Use something meaningful, but preferably not too long
>  Cheers,
> Med
>  De : Andy Bierman  
> Envoyé : vendredi 15 mars 2024 18:01
> À : Jürgen Schönwälder ; Andy Bierman 
> ; BOUCADAIR Mohamed INNOV/NET 
> ; netmod@ietf.org
> Objet : Re: [netmod] On prefixes again RE: IETF#119 I-D Status: 
> draft-ietf-netmod-rfc8407bis
>On Fri, Mar 15, 2024 at 9:42 AM Jürgen Schönwälder 
>  wrote:
> Yes, for long XPath expressions, one likes to have short prefixes, the
> shorter the better. In other contexts, such as type definitions, one
> may want to use longer prefixes providing more context. It seems you
> can't have both at the same time. Given this inherent conflict, I am
> not sure that generally pushing for longer prefixes is a good thing.
> 
> For modules with long XPath expressions, an author may consider to go
> for one character local prefixes even if they require to lookup their
> meaning in the imports (or people have modern editors that can
> dynamically show an expansion) because mutli-line XPath expressions
> with lots of repetitive substrings are pretty bad for human eyes.
>  Short is OK if the prefix is familiar to the reader. Like "if".
> What if the writer wanted a, b, c, d, etc? Shortt but not meaningful.
> It is a judgment call every time, too complex for a guideline.
>  The guideline only mentions short so the prefix will not conflict and the 
> import-stmt in
> other modules will not need a different prefix.  This is only for reader 
> familiarity, since the
> YANG compiler does not care which prefix is used.
>  The naming convention already established is that the SDO prefix (ietf or 
> iana) is not used.
> It would not help readers to change it now.
>/js
>  Andy
>  
> On Fri, Mar 15, 2024 at 08:22:03AM -0700, Andy Bierman wrote:
> > On Fri, Mar 15, 2024 at 7:24 AM Jürgen Schönwälder
> >  wrote:
> > 
> > > 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 short to keep
> > > YANG snippets concise and easy to read.
> > >
> > >
> > 
> > This is the IETF Coding Conventions document, not the YANG specification.
> > Naming conventions are CLRs but often with some benefits.
> > 
> > What problems?
> > 
> > 1) If there are multiple modules used in imports then the reader must be
> > able to
> > easily tell the prefixes apart.  If prefixes are too short and not
> > meaningful, this task
> > gets more difficult.  I find myself constantly going back to the imports to
> > make sure
> > I am matching the prefix to the correct module.
> > 
> > 2) If there are complex XPath expressions then prefixes that are too long
> > make the
> > expression unreadable, especially as it is chopped into "string" +
> > "string"  format
> > to fit into 72 character lines. If prefixes are too short then back to
> > problem (1).
> > 
> > 3)  It is becoming more common to have vendor modules import modules from
> > multiple SDOs.
> > Prefix naming conventions are already the BCP everywhere but the IETF.
> > 
> > Is it too late to start for IETF? There are many modules already with no
> > naming consistency,
> > so this would only affect new modules. There will never be consistent
> > naming of prefixes
> > so it may not be worth the change now.
> > 
> > 
> > 
> > /js
> > >
> > 
> > 
> 
> -- 
> Jürgen Schönwälder  Constructor University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> 
> 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 

Re: [netmod] On prefixes again RE: IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

[Christian Hopps]

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 short to keep
YANG snippets concise and easy to read.


Right.. I don't understand the need for uniqueness even, since one specifies a prefix 
when importing other modules. I'd definitely vote for not requiring standard prefix 
prefixes like "ietf-".

Thanks,
Chris


/js

On Fri, Mar 15, 2024 at 01:02:58PM +, mohamed.boucad...@orange.com wrote:

Hi Andy,

(changing the subject to ease tracking this)

The thread I was referring is: 
https://mailarchive.ietf.org/arch/msg/netmod/6VkSrroaxwXHSI19Jj0j-tbFCjA/

I do personally think that it is a good guidance to prefix IETF modules with 
“ietf-“ and IANA-maintained ones with “iana-‘. This is consistent with the 
practice we followed recently for iana-maintained modules.

If we recommend this prefix pattern, I’m afraid that we need to revisit the 
text about short prefixes, e.g.,

OLD:
   Prefix values SHOULD be short but are also likely to be unique.
   Prefix values SHOULD NOT conflict with known modules that have been
   previously published.

NEW:
   Prefix values SHOULD be prefixed with “ietf-“ for IETF modules and
   “iana-“ for IANA-maintained modules. Prefix values SHOULD NOT be
   too long and SHOULD NOT conflict with known modules that have been
   previously published.

Cheers,
Med

De : Andy Bierman 
Envoyé : jeudi 14 mars 2024 22:53
À : Mahesh Jethanandani 
Cc : BOUCADAIR Mohamed INNOV/NET ; netmod@ietf.org
Objet : Re: [netmod] IETF#119 I-D Status: draft-ietf-netmod-rfc8407bis

Hi,

I cannot find this email wrt/ short prefixes


  *   (short/uniqueness of prefixes

Other SDOs are using a prefix in their prefixes (e.g. openconfig).
It is common for servers to have both "if:interfaces" and "oc-if:interfaces" 
subtrees.

It might be a good idea to have a guideline that all IETF YANG modules SHOULD
use the "ietf-" string in the module prefix.  This should reduce the chance of 
name collisions
between SDOs and vendors, and helps identify the module as an IETF module.


Andy



On Tue, Mar 12, 2024 at 10:51 AM Mahesh Jethanandani 
mailto:mjethanand...@gmail.com>> wrote:
Hi Med,

Thanks for driving this effort on updating RFC 8407.

One additional change coming your way, is to address the question of how IANA 
is supposed to handle updates to IANA YANG modules. The YANG doctors are 
currently debating those changes. Once agreed, we will bring that discussion 
here, and will need to update rfc8407bis to provide guidance to authors who 
update an IANA module. Stay tuned.

Cheers.


On Mar 12, 2024, at 5:00 AM, 
mohamed.boucad...@orange.com wrote:

Hi all,


  *   A candidate -10 is ready to address 3 comments from Jan:

 *   Long trees
 *   Updated security template
 *   Minor tweaks to Section 3.8
 *   The changes circulated on the list can be seen here: Compare Editor's Copy 
to 
Datatracker

  *   Jan raised two other comments (short/uniqueness of prefixes + how to 
handle “not set”) but no changes were made per the feedback received on the 
list.
  *   Next steps:

 *   Submit -10 right after IETF#119
 *   WGLC

Cheers,
Med



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


Mahesh Jethanandani
mjethanand...@gmail.com





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

Ce message et ses pieces jointes peuvent 

Re: [netmod] Next steps for draft-ietf-netmod-rfc8407bis

[Christian Hopps]

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
suggestions you might consider.

+ In section 3.4 about tree diagrams, the section text is already
advocating intermixing smaller tree snippets with explanations (which
is great), but I wish we could say that
tree diagrams of entire modules SHOULD NOT be included. Just a waste
of forest and attention span, imho.


The full tree diagram is literally the thing I read first and most in almost 
every YANG RFC/draft. Please do not get rid of it.


+ In section 4.11.5 regarding booleans, it is said that booleans can
take values true and false. This is true in mathematics :-) but in
YANG a boolean leaf can additionally take the "value" of "not set".
Actually, "not set" is a possibility for leafs in general, unless it
is declared mandatory true, or has a default. In my experience, one
of the most common YANG modeling issues is when people model a leaf
foo, which isn't mandatory, has no default and the description
statement does not say what happens if the leaf is not set. In many
cases, there is a sort of natural meaning, but with booleans leafs in
particular, the absence of the leaf is typically highly ambiguous. I
think this hole merits a recommendation clause in the I-D.


I think this general idea of the author having a clear understanding of not-set 
for all non-mandatory nodes, and that it is communicated to the user if need 
be, is a really good one.

Though for the particular case of booleans I would think not-set just implies 
false. Maybe that should be codified if it isn't already. :)

Thanks,
Chris.


Best Regards,
/jan


signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes in YANG 1.0 & YANG 1.1 or not?

[Christian Hopps]

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 sentence like

“A new module revision MAY but SHOULD NOT contain NBC changes … ”

be OK ?

I think the MAY part is also needed< because that is what we are
introducing as new compared to 7950.


IMO using both MAY and SHOULD NOT is confusing and unnecessary. "SHOULD NOT" 
allows a thing while discouraging it.

Thanks,
Chris.




be agreeable?

Regards Balazs



From: Andy Bierman 
Sent: Sunday, 23 July, 2023 17:26
To: Balázs Lengyel 
Cc: Martin Björklund ; netmod@ietf.org
Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC
changes in YANG 1.0 & YANG 1.1 or not?







On Sun, Jul 23, 2023 at 5:08 PM Balázs Lengyel <
balazs.leng...@ericsson.com> wrote:

Hello Andy,

In 3GPP we have endless debates about what is a bugfix. If the
functionality will not work it is a bugfix. If it works in a bad
way it is or maybe not a bugfix. If it works just in an ugly way
is it a bugfix?

Conclusion: it is not possible to define clear criteria about
what is a bug and what is an improvement.





It is easy to change MAY to SHOULD NOT in the versioning draft.



IMO changing MUST NOT to MAY is unacceptable.

The versioning draft is attempting to completely toss out all of the
YANG update rules.

Changing the normative text to SHOULD NOT instead of MAY does not
require any specification of a bugfix.





Regards Balazs





Andy





From: netmod  On Behalf Of Andy Bierman
Sent: Wednesday, 19 July, 2023 10:13
To: Martin Björklund 
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC
changes in YANG 1.0 & YANG 1.1 or not?







On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund <
mbj+i...@4668.se> wrote:

What about Option 4 - Pragmatic Adherence to Current RFC7950
Rules





This is the approach I also suggested on the mailing list.



- As it works today; the IETF *has* published bugfixed
modules that break the
  rules.  (and many vendors do this as well)
- (Possibly) Introduce rev:non-backwards-compatible

This would allow 6991bis to update date-and-time to follow
the updated
semantics for RFC3339 timestamps (which imo is the only
reasonable
thing to do - the consuequences of this change is handled by
SEDATE).





The important thing in each case is to consider

the expected impact on the real world and real deployments.



IMO a bugfix should be OK, even if the rules in RFC 7950 say it
is an NBC change.

But this is not the same thing as changing the rules in a new
document to shift the

implementation burden to the client.



This is only an IETF issue and the burden should be on a WG to
convince the IESG and IETF

that making the NBC change is a bugfix and should be allowed as a
special case.






/martin



Andy




"Jason Sterne (Nokia)"  wrote:
> Hi all,
>
> At the request of the NETMOD chairs, and on behalf of the
YANG Versioning weekly call group, here's a summary of Key
Issue #1 for the versioning work (i.e. for the Module
Versioning and YANG Semver WGLC).
>
> We'd like to suggest that the WG has a strong focus on
deciding on this specific issue first. Then we'll move on to
tackle other key issues. The idea is to try and avoid getting
tangled in a web of multiple intertwined issues.
>
> Key Issue #1 is the following:  Allow NBC changes in YANG
1.0 & YANG 1.1 or not?
>
> For now please avoid debating other issues in this thread
(e.g. multiple vs single label schemes, whether YANG semver
is a good scheme, etc). Let's focus on K1 and work towards a
WG decision.
>
> ###
> K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
>
> Option 1 - Update RFC7950 to Allow NBC Changes
>
---
> - Module Versioning modifies 7950 to allow NBC changes
> - guidance that NBC changes SHOULD NOT be done (impact to
user base)
> - rev:non-backwards-compatible is a YANG extension
> - introduction in published YANG does not impact
current tooling (ignored until recognized)
> PROS:
> - address fundamental requirement of this versioning work
(requirements doc)
> - allows gradual adoption in the industry. YANG authors can
immeditately start publishing with the new extensions.
> - move 

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Christian Hopps]

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 stop actual industry use, contradicts my 
experience.

My experience is that users just want to get work done and don't actually "give a 
crap" (they often used more colorful language :) about things being 100% perfect 
when 95% gets the job done. I believe that drove many of the choices that openconfig made 
in fact. It also drove operators away from the netmod WG as people argued endlessly over 
things like not changing a typedef to match the actual deployed real world situation, b/c 
it's theoretically wrong even if it was operationally correct.

Personally I think a balance must be struck. I think openconfig went too far down the 
"just do whatever works" path, and that IETF/netmod has gotten better about 
being less about something that professors would love, and more about something industry 
actually finds useful, today.

I think Rob is trying to strike that balance (and has been for a while now with 
his work in this area), and I support him.

Thanks,
Chris.


Randy Presuhn  writes:


Hi -

If one accepts your arguments, you've made the case for defining
a new module with typedefs for ipv6-address, etc. with modified
syntax, semantics, and behavioral constraints to fit what has been
deployed, and that modules requiring those perhaps more felicitously-
named typdefs (because at its heart this kerfuffle is about the names)
should import the definitions from there, rather than the existing module.
That would seem the least disruptive path forward.

But I get the feeling that you may envision a world of Yang / Netconf
conformance testing that is far more rigorous than current reality,
at least as reported by those actively involved in tool development.
I'm no fan of the laissez-faire spirit of Netconf, but I fear that
tugging a loose strings like this will unravel the whole wad of yarn,
particularly if any expectations remain that it might support
what has traditionally been called configuration management.  What
happens when the next typedef is found that has been implemented
in a manner not totally consistent with its definition?  This seems
a really really really bad precedent to set.

Randy

On 2022-04-20 6:18 AM, Rob Wilton (rwilton) wrote:

Hi Randy,
Thanks for summarizing, but I don't really agree with your categorization for
(1) or (3).
My interpretation of ip-address and the related v4/v6 types, based on RFC
7950, is that implementations MUST allow clients to configure zoned IP
addresses to be fully complaint with the module definition.  If a server
implementation does not support zoned ip-addresses then it is expected to use
a deviation (e.g., to replace the type with ip-address-no-zone) to indicate
how it does not conform to the model.  I don’t see that is being any different
than an integer datatype with a range “1..255” and the server only supporting
the client configuring values in the range “1..100”.
The "may include a zone index" in the ip-address definitions relates to the
client when writing a value (or server when returning a value), i.e., they
don't have to always provide zones for all IP addresses.  They can leave them
out, and when the zone is left out the "default zone of the device will be
used".
E.g., considering the RFC 6991 and the IP RIB YANG model,
  typedef ipv6-address {
    type string {
  pattern '…’
    }
    description
     "The ipv6-address type represents an IPv6 address in full,
  mixed, shortened, and shortened-mixed notation.  The IPv6
  address may include a zone index, separated by a % sign.
  The zone index is used to disambiguate identical address
  values.  For link-local addresses, the zone index will
  typically be the interface index number or the name of an
  interface. *If the zone index is not present, the default*
* zone of the device will be used.*
  The canonical format of IPv6 addresses uses the textual
  representation defined in Section 4 of RFC 5952
. *The*
* canonical format for the zone index is the numerical*
* format as described in Section 11.2 of RFC 4007
.";*
  |  |    +--rw v6ur:ipv6
  |  |   +--rw v6ur:route* [destination-prefix]
  |  |  +--rw v6ur:destination-prefix
  |  |  |   inet:ipv6-prefix
  |  |  +--rw v6ur:description?  string
  |  |  +--rw v6ur:next-hop
  |  | +--rw (v6ur:next-hop-options)
  |  |    +--:(v6ur:simple-next-hop)
* |  |    |  +--rw 

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Christian Hopps]

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 RFC6991-bis for new modules.

All new modules should:

  - Use `X` in place of `X-no-zone`
  - Use `X-zone` in place of `X` if zone info wanted
  - In the module description indicate that `{ip,ipv4,ipv6}-address` use 
conforms to the guidance in RFC (6991-bis)

Thanks,
Chris.

"Rob Wilton (rwilton)"  writes:


Hi all,





Given the pushback on making a single non-backwards compatible change to the 
new definition, I want to ask whether the following might be a possible path 
that gains wider consensus:

(1) In RFC 6991 bis, I propose that we:
(i) define new ip-address-with-zone types (and v4 and v6 versions) and keep the 
-no-zone versions.
(ii) we change the description of "ip-address" to indicate:
- Although the type allows for zone information, many implementations are
unlikely to accept zone information in most scenarios (i.e., so the description
of the type more accurately reflects reality).
- A new ip-address-with-zone type has been introduced to use where zoned IP
addresses are required/useful, and models that use ip-address with the intention
of supporting zoned IP addresses MUST migrate to ip-address-with-zone.
- In the future (at least 2 years after RFC 6991 bis is published), the 
expectation is that the definition of ip-address will change to match that of 
ip-address-no-zone.

(2) Then in 2 years time, we publish RFC 6991-bis-bis to change the definition of 
ip-address to match ip-address-no-zone and deprecate the "-no-zone" version at 
the same time.

My reasoning as to why to take this path is:
(1) It is a phased migration, nothing breaks, 3rd parties have time to migrate.
(2) It ends up with the right definition (with the added bonus that it aligns 
to the OC definition).
(3) It doesn't require us republishing 40+ RFCs.
(4) it hopefully allows us to use YANG versioning to flag this as an NBC change,
along with the other standards to help mitigate this change (import
revision-or-derived, YANG packages, schema comparison).

I would be keen to hear thoughts on whether this could be a workable consensus 
solution - i.e., specifically, you would be able to live with it.

Regards,
Rob


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

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Christian Hopps]

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 with the semantics or syntax,
I'm sure there would be more sympathy for the argument.  But the heart
of the argument is that the types label's mnemonicity is poor.  That,
coupled with the collateral damage resulting from a "fix", makes
the whole argument terribly unpersuasive to me, particularly
when the definition in question was been published, implemented, and
deployed years ago.


FWIW, I'm not arguing for this change; however, to be fair, isn't this also 
about the existing published modules that are using the incorrect type?

Thanks,
Chris.




Randy

___
Lsr mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Christian Hopps]

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 unknowable.

WG B comes along, and wants to use X, but dislikes the name, preferring
to call it Y instead.  WG B then demands that A rename X to Y, with
no regard to the process for managing changes to types nor to the
collateral damage resulting from the changed definition of Y.


Hi Randy,

It's not really like this.

Instead, Acee (I'm not sure I'd call him WG B :) is asserting that *nobody* 
actually wanted the current type, and it has been misused everywhere and all 
over. The vast majority of implementations in operation probably can't even 
handle the actual type (Andy's point). So, Acee is just the messenger of bad 
news here. Please note that the AD in charge of all this agreed with Acee as 
well.

Thanks,
Chris.



That we should even be bothering with this discussion is the kind of
thing that gives standards organizations a bad name.

Randy

___
Lsr mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


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

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Christian Hopps]

> On Apr 5, 2022, at 09:48, Acee Lindem (acee)  wrote:
> 
> [wg-member]
> 
> The thing is that most of the existing RFCs use inet:ip-address rather 
> inet:ip-address-no-zone. It would be better to if we could fix 
> inet:ip-address in RFC 6991 BIS to not include the zone similar to what was 
> done in the MIB (RFC 4001). However, we're getting the passive aggressive 
> treatment on this point. 
> 
> If the netmod WG doesn't have the integrity and strength to fix RFC 6991 in 
> the BIS version, we should consider changing the OSPF and IS-IS base 
> specifications before publication to use inet:ip-address-no-zone. 

[as wg-member]

I think we should do the right thing in our (LSR) modules no matter what, 
again, what harm does it do to get it right in the modules under LSR WGs direct 
control?

The netmod change is a much larger action with a large 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 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 the MIB,  the base types don't include the zone - 
>> https://www.ietf.org/rfc/rfc4001.txt
>> 
>> It was very unfortunate that the YANG IP addresses included the zone in the 
>> base types. 
>> 
>> Tom - I think it would be hard to find an author where including the zone 
>> was a conscious decision. 
>> 
>> Thanks,
>> Acee
>> 
>> On 4/4/22, 11:55 AM, "tom petch"  wrote:
>> 
>>   From: Acee Lindem (acee) 
>>   Sent: 04 April 2022 15:58
>> 
>>   Hi Tom, +Juergen, netmod WG,
>> 
>>   I think the question you ought to be asking is whether the base IPv4 and 
>> IPv6 address types should be modified to NOT include the zone and the zone 
>> versions should be added as a separate YANG type.
>> 
>>   The RFC 6991 is under revision now:
>> 
>>   https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/
>> 
>>   However, I'm not sure if the painful backward compatibility discussions 
>> could be overcome.  We'd also have to admit that it was a big mistake to 
>> include the zone in the base addresses. In any case, I don't think we just 
>> start using the no-zone types when the base addresses types are used 
>> everywhere.
>> 
>>   
>> 
>>   Well, there are plenty of uses of the no-zone types as well, so some 
>> authors, some YANG doctors, have made the conscious choice to use them.  I 
>> cannot do a search just now but I see no-zone in the dhc and I2NSF WG I-Ds, 
>> and there are others.
>> 
>>   Also, some authors want the zone information as part of their leaf.
>> 
>>   Tom Petch
>> 
>>   Thanks,
>>   Acee
>> 
>> 
>> 
>>   On 4/4/22, 7:11 AM, "Lsr on behalf of tom petch" > behalf of ie...@btconnect.com> wrote:
>> 
>>   I assume that this is a refresh while waiting for ospf.yang to wind 
>> its way through the system
>> 
>>   I wonder if the ip address should be the no-zone variant from RFC6991 
>> - I never know the answer to that so keep asking.
>> 
>>   Some time the contact needs updating to https://datatracker and the 
>> TLP to 'Revised'
>> 
>>   Tom Petch
>> 
>>   
>>   From: Lsr  on behalf of internet-dra...@ietf.org 
>> 
>>   Sent: 07 March 2022 03:14
>>   To: i-d-annou...@ietf.org
>>   Cc: l...@ietf.org
>>   Subject: [Lsr] I-D Action: 
>> draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
>> 
>> 
>>   A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>>   This draft is a work item of the Link State Routing WG of the IETF.
>> 
>>   Title   : YANG Model for OSPFv3 Extended LSAs
>>   Authors : Acee Lindem
>> Sharmila Palani
>> Yingzhen Qu
>>   Filename: 
>> draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
>>   Pages   : 29
>>   Date: 2022-03-06
>> 
>>   Abstract:
>>  This document defines

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Christian Hopps]

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 the MIB,  the base types don't include the zone - 
> https://www.ietf.org/rfc/rfc4001.txt
> 
> It was very unfortunate that the YANG IP addresses included the zone in the 
> base types. 
> 
> Tom - I think it would be hard to find an author where including the zone was 
> a conscious decision. 
> 
> Thanks,
> Acee
> 
> On 4/4/22, 11:55 AM, "tom petch"  wrote:
> 
>From: Acee Lindem (acee) 
>Sent: 04 April 2022 15:58
> 
>Hi Tom, +Juergen, netmod WG,
> 
>I think the question you ought to be asking is whether the base IPv4 and 
> IPv6 address types should be modified to NOT include the zone and the zone 
> versions should be added as a separate YANG type.
> 
>The RFC 6991 is under revision now:
> 
>https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/
> 
>However, I'm not sure if the painful backward compatibility discussions 
> could be overcome.  We'd also have to admit that it was a big mistake to 
> include the zone in the base addresses. In any case, I don't think we just 
> start using the no-zone types when the base addresses types are used 
> everywhere.
> 
>
> 
>Well, there are plenty of uses of the no-zone types as well, so some 
> authors, some YANG doctors, have made the conscious choice to use them.  I 
> cannot do a search just now but I see no-zone in the dhc and I2NSF WG I-Ds, 
> and there are others.
> 
>Also, some authors want the zone information as part of their leaf.
> 
>Tom Petch
> 
>Thanks,
>Acee
> 
> 
> 
>On 4/4/22, 7:11 AM, "Lsr on behalf of tom petch"  behalf of ie...@btconnect.com> wrote:
> 
>I assume that this is a refresh while waiting for ospf.yang to wind 
> its way through the system
> 
>I wonder if the ip address should be the no-zone variant from RFC6991 
> - I never know the answer to that so keep asking.
> 
>Some time the contact needs updating to https://datatracker and the 
> TLP to 'Revised'
> 
>Tom Petch
> 
>
>From: Lsr  on behalf of internet-dra...@ietf.org 
> 
>Sent: 07 March 2022 03:14
>To: i-d-annou...@ietf.org
>Cc: l...@ietf.org
>Subject: [Lsr] I-D Action: 
> draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
> 
> 
>A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>This draft is a work item of the Link State Routing WG of the IETF.
> 
>Title   : YANG Model for OSPFv3 Extended LSAs
>Authors : Acee Lindem
>  Sharmila Palani
>  Yingzhen Qu
>Filename: 
> draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
>Pages   : 29
>Date: 2022-03-06
> 
>Abstract:
>   This document defines a YANG data model augmenting the IETF OSPF 
> YANG
>   model to provide support for OSPFv3 Link State Advertisement (LSA)
>   Extensibility as defined in RFC 8362.  OSPFv3 Extended LSAs provide
>   extensible TLV-based LSAs for the base LSA types defined in RFC 
> 5340.
> 
> 
>The IETF datatracker status page for this draft is:
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
> 
>There is also an htmlized version available at:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-10
> 
>A diff from the previous version is available at:
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospfv3-extended-lsa-yang-10
> 
> 
>Internet-Drafts are also available by rsync at 
> rsync.ietf.org::internet-drafts
> 
> 
>___
>Lsr mailing list
>l...@ietf.org
>https://www.ietf.org/mailman/listinfo/lsr
> 
>___
>Lsr mailing list
>l...@ietf.org
>https://www.ietf.org/mailman/listinfo/lsr
> 
> 
> ___
> Lsr mailing list
> l...@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

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

Re: [netmod] Camel Case versus hyphenation

[Christian Hopps]

> 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 consistently, is likely to be a source of confusion.
>> 
> 
> If someone tells a human operator over the phone to set the wait time
> to 42, then it is likely that the operator assumes the leaf is called
> wait-time. Many network operators are not state machine implementors
> and they likely appreciate consistency at the management interface
> more than consistency with the spelling in some protocol specs.


100% agree.

The vast majority of the users of these YANG modules and models will probably 
never read the multitude of underlying RFCs. What they will do is interact with 
the sum of many modules that model these RFCS, maybe even using a single 
unified management system. I think consistency should be defined in that 
context then, from the users standpoint.

Thanks,
Chris.

> 
> /js
> 
> -- 
> Jürgen Schönwälder  Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> 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] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)]

[Christian Hopps]

> 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 stability and backward compatibility.

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

Re: [netmod] json empty leaf encoding strangeness [Re: WG Last Call for draft-ietf-netmod-yang-json-04 (until 2015-06-29)]

[Christian Hopps]

> 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 language, which incidentally has a couple of 
> representation formats (YANG-XML, YANG-JSON, YANG-CBOR).
> There is no intention for the YANG generic data model (the set of all data 
> models YANG can express) to cover the generic data model of the 
> representation format.

To be clear, the question I raised is about an encoding of YANG modeled data. 
In particular the JSON encoding of the YANG empty leaf element.

  https://datatracker.ietf.org/doc/html/rfc7951#section-6.9

the justification for having the very odd encoding was that there was some 
belief that some programming languages might have trouble with the obvious JSON 
"null" encoding (which stands for "no value" in JSON -- exactly what we want 
here). An old email gave a python example to try and illustrate this, except 
the python example was an incorrect use of python for this case (presence 
check) and not a problem with the natural JSON encoding for no value items. In 
fact correctly written python code has no problem at all with the more natural 
"null" encoding, and results in the correct internal representation in python 
to boot.

This isn't about the YANG specification in general, or making YANG conform to 
any particular language. It's just about the a choice in the specification for 
the encoding of YANG in a particular format (JSON).

Thanks,
Chris.



> 
> While RFC 8791 (and before it RFC 8040) extended YANG to be able to describe 
> data in flight, there is no intention that YANG can be used to describe the 
> entire expressibility of the representation format.  We have Relax-NG, CDDL, 
> and a few other modeling approaches if we need that.

> Grüße, Carsten
> 

___
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)

[Christian Hopps]

> 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 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 

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

[Christian Hopps]

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 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.


Let's start with a simple baseline, if you want to dig any deeper than the well 
understood Lat+Long; do you know what a geodetic datum is? This is required 
knowledge if you want to get into anything more than the obvious Lat+Long use 
of this grouping. It defines the coordinates and also the accuracy of 
measurements.

It is out way out of scope for this YANG grouping to try and explain th

Re: [netmod] Lars Eggert's Abstain on draft-ietf-netmod-geo-location-10: (with COMMENT)

[Christian Hopps]

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 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/



--
COMMENT:
--

I disagree with the approach taken to deal with unstable URLs used in -08
for various normative references (e.g., [EGM08] , [EGM96]), which was to
remove the URLs and leave future implementers hoping they can track down
the correct spec manually.


So you really think someone who cares to the detail level of a sub-specifications of the 
WGS-84 geodesic standard only has a "hope" of finding said sub-specification? 
This YANG grouping isn't supposed to be teaching people about geodesic data, they are 
expected to know that.

Keeping that in mind, I think inserting best-guess URLs that have already been 
shown to be ephemeral, may be inferior to the expected readers own knowledge, 
in a standards document reference, seems a rather poor choice.

If there is no give here, I of course will give up and put some reference back 
in, so the thing can progress.


---

Section 2.3, paragraph 2, comment:

   3-dimensional vector value.  The components of the vector are
   "v-north", "v-east" and "v-up" which are all given in fractional


In the formulas in the text rendering of the document, these components are
called "v_{north}", etc. It would be good to use a single variant in both the
text and any formulas.

This document uses RFC2119 keywords, but does not contain the recommended
RFC8174 boilerplate. (It contains some text with a similar beginning.)


Document text:

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
  "OPTIONAL" in this document are to be interpreted as described in
  [RFC2119] [RFC8174] when, and only when, they appear in all capitals,
  as shown here.


Boilerplate from RFC8174:

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
  "OPTIONAL" in this document are to be interpreted as described in
  BCP 14
  [RFC2119] [RFC8174] when, and only when, they appear in all capitals,
  as shown here.

"It contains some text with a similar beginning" might be the worst one can 
make the above difference sound w/o actually being un-factual. I will add the missing 2 
words.

Thanks,
Chris.



---
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 1, paragraph 2, nit:
-might be the location of data center, a rack in an internet exchange
-   ^
+might be the location of data center, a rack in an Internet exchange
+   ^

Section 2.5, paragraph 1, nit:

development of this module, the question of whether it would support data su
^^^

Wordiness: Consider shortening this phrase.

Section 3, paragraph 17, nit:

 describes this motion at the the time given by the timestamp. For a
  ^^^

Maybe you need to remove one determiner so that only "the" or "the" is left.

Section 4, paragraph 4, nit:

lts For test "A.1.2.1" the YANG geo location object either includes a CRS ("r


This word is normally spelled as one.

Section 5.1.4, paragraph 4, nit:

value, the YANG grouping supports the ignore case but not the relative case.
  ^^

After 'the', do not use a verb. Make sure that the spelling of 'ignore' is
correct. If 'ignore' is the first word in a compound adjective, use a hyphen
between the two words. Note: This error message can occur if you use a verb as
a noun, and the word is not a noun in standard English.

Section 7, paragraph 6, nit:

e than standard configuration. Some of the readable data nodes in this YANG m
   ^^^

If the text is a generality, 'of the' is not necessary.

"Appendix A.", paragraph 3, nit:

ure 2: Example YANG module using 

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

[Christian Hopps]

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:


Francesca Palombini via Datatracker  writes:

> Francesca Palombini has entered the following ballot position for
> draft-ietf-netmod-geo-location-08: Discuss
>

>
> --
> DISCUSS:
> --
>
> Thank you for the work on this document, and thank you to the shepherd 
for a
> very well-written shepherd write up.
>
> I have a couple of DISCUSS points related to the IANA section, and some 
non
> blocking question.
>
> Francesca
>
> 1. -
>
>The allocation policy for this registry is First Come, First Served,
>[RFC8126] as the intent is simply to avoid duplicate values.
>
> FP: RFC 8126 specifies:
>
>When creating a new registry with First Come First Served as the
>registration policy, in addition to the contact person field or
>reference, the registry should contain a field for change controller.
>Having a change controller for each entry for these types of
>registrations makes authorization of future modifications more clear.
>See Section 2.3.
>
> The current registry dos not contain contact person, nor reference, nor 
change
> controller fields.

I honestly have no idea what to put in that field for the referenced 
standards. Certainly we can't just point people at the defining standards or 
people who wrote them as they have no reason to pay attention to our YANG 
groupings IANA registry. Should I put myself, or the NETMOD working group 
perhaps?

FP: For the value you register in this document, I think it would make sense to 
have the reference to this document. For change controller, it is quite common 
to have IESG. That would mean two changes:
- add 2 columns: "Reference" and "Change control" to table 3, where Reference is
[This document] and Change control is IESG, for all rows. (You don't need to add
one column for contact person, I have noticed it is quite common for IANA
registry to use that same Reference column to point either to a standard or to a
contact person)
- add a sentence stating that "Reference" can point to the document doing the 
registration or the contact person, as defined by RFC 8126.

> 2. -
>
>It should be noted that [RFC5870] also creates a registry for
>Geodetic Systems (it calls CRS); however, this registry has a very
>strict modification policy.  The authors of [RFC5870] have the stated
>goal of making CRS registration hard to avoid proliferation of CRS
>values.  As our module defines alternate systems and has a broader
>(beyond Earth) scope, the registry defined below is meant to be more
>easily modified.
>
> FP: Thanks for bringing this up - I want to confirm that we need this 
registry,
> and that we are not creating a way to bypass the CRS registration 
policies by
> providing a different registry with a more lenient policy.
>

FP: This was discussed during the telechat and is resolved, so as soon as we 
agree on point 1. I will remove my DISCUSS.

>
> --
> COMMENT:
> --
>
>
> 3. -
>
>[WGS84]National Imagery and Mapping Agency., "National Imagery
>   and Mapping Agency Technical Report 8350.2, Third
>   Edition.", 3 January 2000, <http://earth-
>   info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf>.
>
> FP: I support Lars DISCUSS, and add the following normative reference to 
the
> list - link is broken. A quick google search found this:
> 
https://protect2.fireeye.com/v1/url?k=8c4dc9b7-d3d6f09a-8c4d892c-8692dc8284cb-c0df19b629553d9e=1=7e44c916-ff47-4dae-b193-a89283c49472=https%3A%2F%2Fgis-lab.info%2Fdocs%2Fnima-tr8350.2-wgs84fin.pdf
 , which I assume is the
> wanted reference... but I don't think that we should be relying on 
informal
> communities to maintain normative references to our documents, can we do 
better?

I removed the URLs -- obviously they are not stable. So we can proceed with 
the normal document title, author, and publication date.

FP: I see that there was discussion with Lars about it, so I 

Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs

[Christian Hopps]

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 of the module 
and examples, generating YANG trees, downloading YANG dependencies etc.. :)

An example use: https://github.com/choppsv1/draft-chopps-netmod-geo-location 


Thanks,
Chris.

> On Jun 14, 2021, at 10:09 AM, Michael Richardson  
> wrote:
> 
> 
> Carsten Bormann  wrote:
>> On 14. Jun 2021, at 03:09, Michael Richardson  wrote:
>>> 
>>> 1) how to process yang files with -DD-MM into XML.
>>> 2) how to generate yang tree files.
>>> 3) how do I get my YANG includes downloaded, and do I put them into my repo?
>>> 4) how to do this with MT Makefiles?
> 
>> I people could tell me what they need, we could develop a feature in
>> kramdown-rfc to handle this.
> 
> One possibility is that kramdown-rfc ought to look for, and include the
> latest foo--MM-DD.yang file, when told to ::include foo.yang.
> Alternatively, it could perhaps do the -MM-DD substitution itself.
> 
>> (This would presumably also include support for YANG-SID files.)
> 
> That's mostly just a question about including the results, and it's not that
> hard thing to add to the main Makefile.
> 
> But, as I said, I xml2rfc doesn't have a useful include functionality, for
> when not working with kramdown.
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>   Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> ___
> 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] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT)

[Christian Hopps]

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 blank line where it originally was, na errant D or 
something in vi. :)

I've put it back.


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.


I've included a reference for 'me', and removed mola-vik-1 b/c it was simply 
too hard to find a good reference for it.


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
apply, they can safely be removed.  In particular, the "these are the
subtrees and data nodes and their sensitivity/vulnerability" lines can
go, and the clause about "can have a negative effect on network
operations" may be worth tweaking (network operations may not be the
most likely thing to be impacted).  I think it's also okay to drop the
paragraph/sentence about RPCs.


Updated.


signature.asc
Description: PGP signature
___
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)

[Christian Hopps]

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.


--
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.


This is a very edge case of this grouping meant really to handle something like 
continental drift with long stored values. One can keep drilling down on this 
particular velocity value seemingly forever, but then we aren't getting our 
work done. I think it's enough to say that if the usable values don't work for 
a use case at this point, then they don't work.


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.


Ok changed to "overriding".



   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.


It doesn't hurt anything to include it and it was asked for by the person who 
came up with the shape of this grouping (Peter L.). Unless there's a strong 
objection I'd prefer to leave it in deference to the person who asked for it.


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
  

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

[Christian Hopps]

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

Thank you for the work on this document, and thank you to the shepherd for a
very well-written shepherd write up.

I have a couple of DISCUSS points related to the IANA section, and some non
blocking question.

Francesca

1. -

   The allocation policy for this registry is First Come, First Served,
   [RFC8126] as the intent is simply to avoid duplicate values.

FP: RFC 8126 specifies:

   When creating a new registry with First Come First Served as the
   registration policy, in addition to the contact person field or
   reference, the registry should contain a field for change controller.
   Having a change controller for each entry for these types of
   registrations makes authorization of future modifications more clear.
   See Section 2.3.

The current registry dos not contain contact person, nor reference, nor change
controller fields.


I honestly have no idea what to put in that field for the referenced standards. 
Certainly we can't just point people at the defining standards or people who 
wrote them as they have no reason to pay attention to our YANG groupings IANA 
registry. Should I put myself, or the NETMOD working group perhaps?


2. -

   It should be noted that [RFC5870] also creates a registry for
   Geodetic Systems (it calls CRS); however, this registry has a very
   strict modification policy.  The authors of [RFC5870] have the stated
   goal of making CRS registration hard to avoid proliferation of CRS
   values.  As our module defines alternate systems and has a broader
   (beyond Earth) scope, the registry defined below is meant to be more
   easily modified.

FP: Thanks for bringing this up - I want to confirm that we need this registry,
and that we are not creating a way to bypass the CRS registration policies by
providing a different registry with a more lenient policy.


--
COMMENT:
--


3. -

   [WGS84]National Imagery and Mapping Agency., "National Imagery
  and Mapping Agency Technical Report 8350.2, Third
  Edition.", 3 January 2000, .

FP: I support Lars DISCUSS, and add the following normative reference to the
list - link is broken. A quick google search found this:
https://gis-lab.info/docs/nima-tr8350.2-wgs84fin.pdf , which I assume is the
wanted reference... but I don't think that we should be relying on informal
communities to maintain normative references to our documents, can we do better?


I removed the URLs -- obviously they are not stable. So we can proceed with the 
normal document title, author, and publication date.


4. -

   choice "latitude" and "longitude" are specified as fractions of
   decimal degrees, and the "height" value is in fractions of meters.
   For the Cartesian choice "x", "y" and "z" are in fractions of meters.

FP: I have the feeling that the document is specifying both numeric data
expected and unit at the same time "fraction of _insert unit_". For the sake of
clarity, I think it would be best to split this up, so change the "fraction of
meters" to "meters, expressed in floating point". TODO: check that format is
defined.


It is specifying units and their format, I felt this was simply concise, but 
not confusing. Do you feel strongly about this? FWIW we use YANG decimal64 not 
floating point in the YANG grouping.


5. -

FP: After looking for a while: does a stable reference exist for the list of
astronomical bodies and their name (rather than just saying it is maintained by
IAU)? I only found the following for stars:
https://www.iau.org/public/themes/naming_stars/ . I also found the page for the
corresponding WG, which defined the guidelines for naming stars. I was
wondering if there is a reference to these guidelines for all astronomical
bodies. What I am especially concerned about is that I was not able to verify
that we will not incur on encoding problems, if IAU changes their naming
conventions, given the following text in the document:

'67p/churyumov-gerasimenko (a comet). The value should
be 

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

[Christian Hopps]

Roman Danyliw via Datatracker  writes:

--
DISCUSS:
--

** Section 3.  leaf astronomical-body.  The content of this field appears to be
"An astronomical body as named by the International Astronomical Union (IAU) or
according to the alternatesystem if specified."  What’s the
normative reference to the IAU’s list of astronomical bodies.  Listed here is
“https://www.iau.org” which is an unstable reference to a website with changing
content.


I have none.


--
COMMENT:
--

Thank you to Stefan Santesson for the SECDIR review.

** Section 6.1.  Should the constraining pattern “[ -@\[-\^_-~]*” and
associated text from leaf geodetic-datum be used to guide the acceptable values
of the 'name' column?


Well the pattern allows more than the SHOULD and MUSTs in the IANA section, in 
order to not be overly restrictive on users.


signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Martin Duke's No Record on draft-ietf-netmod-geo-location-08: (with COMMENT)

[Christian Hopps]

Martin Duke via Datatracker  writes:

--
COMMENT:
--

(2.2) "For the standard location choice latitude and longitude are specified as
fractions of decimal degrees, and the height value is in fractions of meters."

What are "fractions of decimal degrees"? Is it not better to just say "decimal
degrees" and "decimal meters"?


Yes, fixed.



signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] John Scudder's No Objection on draft-ietf-netmod-geo-location-08: (with COMMENT)

[Christian Hopps]

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 remaining nits.

Thanks,
Chris.


Section 5.1:

   In order to verify portability while developing this module the
   following standards and standard APIs and were considered.

“and were” -> “were”

Section 5.1.1:

   all the location values.  As the URI is a string, all values are
   specifies as strings and so are capable of as much precision as

“specifies” -> “specified”

Section 5.1.3:

   position type "gml:pos" which is a sequence of "double" values.  This
   sequence of values represent coordinates in a given CRS.  The CRS is

“represent” -> “represents” (because “sequence” is singular)

   Earth based CRS as well as virtual CRS should also be representable
   by the GML CRS types as well.

Drop “as well” (redundant with “also”).

Section 6.1:

   This registry allocates names for standard geodetic systems.  Often
   these values are referred to using multiple names (e.g., full names
   or multiple acronyms values).  The intent of this registry is to

“Multiple acronym values” or better still “multiple acronyms”.

Appendix A:

 description "A of locatable item";

Lose the “of”.




signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Murray Kucherawy's No Objection on draft-ietf-netmod-geo-location-08: (with COMMENT)

[Christian Hopps]

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 Terra Stream project."  I'm
tempted to ask why this is slotted for Standards Track publication.


It's a grouping, it's meant to be incorporated into other YANG modules rather 
than have each module come up with their own version of a geo-location object.

So, it's wont be "implemented" directly by any vendor until it is published and 
can start to be used in other module definitions. There definitely is interest in this 
use in the netmod WG.


signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Erik Kline's No Objection on draft-ietf-netmod-geo-location-08: (with COMMENT)

[Christian Hopps]

Erik Kline via Datatracker  writes:


--
COMMENT:
--

[[ questions ]]

[ section 2.1 ]

* Is WGS-84 still the default for geodetic-datum when
  astronomical-body != "earth"?

  I think I might find it surprising if it were (i.e. if
  astronomical-body="enceladus" and geodetic-datum still defaults to "wgs-84"
  as opposed to an unspecified value or something that might cause a useful
  error message to be generated).

  I don't know enough YANG to know if the "when" statement is usable in this
  case to constrain the applicability of this default or not.


This is very interesting question. I do not believe there are multiple defaults 
allowed. I have actually run into this in other YANG modules where it would be 
nice to have conditional defaults.

I think the only thing we can do is either have no default which seems sub-optimal given 
+99% of the use cases will be "earth", or make a note in the description that 
the default should be overridden by explicitly setting, when the astronomical body is != 
earth.

Thanks,
Chris.


[[ nits ]]

[ section 3 ]

* In the description of "leaf astronomical-body",
  '67p/churyumov-gerasimenko lacks a closing quotation mark.



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




signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] inet:ipv4-address

[Christian Hopps]

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-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?


It was discussed e.g. in these threads:

*
https://mailarchive.ietf.org/arch/browse/netmod/?gbt=1=subject%3A%22draft-schoenw-netmod-rfc6021-bis-01%20(20130204)%22

*
https://mailarchive.ietf.org/arch/browse/netmod/?gbt=1=gcMx6c-NFt2UCbtBFi7BsUWf0EU

Lada



I see that OpenConfig chose the opposite meaning for the "obvious" names
(i.e., you want zoned addresses you use "-zoned" types e.g.,
"ipv6-address-zoned").

Thanks,
Chris.

___
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

[netmod] inet:ipv4-address

[Christian Hopps]

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 you use "-zoned" types e.g., "ipv6-address-zoned").

Thanks,
Chris.

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

Re: [netmod] Genart last call review of draft-ietf-netmod-geo-location-08

[Christian Hopps]

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 creating a Constant for the pattern to be referenced?
in case you want to make changes to the pattern.


Changing the pattern in YANG is a backward incompatible change, so we don't 
actually want to make that indirect or easy. :)

Thanks,
Chris.



Major issues: None.

Minor issues: None.

Nits/editorial comments: None.

Best Regards,
Linda Dunbar


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

Re: [netmod] Last Call: (A YANG Grouping for Geographic Locations) to Proposed Standard

[Christian Hopps]

> 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 because in my (admittedly limited) 
> experience, ENU order (or NED for that matter) was more familiar since it 
> forms a coordinate system that aligns with the right hand rule.
> 
> NEU->ENU conversion is obviously trivial.  I was just thinking of possible 
> errors where the members of the vector aren't accessed by name but by 
> position.
> 
> -ek
> 
> On Mon, Apr 19, 2021 at 7:07 AM The IESG  > wrote:
> 
> The IESG has received a request from the Network Modeling WG (netmod) to
> consider the following document: - 'A YANG Grouping for Geographic Locations'
>as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> last-c...@ietf.org  mailing lists by 2021-05-03. 
> Exceptionally, comments may
> be sent to i...@ietf.org  instead. In either case, 
> please retain the beginning
> of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>This document defines a generic geographical location object YANG
>grouping.  The geographical location grouping is intended to be used
>in YANG models for specifying a location on or in reference to Earth
>or any other astronomical object.
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/ 
> 
> 
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
> 
> 
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org 
> https://www.ietf.org/mailman/listinfo/ietf-announce 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] AD review of draft-ietf-netmod-geo-location-07

[Christian Hopps]

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:rwil...@cisco.com>>
>> Cc: Christian Hopps mailto:cho...@chopps.org>>; 
>> netmod@ietf.org <mailto:netmod@ietf.org>; draft-ietf-
>> netmod-geo-location@ietf.org <mailto:netmod-geo-location@ietf.org>
>> Subject: Re: AD review of draft-ietf-netmod-geo-location-07
>> 
>> 
>> 
>>> 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 grammatical nits. Some I
>> spotted manually; the rest are from a beta version of a grammar tool that
>> I am playing with.
>>> 
>>> Minor comments/questions:
>>> 
>>> 1.
>>> In the YANG module, the pattern statements have 3 ranges of characters,
>>> but the description only indicates two ranges.  Is there a reason that
>>> the following pattern doesn't work?
>>> pattern '[ -@\[-~]*';
>> 
>> From an old email on the list: "These 3 ranges seem to make pyang happy. I
>> don't know why I need to break up the second range into 2 adjacent ranges
>> like that to make pyang not complain, but complain it does if I just use:
>> '[ -@\[-~]*'"
> [RW]
> 
> Okay.
> 
> 
>> 
>>> 2.
>>> I note that the YANG module allows just a lat, or a long, or a height
>>> to be specified, rather than requiring at least a pair of lat/long or
>>> x/y coordinates.  I think that this is fine (and keeps the model
>>> flexible), but wanted to check that this is the intentional.
>> 
>>> 3.
>>> I also note that that grouping doesn't require that any coordinates be
>>> specified at all.  I presume that this is intentional, it makes sense
>>> to me (e.g., if it is intended to be optional).
>> 
>> My answer to a thread on the list asking for removal of some of the
>> mandatory designations which cause problems:
>> 
>> "The intention was for a location node to be required if the > location> 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 an object). I'll remove the mandatory
>> from location."
> [RW]
> 
> Okay.
> 
> 
>> 
>> 
>>> 4. In the YANG module,
>>> "v-east is the rate of change (i.e., speed) perpendicular
>>> to truth-north as defined by the geodetic-system.";
>>> 
>>> As a nit, this doesn't actually define whether a positive v-east
>>> value is in the East or West direction.  I appreciate that this is
>>> obvious, but for the other two components in the vector, it is
>>> unambiguously specified.
>> 
>> How about:
>> 
>>  "v-east is the rate of change (i.e., speed) perpendicular
>>   to the right of truth-north as defined by
>>   the geodetic-system.";
> [RW]
> 
> LGTM.
> 
> 
>> 
>> 
>>> 
>>> 5.
>>> In Security Considerations:
>>> 
>>>  Since the grouping defined in this module identifies locations,
>>>  authors using this grouping SHOULD consider any privacy issues that
>>>  may arise when the data is readable.
>>> 
>>> Perhaps, expand this paragraph to give an example, e.g., revealing
>>> the physical location of a device, or data center.
>> 
>> How about:
>> 
>> "Since the grouping defined in this module identifies locations,
>> authors using this grouping SHOULD consider any privacy issues
>> that may arise when the data is readable (e.g., customer device
>> locations, etc)."
> [RW]
> 
> LGTM.
> 
> 
>> 
>> 
>>> 
>>> The rest are just grammar nits:
>>> 
>>> 
>>>  In addition to identifying the astronomical body we also need to
>>>  define the meaning of the coordinates
>>> =>
>>>  In addition to identifying the astronomical body, we als

Re: [netmod] AD review of draft-ietf-netmod-geo-location-07

[Christian Hopps]

> 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 grammatical nits. Some I 
> spotted manually; the rest are from a beta version of a grammar tool that I 
> am playing with.
> 
> Minor comments/questions:
> 
> 1.
> In the YANG module, the pattern statements have 3 ranges of characters,
> but the description only indicates two ranges.  Is there a reason that
> the following pattern doesn't work?
>  pattern '[ -@\[-~]*';

From an old email on the list: "These 3 ranges seem to make pyang happy. I 
don't know why I need to break up the second range into 2 adjacent ranges like 
that to make pyang not complain, but complain it does if I just use: '[ 
-@\[-~]*'"

> 2.
> I note that the YANG module allows just a lat, or a long, or a height
> to be specified, rather than requiring at least a pair of lat/long or
> x/y coordinates.  I think that this is fine (and keeps the model
> flexible), but wanted to check that this is the intentional.

> 3.
> I also note that that grouping doesn't require that any coordinates be
> specified at all.  I presume that this is intentional, it makes sense
> to me (e.g., if it is intended to be optional).

My answer to a thread on the list asking for removal of some of the mandatory 
designations which cause problems:

"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 an object). I'll remove the mandatory from location."


> 4. In the YANG module,
> "v-east is the rate of change (i.e., speed) perpendicular
> to truth-north as defined by the geodetic-system.";
> 
> As a nit, this doesn't actually define whether a positive v-east
> value is in the East or West direction.  I appreciate that this is
> obvious, but for the other two components in the vector, it is
> unambiguously specified.

How about:

  "v-east is the rate of change (i.e., speed) perpendicular
   to the right of truth-north as defined by
   the geodetic-system.";


> 
> 5.
> In Security Considerations:
> 
>   Since the grouping defined in this module identifies locations,
>   authors using this grouping SHOULD consider any privacy issues that
>   may arise when the data is readable.
> 
> Perhaps, expand this paragraph to give an example, e.g., revealing
> the physical location of a device, or data center.

How about:

"Since the grouping defined in this module identifies locations,
authors using this grouping SHOULD consider any privacy issues
that may arise when the data is readable (e.g., customer device
locations, etc)."


> 
> The rest are just grammar nits:
> 
> 
>   In addition to identifying the astronomical body we also need to
>   define the meaning of the coordinates
> =>
>   In addition to identifying the astronomical body, we also need to
>   define the meaning of the coordinates

fixed

> 
>   In addition to the "geodetic-datum" value we allow refining the
>   coordinate and height accuracy using "coord-accuracy" and "height-
>   accuracy" respectively.
> =>
>   In addition to the "geodetic-datum" value, we allow refinement of the
>   coordinate and height accuracy using "coord-accuracy" and "height-
>   accuracy" respectively.

fixed

>   This is the location on or relative to the astronomical object.  It
>   is specified using 2 or 3 coordinates values.
> =>
>   This is the location on, or relative to, the astronomical object.  It
>   is specified using 2 or 3 coordinates values.

fixed

>   The intent of the grouping being defined here is to identify
>   where something is located, and generally this is expected to be
>   somewhere on or relative to Earth (or another astronomical body).
> =>
>   The intent of the grouping being defined here is to identify
>   where something is located, and generally this is expected to be
>   somewhere on, or relative to, Earth (or another astronomical body).

fixed

>   At
>   least two options are available to YANG models that wish to use this
>   grouping with objects that are changing location frequently in non-
>   simple ways, they can add additional motion data to their model
>   directly, or if the application allows it can require more frequent
>   queries to keep the location data current.
> =>
>   At
>   least two options are available to YANG models that wish to use this
>   grouping with objects that are changing location frequently in non-
>   simple ways.  They can add additional motion data to their model
>   directly.  Or, if the application allows, it can require more frequent
>   queries to keep the location data current.

fixed

> When 

Re: [netmod] I-D Action: draft-ietf-netmod-geo-location-06.txt

[Christian Hopps]

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 identified during WGLC.
> 
> 
> 
> Chris
> 
> I did suggest expanding the contact in the YANG module as e.g. in rfc6991-bis 
> (or RFC8407)with
> 
>   contact
>"WG Web:   <https://datatracker.ietf.org/wg/netmod/>
> WG List:  <mailto:netmod@ietf.org>
> 
> Editor:   Christian ...
> 
> Tom Petch
> 
> Thanks,
> Chris.
> 
> 
>> On Dec 2, 2020, at 6:27 AM, internet-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  : Christian Hopps
>>  Filename: draft-ietf-netmod-geo-location-06.txt
>>  Pages   : 25
>>  Date: 2020-12-02
>> 
>> Abstract:
>>  This document defines a generic geographical location object YANG
>>  grouping.  The geographical location grouping is intended to be used
>>  in YANG models for specifying a location on or in reference to Earth
>>  or any other astronomical object.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/
>> 
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-netmod-geo-location-06.html
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-geo-location-06
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> 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
>> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-geo-location-06.txt

[Christian Hopps]

This update addresses a few remaining nits identified during WGLC.

Thanks,
Chris.


> On Dec 2, 2020, at 6:27 AM, internet-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  : Christian Hopps
>   Filename: draft-ietf-netmod-geo-location-06.txt
>   Pages   : 25
>   Date: 2020-12-02
> 
> Abstract:
>   This document defines a generic geographical location object YANG
>   grouping.  The geographical location grouping is intended to be used
>   in YANG models for specifying a location on or in reference to Earth
>   or any other astronomical object.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-netmod-geo-location-06.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-geo-location-06
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> 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
> 



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-geo-location-05.txt

[Christian Hopps]

https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/ 
<https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/>

indicates status is Revised ID needed which I believe was addressed by the 
below publication.

Thanks,
Chris.

> On Jul 29, 2020, at 6:37 AM, internet-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  : Christian Hopps
>   Filename: draft-ietf-netmod-geo-location-05.txt
>   Pages   : 25
>   Date: 2020-07-29
> 
> Abstract:
>   This document defines a generic geographical location object YANG
>   grouping.  The geographical location grouping is intended to be used
>   in YANG models for specifying a location on or in reference to the
>   Earth or any other astronomical object.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-netmod-geo-location-05
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-geo-location-05
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-geo-location-05
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> 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
> 



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, yang:country-code

[Christian Hopps]

The point of the grouping is to not cut corners, and that it was vetted by 
experts in the field. Just re-using some typedefs of lat/long/height is not 
sufficient. You must also talk about the reference system which defines the 
meaning of those values, and know what you are talking about. It matters. 
Providing typedef's would suggest that it was OK to just re-use those values 
alone, when in fact it is not. If you read through the document you will see 
comparisons to other geographic location specifications. None of them just 
define "lat/long" as decimal degrees and call it done, as that is not 
sufficient.

Why shouldn't the grouping be used as is here? Nothing says that the software 
has to support every possible variation of data. Yes, the grouping allows 
specifying many types of coordinates (e.g., on the Moon), but that does not 
mean that the software that uses the grouping has to actually support those 
inputs.

In fact, If you look at the case we are talking about here, there's not only no 
reason to be limiting the geo-location, it's literally the use-case that drove 
me to create the grouping and its generality (i.e., locating network elements 
for a telecom and its management system).

Thanks,
Chris.

> On Jul 30, 2020, at 9:32 PM, Qin Wu  wrote:
> 
> Thanks Chris and Jurgen for clarification,
> Chris, I am not sure I catch what you said. Does adding new typedef for 
> longtitude and latitude do harm to draft-ietf-netmod-geo-location-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>>
> 抄送: Christian Hopps mailto:cho...@chopps.org>>; Qin Wu 
> mailto:bill...@huawei.com>>; netmod@ietf.org 
> <mailto:netmod@ietf.org>; netmod-cha...@ietf.org 
> <mailto:netmod-cha...@ietf.org>
> 主题: Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, 
> yang:country-code
> 
> 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 
>  <mailto:j.schoenwael...@jacobs-university.de>> wrote:
> 
> Looking in the I-Ds, I see that draft-ietf-netmod-geo-location-05
> defines a grouping geo-location. draft-ietf-teas-yang-te-topo-22
> has:
> 
>  +--ro geolocation
> +--ro altitude?int64
> +--ro latitude?geographic-coordinate-degree
> +--ro longitude?   geographic-coordinate-degree
> 
> You might simply use the grouping here that comes out of
> draft-ietf-netmod-geo-location-05 - but then the grouping is
> also a bit more complex than what you have.
> 
> Unfortunately, draft-ietf-netmod-geo-location-05 does not define
> helper types. The latitude and longitude leafs are simply decimal64s
> with all details spelled out inline:
> 
> leaf latitude {
>   type decimal64 {
> fraction-digits 16;
>   }
>   units "decimal degrees";
>   description
> "The latitude value on the astronomical body. The
>  definition and precision of this measurement is
>  indicated by the reference-frame value.";
> }
> leaf longitude {
>   type decimal64 {
> fraction-digits 16;
>   }
>   units "decimal degrees";
>   description
> "The longitude value on the astronomical body. The
>  definition and precision of this measurement is
>  indicated by the reference-frame.";
> }
> 
> The teas document has
> 
> typedef geographic-coordinate-degree {
> type decimal64 {
>   fraction-digits 8;
> }
> description
>   "Decimal degree (DD) used to express latitude and longitude
>geographic coordinates.";
> }
> 
> leaf latitude {
>   type geographic-coordinate-degree {
> range "-90..90";
>   }
>   description
> "Relative position north or south on the Earth's surface.";
> }
> 
> leaf longitude {
>   type geographic-coordinate-degree {
> range "-180..180";
>   }
>   description
> "Angular distance east or west on the Earth's surface.";
>  

Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, yang:country-code

[Christian Hopps]

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:
> 
> Looking in the I-Ds, I see that draft-ietf-netmod-geo-location-05
> defines a grouping geo-location. draft-ietf-teas-yang-te-topo-22
> has:
> 
>  +--ro geolocation
> +--ro altitude?int64
> +--ro latitude?geographic-coordinate-degree
> +--ro longitude?   geographic-coordinate-degree
> 
> You might simply use the grouping here that comes out of
> draft-ietf-netmod-geo-location-05 - but then the grouping is
> also a bit more complex than what you have.
> 
> Unfortunately, draft-ietf-netmod-geo-location-05 does not define
> helper types. The latitude and longitude leafs are simply decimal64s
> with all details spelled out inline:
> 
> leaf latitude {
>   type decimal64 {
> fraction-digits 16;
>   }
>   units "decimal degrees";
>   description
> "The latitude value on the astronomical body. The
>  definition and precision of this measurement is
>  indicated by the reference-frame value.";
> }
> leaf longitude {
>   type decimal64 {
> fraction-digits 16;
>   }
>   units "decimal degrees";
>   description
> "The longitude value on the astronomical body. The
>  definition and precision of this measurement is
>  indicated by the reference-frame.";
> }
> 
> The teas document has
> 
> typedef geographic-coordinate-degree {
> type decimal64 {
>   fraction-digits 8;
> }
> description
>   "Decimal degree (DD) used to express latitude and longitude
>geographic coordinates.";
> }
> 
> leaf latitude {
>   type geographic-coordinate-degree {
> range "-90..90";
>   }
>   description
> "Relative position north or south on the Earth's surface.";
> }
> 
> leaf longitude {
>   type geographic-coordinate-degree {
> range "-180..180";
>   }
>   description
> "Angular distance east or west on the Earth's surface.";
> }
> 
> Note also the differences in the precision. Obviously,
> draft-ietf-netmod-geo-location-05 could have defined
> helper types like
> 
>typedef latitude {
>  type decimal64 {
>  fraction-digits 16;
>  }
>  units "decimal degrees";
>  description
> "The latitude value on the astronomical body.";
>}
> 
>typdef longitude {
>  type decimal64 {
>  fraction-digits 16;
>  }
>  units "decimal degrees";
>  description
>"The longitude value on the astronomical body. The
> definition and precision of this measurement is
> indicated by the reference-frame.";
>}
> 
> and a bunch more and used them to define the leafs. These types could
> then have been reused in situations where the grouping in all its
> details is not needed.
> 
> I am not entirely sure where draft-ietf-netmod-geo-location-05 is in
> the WG process, the datatracker says "In WG Last Call, Revised I-D
> Needed - Issue raised by WGLC" - so perhaps there is a chance to get
> the inline type definitions factored out so that they can be reused.
> 
> I think this is something where the input from Chris Hopps and the
> NETMOD chairs is important to determine the path forward. Since we
> have an ietf-geo-location module, I would prefer to have common types
> for location information defined there and not in yang-types.
> 
> /js
> 
> On Thu, Jul 30, 2020 at 04:02:51PM +0200, Juergen Schoenwaelder wrote:
>> But then perhaps draft-ietf-netmod-geo-location-05 needs to be updated
>> or you need to use a grouping. I think we should not have overlapping
>> work in different documents.
>> 
>> /js
>> 
>> On Thu, Jul 30, 2020 at 01:54:43PM +, Qin Wu wrote:
>>> That is a good option, but draft-ietf-netmod-geo-location-05 only define 
>>> grouping, there is typedef for longitude and latitude, altitude.
>>> 
>>> -Qin
>>> -邮件原件-
>>> 发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
>>> 发送时间: 2020年7月30日 21:32
>>> 收件人: Qin Wu 
>>> 抄送: netmod@ietf.org
>>> 主题: Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, 
>>> yang:postal-code, yang:country-code
>>> 
>>> But there is draft-ietf-netmod-geo-location-05... What about using the 
>>> types defined in there?
>>> 
>>> /js
>>> 
>>> On Thu, Jul 30, 2020 at 01:28:17PM +, Qin Wu wrote:
 See geolocation definition in draft-ietf-teas-yang-te-topo-22 which 
 defines longitude and latitude, altitude.
 I know it is beneficial for future document to 

Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?

[Christian Hopps]

> 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"
>> 
>> use
>> 
>>"type string { pattern '[0-9]+(\.[0-9]+)?'; }"
>> 
> 
> And then everybody implements what he/she likes? That would be a big
> step backward since every implementation will then interpret the
> numbers differently.

I dislike having to specify arbitrary limits b/c of the type. I think it would 
be useful to have integer and real number support that allowed for specifying 
"at least" precision, but not forcing the model to specify an "at most".

In generally I dislike many of the specified semantic restrictions I find in 
YANG models, they seem to be the most oft-cited examples of when a "backward 
incompatible" change might need to be made to a model.

BTW, I think decimal64 is fine for this use-case, I mainly asked on the list 
b/c I'm curious about the more general use-case.

Thanks,
Chris.

> 
> /js
> 
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>
> 



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?

[Christian Hopps]

> 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 what 'strings' are here.

Mentioned in the earlier mail

instead of

"decimal64"

use

"type string { pattern '[0-9]+(\.[0-9]+)?'; }"

> In the xml and json encodings, everything finally has a string
> representation. But what matters is how the strings are interpreted
> since computers internally often do not use strings when it comes to
> numbers or addresses or ...

But they can operate with arbitrarily precise numbers (e.g., python mpmath, or 
even decimal with some arbitrarily large precision specified).

Thanks,
Chris.

> 
> /js
> 
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>
> 



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Justification for decimal64 over string for floating point values in geo location data?

[Christian Hopps]

> On Jul 7, 2020, at 7:24 AM, Juergen Schoenwaelder 
>  wrote:
> 
> Precision often means different things to different people. Here is my
> take:
> 
> - Floating point numbers have almost always rounding errors. And
>  floating point numbers use binary fractions, a decimal fraction like
>  1.0 has no precise representation as a binary fraction. Type 0.1 +
>  0.2 into python or haskell or any other language that gives you bare
>  floating point numbers and enjoy the result.
> 
> - Fixed precision decimal numbers do not have rounding errors since
>  they are essentially scaled integers and hence they are precise as
>  long as calculations stay within the range.
> 
> - Floating point numbers can cover a large number space (from very
>  tiny to really big), fixed precision decimal numbers are much more
>  restrictive.
> 
> - In XML and JSON, numbers are rendered in strings that likely do not
>  look much different if its a decimal64 or a float or ... If you really
>  care about size, use a binary encoding like CBOR.

So do you think it's enough to just use decimal64, and not justify it's use 
over strings? I don't necessarily think we need to talk to it in the document, 
but it was raised in the review so I figured some discussion on the list was at 
least merited.

While I haven't done any binary stuff with YANG, I think it's definitely usable 
that way (e.g., to define binary APIs in software where 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 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 
>> lost when converting from other geo location formats that use string (or 
>> double for w3c) to decimal64. Given that mention of loss of extreme 
>> precision, the reviewer was asking if some justification for the decimal64 
>> should be given in the document.
>> 
>> What are the advantages to using decimal64 for floating point numbers vs 
>> using a string with a pattern "[0-9]+(\.[0-9]+)?" (convert that to yang 
>> pattern language). The advantage of using a string is that the precision of 
>> the value is not restricted by the model. Does the YANG decimal64 values 
>> have a concise binary format that can be more efficiently transported or 
>> stored in binary form? If so is this the only advantage, and is it enough of 
>> one to limit the precision in the model?
>> 
>> It's definitely worth noting that the precision of the decimal64 values seem 
>> vastly adequate for geo location data (e.g., for Cartesian coordinates and 
>> height values which are measured in meters the fractional digits is 6 which 
>> means the surface could be up to 9 billion kilometers large (or away from 
>> for height) and the precision is to the micrometer. For ellipsoidal 
>> coordinates there are 12 fractional digits for the degrees.
>> 
>> Thanks,
>> Chris.
> 
> 
> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>
> 



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Justification for decimal64 over string for floating point values in geo location data?

[Christian Hopps]

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 
lost when converting from other geo location formats that use string (or double 
for w3c) to decimal64. Given that mention of loss of extreme precision, the 
reviewer was asking if some justification for the decimal64 should be given in 
the document.

What are the advantages to using decimal64 for floating point numbers vs using 
a string with a pattern "[0-9]+(\.[0-9]+)?" (convert that to yang pattern 
language). The advantage of using a string is that the precision of the value 
is not restricted by the model. Does the YANG decimal64 values have a concise 
binary format that can be more efficiently transported or stored in binary 
form? If so is this the only advantage, and is it enough of one to limit the 
precision in the model?

It's definitely worth noting that the precision of the decimal64 values seem 
vastly adequate for geo location data (e.g., for Cartesian coordinates and 
height values which are measured in meters the fractional digits is 6 which 
means the surface could be up to 9 billion kilometers large (or away from for 
height) and the precision is to the micrometer. For ellipsoidal coordinates 
there are 12 fractional digits for the degrees.

Thanks,
Chris.


signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG action not allowed at root?

[Christian Hopps]

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 for the same thing, 
right? Having 2 ways to do the same thing wouldn't help make servers easier to 
implement (it would do the opposite actually).

Thanks,
Chris.

> On Apr 30, 2020, at 11:50 AM, Sterne, Jason (Nokia - CA/Ottawa) 
>  wrote:
> 
> Yes - the intent was to address the limitation that an RPC can only be at 
> root. Actions can be out in a tree & nicely associated with something (e.g. 
> instead of having a pile of flat RPCs with long names that encode containers 
> like reset-www-xxx-yyy-zzz-entity).
>  
> But I don't really understand why we limited actions from being at the root. 
> It prevents a strategy of implementing all operations in a server (some of 
> which may be desirable at root for various reasons, some of which may be 
> desirable in the tree) as actions.
>  
> Why not allow this?
>  
>module bar {
>  action do-stuff {
>input {
>  leaf iterations {
>type uint8;
>   }
> }
>  } 
>} 
>} 
>  
> Which could be called from NETCONF like this:
>  
> xmlns="urn:ietf:params:xml:ns:netconf:base:1..0">
>
>  
>5
>  
>
>  
>  
>  
> Jason
>  
> From: Reshad Rahman (rrahman)  
> Sent: Thursday, April 30, 2020 11:31 AM
> To: Sterne, Jason (Nokia - CA/Ottawa) ; 
> netmod@ietf.org
> Subject: Re: [netmod] YANG action not allowed at root?
>  
> I don’t know the history on this but the intent is to have action tied to a 
> data node.
>  
> https://tools.ietf.org/html/rfc7950#section-7.15
>The difference between an action and an rpc is that an action is tied
>to a node in the datastore, whereas an rpc is not.  When an action is
>invoked, the node in the datastore is specified along with the name
>of the action and the input parameters.
>  
> Regards,
> Reshad.
>  
> From: netmod  on behalf of "Sterne, Jason (Nokia - 
> CA/Ottawa)" 
> Date: Thursday, April 30, 2020 at 11:08 AM
> To: "netmod@ietf.org" 
> Subject: [netmod] YANG action not allowed at root?
>  
> Hi all,
>  
> I was a bit surprised to find this in section 7.15 of 7950 recently:
>  
>Since an action cannot be defined at the top level of a module or in
>a "case" statement, it is an error if a grouping that contains an
>action at the top of its node hierarchy is used at the top level of a
>module or in a case definition.
>  
> I realize that actions can be placed down in a schema tree (i.e. sit in the 
> context of a container or list), but why is it phrased that they *must* be in 
> a container?
>  
> RPCs are limited to being at the root. I would have thought actions could be 
> anywhere (root or down in the tree).
>  
> Jason
>  
>  
> ___
> 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] WGLC: draft-ietf-netmod-geo-location-04

[Christian Hopps]

> 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 creating an IANA registry for the values in geodetic-system though so 
> perhaps you are asking for an IANA reference instead? I don't see 4 more 
> obvious places for external references, could you help point them out?
>  A good starting point is any reference in the body of the I-D should be 
> in the YANG module too in a reference clause, such as www.iau.org, IS6709, 
> WGS84 and may be more than once for different description clauses.  velocity 
> could include the formula or refer back to RFC perhaps timestamp too.  
> RFC8344 has enough (but not too many IMHO).

I'll go through the doc, and see what else I might could add. A couple points 
in the meantime though...

Some of these references (non-normative) in the document are for the 
comparisons to other work, and they point at other outside normative 
definitions for similar objects. I think it would be wrong to put references in 
the YANG module that point away from the definitive work (this document) and 
towards some other normative standard.

For velocity, referring back to the RFC that defines the module within 
sub-statements of the module seems rather redundant. The reference at the top 
of the module is the default reference for the module, if one starts adding the 
same reference to module sub-statements where does it end?

Other than that, I'll comb through again to look for normative references that 
aren't yet in the module, and also address your other concerns in a follow up 
version of the document.

Thanks for the review and comments!

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

Re: [netmod] WGLC: draft-ietf-netmod-geo-location-04

[Christian Hopps]

> 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 grouping modules 
> such as Kent's do)

I've pinged Kent for a pointer.

> No YANG version

This means it defaults to 1.0 I thought.

> Wrong prefix for ietf-yang-types

Will change the groupings use from "types" to "yang".

> No reference clause for yang types

Do you mean inside the import ietf-yang-types statement?

> 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 creating an IANA registry for the values in geodetic-system though so 
perhaps you are asking for an IANA reference instead? I don't see 4 more 
obvious places for external references, could you help point them out?

> No Normative reference for yang-types

We add normative document references for imported modules that are not 
mentioned anywhere else in the actual document? I have no problem doing so, but 
I haven't done that before.

> Insufficient information for IANA - I infer they are being asked to create a 
> registry but details seem lacking compared to the requirements in RFC8126

Thanks for pointing this out, I'll add this instead of waiting for IANA to 
complain. :)

Thanks,
Chris.

> 
> At which point I stop and await a fresh revision before having another go.
> 
> Tom Petch
> 
> 
> From: netmod  on behalf of Kent Watsen 
> 
> Sent: 26 March 2020 18:46
> 
> 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 April 2nd).
> 
> Again, positive comments, e.g., "I've reviewed this document and believe it 
> is ready for publication", are welcomed.  This is useful and important, even 
> from authors.  Objections, concerns, and suggestions are also welcomed at 
> this time.
> 
> FWIW, the YANG Doctor review was completed on 3/23 (thanks Mahesh) with the 
> “Ready with Nits” status: 
> https://datatracker.ietf.org/doc/review-ietf-netmod-geo-location-04-yangdoctors-lc-jethanandani-2020-03-23.
> 
> Kent // as shepherd and co-chair
> 
> 
> 
> On Mar 9, 2020, at 6:30 PM, Kent Watsen 
> mailto:kent+i...@watsen.net>> wrote:
> 
> This message begins an almost two-week WGLC for 
> draft-ietf-netmod-geo-location-04 ending on March 22nd (the day before the 
> NETMOD sessions).  Here is a direct link to the HTML version of the draft:
> 
> https://tools.ietf.org/html/draft-ietf-netmod-geo-location-04
> 
> Positive comments, e.g., "I've reviewed this document and believe it is ready 
> for publication", are welcome!  This is useful and important, even from 
> authors. Objections, concerns, and suggestions are also welcomed at this time.
> 
> Thank you,
> NETMOD Chairs
> 
> ___
> 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

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

Re: [netmod] WGLC: draft-ietf-netmod-geo-location-04

[Christian Hopps]

> 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 April 2nd). 
>  
> 
> Again, positive comments, e.g., "I've reviewed this document and believe it 
> is ready for publication", are welcomed.  This is useful and important, even 
> from authors.  Objections, concerns, and suggestions are also welcomed at 
> this time.

Well OK.

As author, I support this work. It has undergone multiple reviews, and 
revisiions, and I think it's ready to ship.

It was well supported during the adoption call, maybe it's covid getting in the 
way of things.

Thanks,
Chris.

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

Re: [netmod] Regarding IPR on draft-ietf-netmod-geo-location-04

[Christian Hopps]

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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Update on https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/

[Christian Hopps]

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.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[Christian Hopps]

> 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: ...
>>>> BTW, I did look at the "SHOULD be avoided" (occurs twice that I saw) once 
>>>> dealing with LFs and CRs which lucky for us is not part of a tags 
>>>> allowable characters. 
>>> There are lots of other things that complicate life. The Yang string 
>>> definition circumscribes some of them, but not all.
>>>> " typedef tag { type string { length "1..max"; pattern '[\S ]+'; } " 
>>> This pattern doesn't make sense to me when I try to understand it using 
>>> https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#charcter-classes It 
>>> excludes "symbols", but permits, for example, paragraph separators and 
>>> formatting characters and such delights as zero-width non-joiner. Also, in 
>>> complementing the "all symbols" category, it seems to me it already permits 
>>> space, so I don't see why it calls out space again. 
>> The intent was to have the pattern match the description immediately below 
>> it: "A tag value is composed of a standard prefix followed by any type 
>> 'string' value that does not include carriage return, newline or tab 
>> characters." Does this pattern fail in doing that?
> 
> Yes, what it accomplishes does not match the stated intent.

I'm finding this hard to believe looking at the definition of "\S" which is 
"everything but space, tab, newline and carriage return" and then adding 
"space". Seems to match the definition unless we quibble over the prefix (which 
I don't think we are).

> I suspect you may have intended something like '[\Z ]+'
> See https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#charcter-classes

I don't think that's a valid pattern.

If you are talking about the property categories (where I see 'Z' mentioned as 
"All separators") then there doesn't appear to be a "lower means include, upper 
means exclude" relationship. Also it appears that to refer to one of these 
things the syntax is actually "\P{Z}" or "\p{Z}" not just "Z". So translating 
maybe that's "[\P{Z} ]"? I see nothing that defines how "catEsc" (\p{}) vs 
"compEsc" (\P{}) are different, but maybe the upper here means exclude.

I'm more inclined to just ditch any pattern or restriction the more this gets 
discussed. Let the user do what they want. If they want to include crazy 
unicode stuff (almost certainly they dont) then I guess that's what they want.

Thanks,
Chris.

> 
> Randy
> 
> ___
> 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] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[Christian Hopps]

> 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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[Christian Hopps]

> 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 lucky for us is not part of a tags allowable 
> > characters.
> 
> There are lots of other things that complicate life.  The Yang string 
> definition
> circumscribes some of them, but not all.
> 
>> "
>>  typedef tag {
>>type string {
>>  length "1..max";
>>  pattern '[\S ]+';
>>}
>> "
> 
> This pattern doesn't make sense to me when I try to understand it using
> https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#charcter-classes
> It excludes "symbols", but permits, for example, paragraph separators and
> formatting characters and such delights as zero-width non-joiner. Also, in
> complementing the "all symbols" category, it seems to me it already permits
> space, so I don't see why it calls out space again.

The intent was to have the pattern match the description immediately below it:

"A tag value is composed of a standard prefix followed by any type 'string' 
value that does not include carriage return, newline or tab characters."

Does this pattern fail in doing that?

If this requires anymore work to get right then I think we should drop the 
pattern, as this isn't the document to come up with a better way to deal with 
the apparent ugliness of UTF strings in YANG. The overriding intent is to leave 
it to the users to decide what they want to put in there.

Thanks,
Chris.

> Randy
> 
> ___
> 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] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[Christian Hopps]

> On Feb 17, 2020, at 9:07 AM, Rob Wilton (rwilton)  wrote:
> 
> Hi Juergen,
> 
> Please see inline ...
> 
>> -Original Message-
>> From: Schönwälder, Jürgen 
>> Sent: 14 February 2020 14:31
>> To: Rob Wilton (rwilton) 
>> Cc: Alexey 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:
>> 
>> a) If we need normalized strings (to avoid comparison suprises), we
>>   should have a common type for them; rfc6991-bis would be a proper
>>   home. I am _not_ saying we should delay the tags document for this,
>>   but we should think about providing a solution that can be easily
>>   reused. Right now, we often use strings as part of keys, which can
>>   lead to comparison issues.
> [RW] 
> 
> I agree.  Note, I am also not proposing that we delay module-tags for 
> rfc6991-bis.
> 
> RFC 7950 states that strings are not normalized by default (section 9.4.2).  
> Thinking about this some more, I think that it is reasonable to make it the 
> client's responsibility to normalize strings, if required.
> 
> Chris, this would mean that no change to the typedef description is required.
> 
>> 
>> b) It seems that normalized strings only solve part of the problem. If
>>   an organization creates names for 'things', the organization likely
>>   wants to further restrict the format of these names to something
>>   sensible to avoid fun with different kinds of hyphens or emojis or
>>   ... So while creative unicode characters may technically work,
>>   there will likely be good reasons to avoid some of them. (There are
>>   reasons why we have coding styles for most programming languages.)
>>   These rules may, however, differ between organizations.
>> 
>> We should not confuse a) and b). If IANA needs additional guidelines for
>> tags (their coding style for tags), then we should provide these
>> guidelines, i.e., this is a type b) action. The type a) action is needed
>> to technically ensure that comparisons do not lead to surprises. But a)
>> won't be an answer for all type b) issues. Of course, we could give IANA a
>> 'coding style' that avoids any normalization issues. This would make IANA
>> assigned tags safe but would not avoid comparison surprises for other
>> sources of tags.
> [RW] 
> 
> So, solving B seems reasonable for the IANA defined module tags, following 
> Alexey's suggestion of referencing RFC 5198 for normalization.

I will not put the additional text in the typedef and instead put it in the 
guidance for the IANA registry then:

 This registry allocates tags that have the registered prefix
 "ietf:". New values should be well considered and not achievable
-through a combination of already existing IETF tags.
+through a combination of already existing IETF tags. For comparing
+non-ascii strings, 'NFC' [[RFC5198]] normalization SHOULD be used.

Unless there are further objections, I believe this, and a small change to the 
security section suggested by Benjamin K, will clear the remaining DISCUSS so I 
will republish soon.

Thanks,
Chris.

> Thanks,
> Rob
> 
> 
>> 
>> /js
>> 
>> On Fri, Feb 14, 2020 at 10:30:50AM +, Rob Wilton (rwilton) wrote:
>>> Hi Juergen,
>>> 
>>> This sounds potentially useful to me, although should this be for
>> general unicode strings (e.g. ones that might include spaces), or just
>> identifiers (without any spaces)?.  Is this something that could/should go
>> into rfc6991-bis, or at least be discussed in that context?
>>> 
>>> I would have thought that normalization would be required wherever a
>> configurable unicode string is used as a list key, or leaf-list.
>>> 
>>> Thanks,
>>> Rob
>>> 
>>> 
>>>> -Original Message-
>>>> From: iesg  On Behalf Of Schönwälder, Jürgen
>>>> Sent: 13 February 2020 18:39
>>>> To: Alexey Melnikov 
>>>> Cc: netmod-cha...@ietf.org; draft-ietf-netmod-module-t...@ietf.org;
>>>> 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)
>>>> 
>>>> And a longer term solution might be to define a YANG Net-Unicode
>>>> string datatype that can be used in all situations where
>>>> non-normalized strings may cause problems. 

Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[Christian Hopps]

> 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 tag is a type 'string' value that does not include carriage
>>   return, newline or tab characters. It SHOULD begin with a
>>   registered prefix; however, tags without 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";
>>  }
>> 
> 
> There are other considerations beyond normalization form.
> For the tip of the iceberg, see the definition of SnmpAdminString
> in RFC 3411, or the "SHOULD be avoided" stuff in RFC 5198.

Do you think that the above is appropriate to include, or should be left out as 
doing more harm than helping?

BTW, I did look at the "SHOULD be avoided" (occurs twice that I saw) once 
dealing with LFs and CRs which lucky for us is not part of a tags allowable 
characters.

"
 typedef tag {
   type string {
 length "1..max";
 pattern '[\S ]+';
   }
"

The other is about private use unicode, and I don't know anything about that.

I think we either include the diff quoted above, or do nothing, as this isn't 
the document, as we all seem to agree, to fix the larger unicode issues with 
YANG string type.

Thanks,
Chris.

> 
> For things like tags where one would like to minimize accidental
> visual punning, I'd suggest NFKC should probably be given some
> consideration.   Excellent presentation of the issues is
> available at https://unicode.org/reports/tr15/
> 
> That said, these are issues that were raised in the earliest days of Netmod /
> Netconf, and no one should be surprised that they haven't gone away by
> themselves.  So I find my self in ironic agreement with Andy that it doesn't
> make sense to wait for / impose a global solution, because there's plenty
> of evidence that having all sorts of ill-defined cases of questionable
> interoperability in theory hasn't been sufficient to prevent adoption of
> the technology.
> 
> Randy
> 
> ___
> 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] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[Christian Hopps]

How about I add this to the description of "typedef tag" in the module:

   description
 "A tag is a type 'string' value that does not include carriage
  return, newline or tab characters. It SHOULD begin with a
  registered prefix; however, tags without 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  wrote:
> 
> 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 
>> completed?
>> 
>> Thanks,
>> Chris.
>> 
>>> On Feb 14, 2020, at 5:43 AM, Rob Wilton (rwilton)  wrote:
>>> 
>>> Hi Alexey, Christian, 
>>> 
>>> Allowing Unicode but requiring normalization as per RFC 5198 for IANA 
>>> managed tags makes sense to me.
>>> 
>>> But does the server also need to normalize any configured tags?  I.e. 
>>> should the description for the tag typedef also specify that tags SHOULD be 
>>> normalized, and specify a normalization 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
>>>> Sent: 13 February 2020 13:10
>>>> To: Christian Hopps 
>>>> Cc: netmod-cha...@ietf.org; Joel Jaeggli ; The IESG
>>>> ; netmod@ietf.org; draft-ietf-netmod-module-t...@ietf.org
>>>> Subject: Re: Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-
>>>> 07: (with DISCUSS)
>>>> 
>>>> 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 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. :)
>>>> 
>>>> And the problem with that is that because there might be multiple ways to
>>>> encode in Unicode visually indistinguishable tags IANA would end up asking
>>>> IESG for help.
>>>> 
>>>> So you need to at minimum specify a Unicode normalization form to use. I
>>>> suggest you normatively reference RFC 5198 here.
>>>> 
>>>>> Having worked for a company where a lot of XML string data was
>>>>> non-ascii I find limiting to ascii to be rather restrictive.
>>>> 
>>>> Best Regards,
>>>> Alexey
>>>> 
>>>>> 
>>>>> Thanks,
>>>>> Chris.
>>>>> 
>>>>>> On Apr 11, 2019, at 9:41 AM, Alexey Melnikov via Datatracker
>>>>  wrote:
>>>>>> 
>>>>>> Alexey Melnikov 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:
>>>>>> 
>>>>>> --
>>>>>> 
>>>>>> This is generally a fine document, but after checking RFC 7950
>>>>>> syntax for strings I question why you think you need non ASCII tags.
>>>>>> There are so many problems that can arise from that. For example,
>>>>>> how would IANA be able to enforce uniqueness of Unicode tags written
>>>>>> in different Unicode canonicalisation forms?
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>> 
>> 
> 

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

Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[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 
> completed?
> 
> Thanks,
> Chris.
> 
>> On Feb 14, 2020, at 5:43 AM, Rob Wilton (rwilton)  wrote:
>> 
>> Hi Alexey, Christian, 
>> 
>> Allowing Unicode but requiring normalization as per RFC 5198 for IANA 
>> managed tags makes sense to me.
>> 
>> But does the server also need to normalize any configured tags?  I.e. should 
>> the description for the tag typedef also specify that tags SHOULD be 
>> normalized, and specify a normalization 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
>>> Sent: 13 February 2020 13:10
>>> To: Christian Hopps 
>>> Cc: netmod-cha...@ietf.org; Joel Jaeggli ; The IESG
>>> ; netmod@ietf.org; draft-ietf-netmod-module-t...@ietf.org
>>> Subject: Re: Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-
>>> 07: (with DISCUSS)
>>> 
>>> 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 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. :)
>>> 
>>> And the problem with that is that because there might be multiple ways to
>>> encode in Unicode visually indistinguishable tags IANA would end up asking
>>> IESG for help.
>>> 
>>> So you need to at minimum specify a Unicode normalization form to use. I
>>> suggest you normatively reference RFC 5198 here.
>>> 
>>>> Having worked for a company where a lot of XML string data was
>>>> non-ascii I find limiting to ascii to be rather restrictive.
>>> 
>>> Best Regards,
>>> Alexey
>>> 
>>>> 
>>>> Thanks,
>>>> Chris.
>>>> 
>>>>> On Apr 11, 2019, at 9:41 AM, Alexey Melnikov via Datatracker
>>>  wrote:
>>>>> 
>>>>> Alexey Melnikov 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:
>>>>> 
>>>>> --
>>>>> 
>>>>> This is generally a fine document, but after checking RFC 7950
>>>>> syntax for strings I question why you think you need non ASCII tags.
>>>>> There are so many problems that can arise from that. For example,
>>>>> how would IANA be able to enforce uniqueness of Unicode tags written
>>>>> in different Unicode canonicalisation forms?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>> 
> 

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

Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[Christian Hopps]

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 completed?

Thanks,
Chris.

> On Feb 14, 2020, at 5:43 AM, Rob Wilton (rwilton)  wrote:
> 
> Hi Alexey, Christian, 
> 
> Allowing Unicode but requiring normalization as per RFC 5198 for IANA managed 
> tags makes sense to me.
> 
> But does the server also need to normalize any configured tags?  I.e. should 
> the description for the tag typedef also specify that tags SHOULD be 
> normalized, and specify a normalization 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
>> Sent: 13 February 2020 13:10
>> To: Christian Hopps 
>> Cc: netmod-cha...@ietf.org; Joel Jaeggli ; The IESG
>> ; netmod@ietf.org; draft-ietf-netmod-module-t...@ietf.org
>> Subject: Re: Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-
>> 07: (with DISCUSS)
>> 
>> 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 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. :)
>> 
>> And the problem with that is that because there might be multiple ways to
>> encode in Unicode visually indistinguishable tags IANA would end up asking
>> IESG for help.
>> 
>> So you need to at minimum specify a Unicode normalization form to use. I
>> suggest you normatively reference RFC 5198 here.
>> 
>>> Having worked for a company where a lot of XML string data was
>>> non-ascii I find limiting to ascii to be rather restrictive.
>> 
>> Best Regards,
>> Alexey
>> 
>>> 
>>> Thanks,
>>> Chris.
>>> 
>>>> On Apr 11, 2019, at 9:41 AM, Alexey Melnikov via Datatracker
>>  wrote:
>>>> 
>>>> Alexey Melnikov 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:
>>>> 
>>>> --
>>>> 
>>>> This is generally a fine document, but after checking RFC 7950
>>>> syntax for strings I question why you think you need non ASCII tags.
>>>> There are so many problems that can arise from that. For example,
>>>> how would IANA be able to enforce uniqueness of Unicode tags written
>>>> in different Unicode canonicalisation forms?
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
> 

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

Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[Christian Hopps]

> 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 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. :)
> 
> And the problem with that is that because there might be multiple ways to 
> encode in Unicode visually indistinguishable tags IANA would end up asking 
> IESG for help.

I don't have a problem including some text in the IANA guidance if we need it; 
however, the guidance already says:

  "New values should be well considered and not achievable through a
   combination of already existing IETF tags."

How could we arrive at a place where IANA is confused about allowing 2 visually 
indistinguishable strings given the above statement? The registry already 
requires IETF review, and it seems counter to the existing IANA guidance to 
even be talking about distinguishing visually indistinguishable tag values. IOW 
simply by talking about the need to compare 2 strings that are visually 
indistinguishable, we diminish the much more important intent of the initial 
guidance.

Thanks,
Chris.

> 
> So you need to at minimum specify a Unicode normalization form to use. I 
> suggest you normatively reference RFC 5198 here.
> 
>> Having worked for a company where a lot of XML string data was 
>> non-ascii I find limiting to ascii to be rather restrictive.
> 
> Best Regards,
> Alexey
> 
>> 
>> Thanks,
>> Chris.
>> 
>>> On Apr 11, 2019, at 9:41 AM, Alexey Melnikov via Datatracker 
>>>  wrote:
>>> 
>>> Alexey Melnikov 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:
>>> --
>>> 
>>> This is generally a fine document, but after checking RFC 7950 syntax for
>>> strings I question why you think you need non ASCII tags. There are so many
>>> problems that can arise from that. For example, how would IANA be able to
>>> enforce uniqueness of Unicode tags written in different Unicode
>>> canonicalisation forms?
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 

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

Re: [netmod] Alexey Melnikov's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS)

[Christian Hopps]

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. :)

Having worked for a company where a lot of XML string data was non-ascii I find 
limiting to ascii to be rather restrictive.

Thanks,
Chris.

> On Apr 11, 2019, at 9:41 AM, Alexey Melnikov via Datatracker 
>  wrote:
> 
> Alexey Melnikov 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:
> --
> 
> This is generally a fine document, but after checking RFC 7950 syntax for
> strings I question why you think you need non ASCII tags. There are so many
> problems that can arise from that. For example, how would IANA be able to
> enforce uniqueness of Unicode tags written in different Unicode
> canonicalisation forms?
> 
> 
> 
> 

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

Re: [netmod] ID submission YANG validation errors?

[Christian Hopps]

I've sent some mail previously to random lists (codesprint, xml2rfc..) and 
Henrik, but I've not heard back. Does anyone know what the official path to 
reporting problems with the yang validation setup is?

Thanks,
Chris.

> On Jan 22, 2020, at 5:29 PM, Mahesh Jethanandani  
> 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-metric/
>> 
>> It's saying it can't find the ietf-isis module. Has anyone else experienced 
>> this issue with referencing draft modules? It seems broken that we can't 
>> refer to works-in-progress, inside our works-in-progress.
> 
> Yes, I experience this error all the time. In this case I am referencing 
> published IEEE models in YangModels GitHub location. If my local validation 
> passes, I just ignore these errors:
> 
> yanglint 0.14.80: yanglint --verbose -p {rfclib} -p {draftlib} -p {tmplib} 
> {model} -i:
> err : Data model "ieee802-dot1q-types" not found.
> err : Importing "ieee802-dot1q-types" module into "ietf-if-l3-vlan" failed.
> err : Module "ietf-if-l3-vlan" parsing failed.
> err : Importing "ietf-if-l3-vlan" module into "ietf-routing-policy" failed.
> err : Module "ietf-routing-policy" parsing failed.
> err : Importing "ietf-routing-policy" module into "ietf-bgp" failed.
> err : Module "ietf-bgp" parsing failed.
> 
> 
>> 
>> Thanks,
>> Chris.
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> Mahesh Jethanandani
> mjethanand...@gmail.com
> 
> 
> 

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

[netmod] ID submission YANG validation errors?

[Christian Hopps]

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? It seems broken that we can't refer 
to works-in-progress, inside our works-in-progress.

Thanks,
Chris.


signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] References to the "tags" typedef

[Christian Hopps]

> 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)
>> ; netmod@ietf.org
>> Subject: Re: [netmod] References to the "tags" typedef
>> 
>> 
>> 
>>> On Oct 3, 2019, at 2:34 PM, Mahesh Jethanandani
>>  wrote:
>>> 
>>> 
>>> 
>>>> On Oct 3, 2019, at 2:37 AM, Rob Wilton (rwilton) 
>> wrote:
>>>> 
>>>> Hi Chris,
>>>> 
>>>> I know that this is late, but ...
>>>> 
>>>> The YANG packages draft (https://tools.ietf.org/html/draft-rwilton-
>> netmod-yang-packages-01, but an updated version will be posted soon), is
>> currently using the module-tags typedef to allow a package definition to
>> contain a list of tags.
>>>> 
>>>> E.g.
>>>> module: ietf-yang-package
>>>> +--ro yang-package
>>>>+--ro name  yang:yang-identifier
>>>>+--ro version   yang-sem-ver
>>>>+--ro revision-date?yanglib:revision-identifier
>>>>+--ro location* inet:uri
>>>>+--ro description?  string
>>>>+--ro reference?string
>>>>+--ro previous-version? yang-sem-ver
>>>>+--ro tag*  tags:tag
>>>>+--ro referentially-complete?   Boolean
>>>>...
>>>> 
>>>> This package definition goes into an instance data document, for which
>> the schema should just be ietf-yang-package, but by it importing ietf-
>> module-tags.yang, it effectively also pulls in the "container module-tags"
>> into the schema for the package definition, that I don't think should be
>> there.
>>>> 
>>>> If we keep package tags, then I think that there are two ways to fix
>> this:
>>>> 
>>>> (1) Split ietf-module-tags into an ietf-module-tags-types.yang and a
>> ietf-module-tags.yang.  But it would be very late to do this, and the
>> packages draft isn't even a workgroup document at this stage.
>>> 
>>> I know it is late. But what will it take to split the tags-types module
>> from the tags module?
>> 
>> I do not understand why this is important at all. What does "pulls in"
>> exactly mean?
> 
> To put YANG instance data into a document you need to know what the schema is 
> associated with the instance data.
> 
> Ideally, I want the schema for a YANG package instance data document to just 
> be the ro yang-package structure described above (actually now defined using 
> YANG data extension from draft-ietf-netmod-yang-data-ext).
> 
> To use the "tags:tag" typedef, ietf-yang-package had an import on 
> "ietf-module-tags" which both defines a tags type and also a "module-tags" 
> container as well.  I want the typedef, but not the container, because I 
> don't want the schema for the package file to be:
>  +--ro yang-package  <-- I do want this
>  |  +--ro name  yang:yang-identifier
>  |  ...
>  +--ro module-tags   <--  I don't want this
> +- ...
> 
> There are a few solutions:
> 
> 1) Split ietf-module-tags into a ietf-module-tags-types.yang that only 
> defines the typedef and the extension, and hence the ietf-module-tags.yang 
> only defines the module-tags container, and ietf-yang-packages.yang can just 
> import ietf-module-tags-types.yang
> 2) Have ietf-yang-package.yang define its own "tags" type, hence there is no 
> dependency on "ietf-module-tags.yang" at all.
> 3) Tweak the schema specification for simplified-inline-schema in 
> instance-data documents so that the use of ietf-module-tags.yang module 
> effectively becomes "import-only" rather than "implemented".

If there's a problem here it doesn't seem to be with module tags, but more 
generically with this "pulling in" issue you have with instance data documents. 
Are we now going to require *all* YANG types be defined in their own modules so 
their re-use in instance data documents doesn't "pull in" the other stuff? Are 
we going to go back and revise and republish all current YANG modules splitting 
them up this way?

Thanks,
Chris.



> 4) Don't worry about the fact that the file schema for a YANG package 
> contains more than it sh

Re: [netmod] References to the "tags" typedef

[Christian Hopps]

> On Oct 3, 2019, at 2:34 PM, Mahesh Jethanandani  
> wrote:
> 
> 
> 
>> On Oct 3, 2019, at 2:37 AM, Rob Wilton (rwilton)  wrote:
>> 
>> Hi Chris,
>> 
>> I know that this is late, but ...
>> 
>> The YANG packages draft 
>> (https://tools.ietf.org/html/draft-rwilton-netmod-yang-packages-01, but an 
>> updated version will be posted soon), is currently using the module-tags 
>> typedef to allow a package definition to contain a list of tags.
>> 
>> E.g.
>> module: ietf-yang-package
>>  +--ro yang-package
>> +--ro name  yang:yang-identifier
>> +--ro version   yang-sem-ver
>> +--ro revision-date?yanglib:revision-identifier
>> +--ro location* inet:uri
>> +--ro description?  string
>> +--ro reference?string
>> +--ro previous-version? yang-sem-ver
>> +--ro tag*  tags:tag
>> +--ro referentially-complete?   Boolean
>> ...
>> 
>> This package definition goes into an instance data document, for which the 
>> schema should just be ietf-yang-package, but by it importing 
>> ietf-module-tags.yang, it effectively also pulls in the "container 
>> module-tags" into the schema for the package definition, that I don't think 
>> should be there.
>> 
>> If we keep package tags, then I think that there are two ways to fix this:
>> 
>> (1) Split ietf-module-tags into an ietf-module-tags-types.yang and a 
>> ietf-module-tags.yang.  But it would be very late to do this, and the 
>> packages draft isn't even a workgroup document at this stage.
> 
> I know it is late. But what will it take to split the tags-types module from 
> the tags module?

I do not understand why this is important at all. What does "pulls in" exactly 
mean?

Thanks,
Chris.

> 
>> 
>> (2) Have the package draft define its own "package tag" typedef, and not 
>> have an import reference on module-tags at all.  Probably if we do keep 
>> package tags, then we should also consider a mechanism by which they can be 
>> 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
>> 
>> 
>> 
>>> -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-module-tags-09.txt
>>> 
>>> This adds the deprecated non-NMDA state module.
>>> 
>>> Thanks,
>>> Chris.
>>> 
>>>> On Sep 25, 2019, at 12:15 PM, internet-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   : YANG Module Tags
>>>>  Authors : Christian Hopps
>>>>Lou Berger
>>>>Dean Bogdanovic
>>>>Filename: draft-ietf-netmod-module-tags-09.txt
>>>>Pages   : 18
>>>>Date: 2019-09-25
>>>> 
>>>> Abstract:
>>>> This document provides for the association of tags with YANG modules.
>>>> The expectation is for such tags to be used to help classify and
>>>> organize modules.  A method for defining, reading and writing a
>>>> modules tags is provided.  Tags may be registered and assigned during
>>>> module definition; assigned by implementations; or dynamically
>>>> defined and set by users.  This document also provides guidance to
>>>> future model writers; as such, this document updates RFC8407.
>>>> 
>>>> 
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/
>>>> 
>>>> There are also htmlized versions available at:
>>>> https://tools.ietf.org/html/draft-ietf-netmod-module-tags-09
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-module-tags-09
>>>> 
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-09
>>>> 
>>>> 
>>>> Please note that it may take a couple of minutes from the time of
>>>> submission until the htmlized version and diff are available at
>>> tools.ietf.org.
>>>> 
>>>> 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 mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> Mahesh Jethanandani
> mjethanand...@gmail.com



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-module-tags-09.txt

[Christian Hopps]

> 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: Re: [netmod] I-D Action: draft-ietf-netmod-module-tags-09.txt
>> 
>> [resending to include list cc]
>> 
>>> On Oct 3, 2019, at 5:45 AM, Rob Wilton (rwilton) 
>> wrote:
>>> 
>>> Hi Chris,
>>> 
>>> As discussed offline, you have left out the "masked-tag" container in
>> the "modules-tags-state" module.
>> 
>> One might read this as an objection that was discussed offline, but I
>> don't think you are objecting, you're just stating what happened, correct?
> 
> Correct, not objecting, although I might be about to 
> 
> Generally, I think that is what is available in "module-tags-state" should be 
> directly equivalent to what is available in the operational datastore for 
> servers that support NMDA.

So is this how we're supposed to construct these deprecated state modules, just 
copy all config true and config false nodes into a new module and mark them all 
config false? If so fine. I will do that.

Thanks,
Chris.



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-module-tags-09.txt

[Christian Hopps]

[resending to include list cc]

> On Oct 3, 2019, at 5:45 AM, Rob Wilton (rwilton)  wrote:
> 
> Hi Chris,
> 
> As discussed offline, you have left out the "masked-tag" container in the 
> "modules-tags-state" module.

One might read this as an objection that was discussed offline, but I don't 
think you are objecting, you're just stating what happened, correct?

> For consistently, I wonder, whether there shouldn't also be a comment in the 
> "masked-tag" leaf-list in the main NMDA compatible module to indicate that 
> "masked-tag" isn't reported in the operational state datastore because the 
> information is combined into the "tag" leaf-list.

Ok, color me confused. For NMDA, why wouldn't masked-tag show up in operational 
datastore? Isn't the operational datastore the union of the applied intended 
config (config true nodes) plus the config false nodes?

Non-NMDA has no concept of "applied" (operational state of config true nodes), 
that is why masked-tags don't go in the module-tags-state container. The user 
can still read the configured masked-tag value on the normal non-deprecated 
module 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-module-tags-09.txt
>> 
>> This adds the deprecated non-NMDA state module.
>> 
>> Thanks,
>> Chris.
>> 
>>> On Sep 25, 2019, at 12:15 PM, internet-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   : YANG Module Tags
>>>   Authors : Christian Hopps
>>> Lou Berger
>>> Dean Bogdanovic
>>> Filename: draft-ietf-netmod-module-tags-09.txt
>>> Pages   : 18
>>> Date: 2019-09-25
>>> 
>>> Abstract:
>>>  This document provides for the association of tags with YANG modules.
>>>  The expectation is for such tags to be used to help classify and
>>>  organize modules.  A method for defining, reading and writing a
>>>  modules tags is provided.  Tags may be registered and assigned during
>>>  module definition; assigned by implementations; or dynamically
>>>  defined and set by users.  This document also provides guidance to
>>>  future model writers; as such, this document updates RFC8407.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/
>>> 
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-netmod-module-tags-09
>>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-module-tags-09
>>> 
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-09
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of
>>> submission until the htmlized version and diff are available at
>> tools.ietf.org.
>>> 
>>> 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
>>> 
> 



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-module-tags-09.txt

[Christian Hopps]

This adds the deprecated non-NMDA state module.

Thanks,
Chris.

> On Sep 25, 2019, at 12:15 PM, internet-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   : YANG Module Tags
>Authors : Christian Hopps
>  Lou Berger
>  Dean Bogdanovic
>   Filename: draft-ietf-netmod-module-tags-09.txt
>   Pages   : 18
>   Date: 2019-09-25
> 
> Abstract:
>   This document provides for the association of tags with YANG modules.
>   The expectation is for such tags to be used to help classify and
>   organize modules.  A method for defining, reading and writing a
>   modules tags is provided.  Tags may be registered and assigned during
>   module definition; assigned by implementations; or dynamically
>   defined and set by users.  This document also provides guidance to
>   future model writers; as such, this document updates RFC8407.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-netmod-module-tags-09
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-module-tags-09
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-09
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> 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
> 



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-module-tags needs a correction

[Christian Hopps]

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 seems wiser to pull it back and add that rather than
> proceed forward with the document as is.
> 
> Thanks
> 
> joel
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] ?= ?==?utf-8?q? mandatory choice with non-presence container cas

[Christian Hopps]

> 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 NP-container text is unclear.
>> 
>> This issue IMO has more to do with the "mandatory" statement under
>> "choice". Similar problems can be caused by data nodes that depend on
>> "when". For example:
>> 
>> choice sel {
>>   madatory true;
>>   leaf foo {
>>   when "...";
>>   ...
>>   }
>>   leaf bar { ... }
>>   leaf baz { ... }
>> 
>> If "foo" exists in instance data but its when condition becomes false,
>> the server is expected to remove the "foo" instance, but what next?
>> The data becomes invalid, but the server can hardly include "bar" or
>> "baz" on its own.
> 
> Right, so that change (that would make the when condition false) will
> be rejected by the server, since the resulting config would be
> invalid.

This is subtle, I wonder if it is called out somewhere for YANG module 
implementers? Basically what the above means (assuming a module sw design) is 
that prior to *any change anywhere in the system* the server software 
(probably) needs to re-run validation on the entire resulting config to make 
sure that the config will still be valid, prior to making the change.

The sort of obvious place this would happen is having baseline software that 
does not know about (has no code written for) some new feature that is added 
later by the vendor/user. This new sw has some when's in it that refer back to 
the baseline sw.

Thanks,
Chris.

> 
> 
> /martin
> 
> 
> 
> 
>> 
>> Lada
>> 
>>> I'm unsure if you saw the thread in NETCONF, but I filed this issue
>>> over the weekend.  Please add to it, if only to include a link to this
>>> thread: https://github.com/netmod-wg/yang-next/issues/88. Thanks, Kent
>>> ___ netmod mailing list
>>> netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
>> 
>> --
>> Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
>> 
>> ___
>> 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



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-geo-location-01: an optional location info

[Christian Hopps]

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 an object). I'll remove the mandatory from location.

Thanks,
Chris.

> On Jul 11, 2019, at 9:54 AM, Jan Kundrát  wrote:
> 
>> The "location" choice is defined as mandatory, so an instance of one of the 
>> cases must be present. I don't know whether it is necessary or not, but you 
>> can avoid it easily by overriding the definition:
> 
> Thanks for explaining this. I'll leave it to the draft authors to evaluate 
> whether an optional geolocation makes more sense than a hard-coded one.
> 
> Diky
> Honza K.
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] convert it and not throw an error was Re: 6021 ipv4-prefix

[Christian Hopps]

> 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 wrote:
>>> 
 Where is the text that tells the server implementor whether to
> throw an
 error when client commits non-zero bits, or to just throw the bits
> away
 and store the value in the canonical format?
>>> 
>>> Such text would be an inappropriate constraint the server's
>>> internal representation.  We should only specify
>>> the externally-visible behaviour: that the reported value
>>> will be in the canonical format.  Whether an implementation
>>> preserves extraneous cruft in its internal representation is
>>> purely an implementation decision, and not subject to
> standardization.
>> 
>> I am talking about what goes on the wire. If the client does an
>> edit-config with ipv6-prefix 2001:db8::1/64, should the server convert
>> this into 2001:db8::/64 or throw an error on the edit-config
> operation.
>> 
>> Jurgen seems to say it should convert it and not throw an error, and
> I'd
>> like text to say that indeed, this is proper behaviour. Nobody has so
> far
>> been able to tell me where this text currently is, so that's why I'm
>> asking for it to be added. Either this should go into an update to
>> https://tools.ietf.org/html/rfc7950#section-9.1 or it should go into
> each
>> and every definition of types (or both of them).
> 
> Mikael
> 
> How about RFC791, still much quoted in all aspects of the work of the
> IETF?
> 
> " In general, an implementation must be conservative
>  in its sending behavior, and liberal in its receiving behavior.  That
>  is, it must be careful to send well-formed datagrams, but must accept
>  any datagram that it can interpret (e.g., not object to technical
>  errors where the meaning is still clear)."
> 
> We did not have MUST in those days, but had we, this would have been one
> IMHO.


So, this is a good opportunity to mention what has bothered me during this 
discussion.

Let's for a moment leave aside the "standards language" etc part, and instead 
consider "What's actually useful for people who try and run networks."

NETCONF and YANG have the concept of validating configuration, this is very 
useful for users. In a previous job I incorrectly started out to use 
ipv4-prefix in a model where I really wanted an ipv4-address-and-prefix (i.e., 
an interface context). Now consider the reverse case then where the model 
really expects a prefix only, and the user for some reason thinks it will 
accept and can make use of an "address-and-prefix". The most obvious indication 
that the user has got this wrong is that they have host bits set. So if the 
server accepts the value but silently discards the host bits the error is not 
caught and the user and server probably have different ideas about what's going 
to happen.

IOW, I don't think "where the meaning is still clear" applies to stripping host 
bits from a value, in fact I think it's more clear that stripping the host bits 
is actually ignoring (getting wrong) the user intent.

Thanks,
Chris.

> 
> Tom Petch



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Alvaro Retana's No Objection on draft-ietf-netmod-module-tags-07: (with COMMENT)

[Christian Hopps]

> 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 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:
> --
> 
> (1) Along the same lines of Alissa's DISCUSS, which I support.
> 
> §6.1: "For standardized modules new tags MUST be assigned in the IANA registry
> defined below, see Section 7.2."  What is a "standardized module"?  It sounds
> like a Standards Track document, but (as Alissa pointed out) the registration
> policy is only IETF Review.

In addressing the other DISCUSS/COMMENTs almost all (but not all) use of the 
word "standard tag"/"standardized tag" has switched to some variant of 
"registered tag". That said, the intention here is what you read: it's saying 
if you are defining a module in a standard's track document then any new tags 
you create MUST be added to the IANA registry. This doesn't contradict the IANA 
registry policy of IETF review (i.e., it's not talking about or trying to 
constrain the registration policy). Consider a case of a info doc that is 
documenting some odd or misuse of tags, we don't want to require that this doc 
register the "odd" or misused case in the registry -- it could, but it's not 
required.

> 
> (2) §7.1: "All YANG module tags SHOULD begin with one of the prefixes in this
> registry."  That statement along with the text in §2.4:
> 
>   Any tag not starting with the prefix "ietf:", "vendor:" or "user:" is
>   reserved for future standardization.  These tag values are not
>   invalid, but simply reserved in the context of standardization.
> 
> ...seem to indicate that a tag with any format can be used.  Is that true?  Is
> that the intent?  If so, then it seems to me that vendor/user tags could 
> simply
> forgo the standardized prefix.  I guess this is ok...it just makes me wonder
> about the need to even define those prefixes.

The document goes to some length to make sure that users can do whatever they 
want as they should be the final arbiter (that philosophy). The need for the 
standard prefixes is to provide a stable framework so that if users choose to 
follow the prefix rules (i.e., use "user:") then they won't get stepped on by 
upstream (design and vendor) uses.

> (3) I'm not sure what, but I think it may be wise to give the would-be DEs for
> the new registry in §7.1 some more guidance on the allocation of new prefixes.
> The only current guidance is this: "Prefix entries in this registry should be
> short strings consisting of lowercase ASCII alpha-numeric characters and a
> final ":" character."

The expected use case (and thus the "guidance"):

"
   Other standards organizations (SDOs) wishing to allocate their own
   set of tags should allocate a prefix from this registry.
"

Perhaps you think this needs wordsmithing though?

Thanks,
Chris.



signature.asc
Description: Message signed with OpenPGP
___
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)

[Christian Hopps]

> 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.

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

> --
> 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.

Chris.



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



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 6991bis: address-with-prefix-length

[Christian Hopps]

> On Apr 2, 2019, at 22:16, Alex Campbell  wrote:
> 
> I don't think this is joining an address with a prefix - this is joining an 
> address with a prefix *length*.
> If it was two separate values, it would still be constraining the address to 
> be covered by the prefix, since there would be no way to define a prefix that 
> the address didn't cover.

It is joining the two things as far as what data it *represents* (i.e., how it 
can be used). You are correct if we are just talking about the physical bits 
being stored, but semantics count. Otherwise I think you are agreeing with me 
that by representing the 2 values this way it necessarily constrains their 
values the way we want it to.

Thanks,
Chris.

> 
> Also a distinction from ipv4-prefix is that an ipv4-prefix is completely 
> meaningless if either part is removed, whereas an 
> ip-address-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.org
> Subject: Re: [netmod] 6991bis: address-with-prefix-length
> 
>> 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 pointed out there is already
>>> a type for that.
>>> 
>>> I think that we need to choose this name very carefully or otherwise I
>>> suspect that folks will accidentally use the wrong type.
>>> 
>>> So having the type as "ip-address-and-prefix-length" or
>>> "ip-addr-and-prefix-len" now seems like a clearer choice to me.
>> 
>> The combined type really specifies (i) an ip address and (ii) an ip
>> prefix.  The prefix happens to be specified with a length indicator.
>> So I think the name "ip-address-and-prefix" is the correct one.
>> 
>>> I
>>> think that I also now agree with Martin that this is really merging
>>> two values into one leaf.
>> 
>> And for the record (again, perhaps), I think this is a bad idea in
>> general, and I am not sure an exception is needed in this case.
> 
> (Again :) this is not just joining two values, it is also constraining the 
> address value to be a value covered by the prefix. The common use case is for 
> interface state where the interface has an address which should be within the 
> prefix assigned to the network the interface attaches to.
> 
> This isn't just about saving space.
> 
> I also agree that "-and-" is a really good idea, saving a few characters in 
> an identifier when doing so has shown to cause the identifier to be 
> misunderstood is not an optimization IMO.
> 
> Thanks,
> Chris.
> 
>> 
>> 
>> /martin
>> 
>> 
>>> Where is this type going to be used?  Is it only used for configuring
>>> host address/prefix?  Or are there other uses cases as well?
>>> 
>>> Thanks,
>>> Rob
>>> 
>>> 
>>>> -Original Message-
>>>> From: Acee Lindem (acee) 
>>>> Sent: 02 April 2019 16:52
>>>> To: Rob Wilton (rwilton) ; Martin Bjorklund
>>>> >>> f.com>; j.schoenwael...@jacobs-university.de
>>>> Cc: netmod@ietf.org
>>>> Subject: Re: [netmod] 6991bis: address-with-prefix-length
>>>> 
>>>> Hi Rob,
>>>> 
>>>> On 4/2/19, 11:37 AM, "netmod on behalf of Rob Wilton (rwilton)"
>>>> >>> boun...@ietf.org on behalf of rwil...@cisco.com> wrote:
>>>> 
>>>> 
>>>> 
>>>>> -Original Message-
>>>>> From: netmod  On Behalf Of Martin
>>>> Bjorklund
>>>>> Sent: 02 April 2019 13:47
>>>>> To: j.schoenwael...@jacobs-university.de
>>>>> Cc: netmod@ietf.org
>>>>> Subject: Re: [netmod] 6991bis: address-with-prefix-length
>>>>> 
>>>>> Juergen Schoenwaelder  wrote:
>>>>>> If you go back ~20 messages, my proposal was ip-address-prefix,
>>>>>> ipv4-address-prefix, and ipv6-address-prefix.
>>>>> 
>>>>> Do we agree that this type really specifies two values in one?  If so
>>>>> I think
>>>> the
>>>>> "and&q

Re: [netmod] 6991bis: address-with-prefix-length

[Christian Hopps]

> 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 pointed out there is already
>> a type for that.
>> 
>> I think that we need to choose this name very carefully or otherwise I
>> suspect that folks will accidentally use the wrong type.
>> 
>> So having the type as "ip-address-and-prefix-length" or
>> "ip-addr-and-prefix-len" now seems like a clearer choice to me.
> 
> The combined type really specifies (i) an ip address and (ii) an ip
> prefix.  The prefix happens to be specified with a length indicator.
> So I think the name "ip-address-and-prefix" is the correct one.
> 
>> I
>> think that I also now agree with Martin that this is really merging
>> two values into one leaf.
> 
> And for the record (again, perhaps), I think this is a bad idea in
> general, and I am not sure an exception is needed in this case.

(Again :) this is not just joining two values, it is also constraining the 
address value to be a value covered by the prefix. The common use case is for 
interface state where the interface has an address which should be within the 
prefix assigned to the network the interface attaches to.

This isn't just about saving space.

I also agree that "-and-" is a really good idea, saving a few characters in an 
identifier when doing so has shown to cause the identifier to be misunderstood 
is not an optimization IMO.

Thanks,
Chris.

> 
> 
> /martin
> 
> 
>> Where is this type going to be used?  Is it only used for configuring
>> host address/prefix?  Or are there other uses cases as well?
>> 
>> Thanks,
>> Rob
>> 
>> 
>>> -Original Message-
>>> From: Acee Lindem (acee) 
>>> Sent: 02 April 2019 16:52
>>> To: Rob Wilton (rwilton) ; Martin Bjorklund
>>> >> f.com>; j.schoenwael...@jacobs-university.de
>>> Cc: netmod@ietf.org
>>> Subject: Re: [netmod] 6991bis: address-with-prefix-length
>>> 
>>> Hi Rob,
>>> 
>>> On 4/2/19, 11:37 AM, "netmod on behalf of Rob Wilton (rwilton)"
>>> >> boun...@ietf.org on behalf of rwil...@cisco.com> wrote:
>>> 
>>> 
>>> 
 -Original Message-
 From: netmod  On Behalf Of Martin
>>> Bjorklund
 Sent: 02 April 2019 13:47
 To: j.schoenwael...@jacobs-university.de
 Cc: netmod@ietf.org
 Subject: Re: [netmod] 6991bis: address-with-prefix-length
 
 Juergen Schoenwaelder  wrote:
> If you go back ~20 messages, my proposal was ip-address-prefix,
> ipv4-address-prefix, and ipv6-address-prefix.
 
 Do we agree that this type really specifies two values in one?  If so
 I think
>>> the
 "and" is useful.
>>> 
>>>Isn't an "IP prefix" made up of an "IP address" and a "prefix length"?
>>> 
>>> This was my confusion as well since the ipv4-prefix and ipv6-prefix
>>> types
>>> (ietf-inet-types) have been used when they probably shouldn't have
>>> been.
>>> Note that they both have the constraint of not allowing the host bits
>>> to be set
>>> should they should be used in situations like interface address
>>> assignment.
>>> 
>>> Excerpted from RFC6991 ipv4-type definition (note the last sentence):
>>> description
>>>"The ipv4-prefix type represents an IPv4 address prefix.
>>> The prefix length is given by the number following the
>>> slash character and must be less than or equal to 32.
>>> 
>>> A prefix length value of n corresponds to an IP address
>>> mask that has n contiguous 1-bits from the most
>>> significant bit (MSB) and all other bits set to 0.
>>> 
>>> The canonical format of an IPv4 prefix has all bits of
>>> the IPv4 address set to zero that are not part of the
>>> IPv4 prefix.";
>>> 
>>>So, I think that the names above are probably right, or otherwise if
>>>you
>>> want the "and" then perhaps it should be
>>> "ip-address-and-prefix-length" -
>>> which seems clunky?
>>> 
>>> I think the original suggestion of ipxx-address-prefix would be ok.
>>> 
>>> Thanks,
>>> Acee
>>> 
>>>Thanks,
>>>Rob
>>> 
>>> 
 
 Also note that the current text in RFC 6991 says:
 
 The ipv4-prefix type represents an IPv4 address prefix.
 
 so having a type ipv4-address-prefix for something that is not (only)
 an
 "ipv4 address prefix" is imo confusing.
 
 
 /martin
 
 
 
 
> 
> /js
> 
> On Tue, Apr 02, 2019 at 11:13:09AM +, tom petch wrote:
>> - Original Message -
>> From: "Jeff Tantsura" 
>> To: ; "Kristian Larsson" 
>> Sent: Monday, April 01, 2019 11:09 PM
>> 
>> What Kristian has proposed makes sense, in favor.
>> 
>> 
>> 
>> Yes, I support this idea and we should be able to come up with a
>> more user-friendly name;  address-prefix or address-length ?
>> 
>> 

Re: [netmod] 6991bis: address-with-prefix-length

[Christian Hopps]

> 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 manual
> input, but I wonder if it really is good practice to squeeze two
> values into one.

This has value more than just convenience. In particular it captures and 
enforces the fact that the address has to be contained by the prefix (e.g., an 
interfaces address on the network it attaches to's prefix).

Thanks,
Chris.

> 
> 
> /martin
> 
> 
> "Acee Lindem (acee)"  wrote:
>> Ok, now I'm confused. I see that the ietf-inet-type model already has the 
>> types ipv4-prefix and ipv6-prefix. How are these any different???
>> Thanks,
>> Acee
>> 
>> On 4/1/19, 12:31 PM, "Acee Lindem (acee)"  wrote:
>> 
>>I believe the "address-" could be omitted from the type identifiers. At 
>> least within the routing area, "ipv4-prefix" is unambiguous.
>>Thanks,
>>Acee
>> 
>>On 4/1/19, 12:14 PM, "netmod on behalf of Juergen Schoenwaelder" 
>>  
>> wrote:
>> 
>>This is the right time for this and I would call these
>>ip-address-prefix, ipv4-address-prefix and ipv6-address
>>prefix.
>> 
>>/js
>> 
>>On Mon, Apr 01, 2019 at 04:38:34PM +0200, Kristian Larsson wrote:
>>> Hello,
>>> 
>>> seeing that 6991 is up for a refresh I wonder if this would be the time to
>>> suggest the addition of a type for address-and-prefix-length, for example
>>> like 192.0.2.1/24?
>>> 
>>> I find that it's the most natural way express the address and prefix-length
>>> to configure on an interface or for some other use. We currently have an
>>> ip-prefix type which allows CIDR style prefixes but since all bits to the
>>> right of the mask is to be 0 it is only possible to use for describing the
>>> IP prefix / network address itself - not the address of a host in that
>>> network.
>>> 
>>> I actually wish the interface-ip modules would have used a combined leaf for
>>> these settings rather than the dual-leaf approach it currently has, but I
>>> suppose that ship has sailed :/
>>> 
>>> Regardless, can we add such a type? Is this the document and time to do it?
>>> :)
>>> 
>>> Kind regard,
>>>   Kristian.
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>>--
>>Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>>Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>>Fax:   +49 421 200 3103 
>> 
>>___
>>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
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod



signature.asc
Description: Message signed with OpenPGP
___
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

[Christian Hopps]

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, 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




signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Comments on draft-ietf-netmod-module-tags-06//RE: Few Comments ////RE: Publication has been requested for draft-ietf-netmod-module-tags-04

[Christian Hopps]

Rohit R Ranade  writes:


Hi,

While looking at Section 3.1, it looks like this document does not mandate that 
all IETF drafts in future MUST have atleast one module-tag. Is this correct ? 
Or whether it is better that future IETF draft MUST/SHOULD have at least one 
IETF tag ?


Correct, we aren't mandating tag use.


Consider modules like "ietf-yang-types" and similar which provide common 
definitions, what will be the tags for such modules ?

Editorial:

Section 4.1
"If the module definition is IETF standards track, the tags MUST also
   be Section 2.1. " ==> s/ MUST also be Section 2.1. / MUST also adhere to 
Section 2.1./  ?


I corrected this based on the GenART review (the odd text was a tool use error 
on my part).

  "...
  If the module is defined in an IETF standards track document, the
  tags MUST be IETF Standard Tags (2.1).
  ..."

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; iesg-secret...@ietf.org; netmod@ietf.org
Subject: RE: [netmod] Few Comments //RE: Publication has been requested for 
draft-ietf-netmod-module-tags-04

Hi,

Please find inline.


-Original Message-
From: Christian Hopps [mailto:cho...@chopps.org]
Sent: 21 February 2019 13:54
To: Rohit R Ranade 
Cc: Christian Hopps ; Joel Jaeggli ; 
ibagd...@gmail.com; netmod-cha...@ietf.org; iesg-secret...@ietf.org; netmod@ietf.org
Subject: Re: [netmod] Few Comments //RE: Publication has been requested for 
draft-ietf-netmod-module-tags-04




On Feb 20, 2019, at 10:40 PM, Rohit R Ranade  wrote:

Hi Christian,

2 points are missing from the IANA registry, "Updates to the IETF XML Registry" and 
"Updates to the YANG Module Names Registry", you can refer to RFC 8342 section 8 for 
registering the new module and namespace.


Will add, thanks.


Also w.r.t "ietf:", whether we can make it "sdo:" and ask ietf modules to start their tags as 
"sdo:ietf:" , because all the other SDO will need to register their organization prefixes once with IANA. 
 This will also keep it at the same level where each vendor will also define his tags as 
"vendor:vendor-name:x" etc.


Since this isn't fixing something that's broken, and in fact is going against 
what was talked about and agreed to in the WG during the document development 
time, it's not an appropriate change to consider at this very late stage in the 
process.
[Rohit R Ranade] OK, If the WG has decided then I concede on this point.

Thanks,
Chris.



With Regards,
Rohit

-Original Message-
From: Christian Hopps [mailto:cho...@chopps.org]
Sent: 18 February 2019 14:57
To: Rohit R Ranade 
Cc: Christian Hopps ; Joel Jaeggli
; ibagd...@gmail.com; netmod-cha...@ietf.org;
iesg-secret...@ietf.org; netmod@ietf.org
Subject: Re: [netmod] Few Comments //RE: Publication has been
requested for draft-ietf-netmod-module-tags-04


Rohit R Ranade  writes:


Hi,

Thank you for accepting the comments. Few more comments from my side.

Technical:
1. Section 8.1, " could allocate a top level prefix ", I think there is no 
concept of top-level prefix now. I think this is a remnant of the versions posted earlier 
where you had examples of multiple prefixes in a tag. Can be removed now I think.


Indeed! I'll remove "top level", as there are no levels.


2. Why should the prefix contain ietf: , vendor:, user: ?  I think the second 
part of the prefix is more important for classification because most of the 
vendors / sdo already define their own prefixes for their module-name based on 
RFC7950 guideline in Section 5.1. By adding the prefix, I feel it will reduce 
the re-usability by other SDO / vendors.


Well the second part of the tag is the tag itself, the prefix is simply there 
to avoid collision between the module authors in various SDOs, the module 
implementers, and the module users.


3. Consider we have defined a module example-bgp which is similar to ietf-bgp.
If we need to add tags to example-bgp, then we need to define new "vendor:" 
prefixes for this even if it uses some IETF protocols ?


"ietf:" tags are allocated with IETF documents which is what the registry policy 
"IETF Review" indicates.

However, this is an allocation policy not a USE policy. As module designer you 
get to pick whatever tags you think apply (which is what section 4.1 says).


I think we need to add more clarity in this document as to when the "ietf:" 
prefix can be used by a module ? Whether a vendor module can/cannot use standard tags ?
Consider a module which has some part of vendor and some part of IETF protocol , whether 
vendor can use "ietf:" tags then ?
I suggest adding one more example in 

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

[Christian Hopps]

> On Mar 7, 2019, at 17:50, Elwyn Davies  wrote:
> 
> Hi, Christian.
> 
> Thanks for the quick response.
> 
> I understand your intent, but the intent and the specification appear to be 
> in conflict.
> 
> The pattern for tags is
>  pattern '[a-zA-Z_][a-zA-Z0-9-_]*:[S ]+';  
> 
> This REQUIRES two character strings separated by a colon unless I have 
> totally forgotten how to read such patterns. Thus all tags have a prefix of 
> the form [a-zA-Z_][a-zA-Z0-9-_]* and a part after the colon that is 
> essentially unconstrained.

Your right the pattern was wrong and needs to be fixed.

> S2 limits the values of the prefixes to those defined in the IANA registry of 
> s7.1.. Further the values of the second part are constrained by the s7.2 
> registry if the prefix is ietf:.
> 
> So, what should a YANG parser do when building datastores as per RFC 8342 if 
> a tag prefix is not one of the ones in the s7.1 registry? Likewise if the 
> prefix is ietf: and the whole tag is not in the s7.2 registry?

A YANG server should never place any restrictions on the tag values. There’s 
need for this limiting and well known justification not to (applying Postel’s 
Law/Robustness principle here).

> If you want to make the presence of the prefix a SHOULD then I think you need 
> to adapt the pattern to make the whole prefix part optional.  However that 
> doesn't get away from describing what the parser should do if it finds a 
> prefix it doesn't know about. 

Assuming the pattern is fixed, do we really have to call out the fact that 
something marked as a SHOULD should not be treated as a MUST? That seems like 
what your asking for, perhaps I’m missing the point though. Are you just asking 
for a blurb saying parsers must not restrict tag values? That seems like 
restating but if it moves things forward I’m amiable. :)

> Additionally, I am not clear how the parser knows which tags should be marked 
> as 'system' in the datastore as mentioned in the YANG module comments. 

B/c it (the server) put them there, not the user.

> Maybe it is that the ietf prefix and s7.2 value leads the tags to be marked 
> as system tags but what should happen if it isn't in the s7.2 list?  Should 
> the parser ignore such tags, throw a fault and refuse to parse the module or 
> maybe treat them as user tags even if they are ietf prefixed?  
> 
> Also if new prefixes are defined by other SDOs, as envisaged in the last 
> paragraph of s7.1, could or would these also be system tags?  Should there 
> then be a flag or value in the registry to flag that tags with this prefix 
> should be marked as system or otherwise?
> 
> Thus also brings up another issue for the s7.1 registry.  If another 
> organisation is defining a prefix there really need to be contact and 
> reference fields in the registry to specify the organisation maintaining this 
> prefix, especially if such a prefix had its own equivalent of the s7.2 
> registry, and the document that introduces the prefix.
> 
> I suggest the authors discuss the appropriate status for the three RFCs that 
> I suggested should be normative and you disagreed with your AD.  It is a 
> rather odd situation where a standards ltrack document is updating an 
> informational or BCP document, and also needing knowledge of items described 
> in BCPs.  With the revised policy on downrefs, this can be handled I believe.

We are updating the BCP guidelines (RFC8407) , but nothing is relying on them 
that I see. I would have thought text that updates informative text is treated 
as informative, this could be my ignorance showing.

RFC8340 being informative is what all the other yang documents (including RFCs) 
I’ve seen do as well.

RFC8199 is informative, the values 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.

> 
> Cheers,
> Elwyn
> 
> Sent from Samsung tablet.
> 
>  Original message 
> From: Christian Hopps 
> Date: 06/03/2019 22:55 (GMT+00:00)
> To: Elwyn Davies 
> Cc: gen-...@ietf.org, Christian Hopps , 
> draft-ietf-netmod-module-tags@ietf.org, "" 
> , netmod@ietf.org
> Subject: Re: [Gen-art] [netmod] Genart last call review of 
> draft-ietf-netmod-module-tags-06
> 
> [I covered this in the previous reply I just sent, and updated the model text 
> in response too..]
> 
> The intent here is to not restrict users of tags where we don't have to. The 
> prefix is only intended to avoid collision between disconnected groups 
> (designers, implementers and users), since users are the final gr

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

[Christian Hopps]

[to this thread in general, not anyone in particular]

We have done this work over 2 years in the working group. It has been presented 
multiple times with multiple revisions etc. We have arrived at a solution that 
works, and has cleared WG LC, and IETF LC.

We have a process we need to follow it. Yes if something is truly broken and 
has somehow escaped all the previous checks it needs to be addressed. But 
general musings about how one might do things a little different or a little 
better are not appropriate at this very late stage, otherwise we never get 
anything done.

Not getting things done in a timely manner has been a problem highlighted at 
least with the work in netmod if not the IETF in general, and has been the 
subject during many meetings at this point, on how to fix it. Endless 
revisionism is one of the major factors identified as a problem.

Can we please restrict discussions on this document to editorial/minor 
corrections or changes that have to be made b/c otherwise the solution will not 
work?

Thanks,
Chris.

> On Mar 7, 2019, at 18:40, Alex Campbell  wrote:
> 
> In that case, why not make it so the tags are actually valid URIs, similar to 
> XML namespaces?
> 
> From: netmod  on behalf of William Lupton 
> 
> Sent: Friday, 8 March 2019 7:37 a.m.
> To: Andy Bierman
> Cc: Datatracker on behalf of Elwyn Davies; IETF discussion list; NetMod WG; 
> General Area Review Team; draft-ietf-netmod-module-tags@ietf.org
> Subject: Re: [netmod] Genart last call review of 
> draft-ietf-netmod-module-tags-06
>  
> This remark might be out of context (I haven't been following the details) 
> but this reference to prefixes makes me wonder whether there's any way that 
> registered URN namespaces could be 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:
> 
> 
> On Wed, Mar 6, 2019 at 2:51 PM Christian Hopps  <mailto:cho...@chopps.org>> wrote:
> Thanks for the review! Comments inline.
> 
> > On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies 
> > mailto:ietf-secretariat-re...@ietf.org>> 
> > wrote:
> > 
> > Reviewer: Elwyn Davies
> > Review result: Almost Ready
> > 
> .
> > If I read correctly, the YANG definition in s4.2 REQUIRES that all tags 
> > have a
> > prefix.  For clarity, it would better if this read:
> >All tags MUST begin with a prefix; it is intended that this prefix SHOULD
> >   [or maybe 'should'] indicate
> >  the ownership or origination of the definition.
> 
> The intent was to not put the MUST on users. As the final arbiters of tags, 
> users should be free to do whatever they want and not have implementations or 
> standards superfluously block them from doing so. How about we carry the 
> SHOULD into the typedef in the YANG model as well? That seems reasonable to 
> me, i.e.,
> 
>   typedef tag {
> type string {
>   length "1..max";
>   pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+';
> }
> description
>   "A tag is a type 'string' value that does not include carriage
>return, newline or tab characters. It SHOULD begin with a
>standard prefix.";
> 
> 
> 
> 
> 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)
> 
> 
> Andy
> 
> > S2, para 1: s/yang type/YANG type/ (I think)
> > 
> > S2.2: s/follwing/following/
> > 
> > S3.1, para 2:
> > OLD:
> > If the module definition is IETF standards track, the tags MUST also be 
> > Section
> > 2.1. Thus, new modules can drive the addition of new standard tags to the 
> > IANA
> > registry, and the IANA registry can serve as a check against duplication.
> > 
> > NEW:
> > If the module is defined in an IETF standards track document, the tags MUST 
> > use
> > the prefix defined in Section 2.1. Thus, definitions of new modules can 
> > drive
> > the addition of new standard tags to the IANA registry defined in Section 
> > 7.2,
> > and the IANA registry can serve as a check against duplication.
> > 
> > ENDS
> > 
> > S3.2: s/standard/IETF Standard/
> > 
> > S3.3: It would be useful to introduce the term 'masking' used later in the 
> > YANG
> > module definition.
> 
> How about:
> 
> "Tags of any k

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

[Christian Hopps]

We already have a reviewed and approved prefixes registry.

Given nothing is broken here, and the current solution has been reviewed for 2+ 
years, and with careful consideration approved by the working group, this does 
not seem like change that should be considered (or perhaps even suggested) at 
this very late point in the process.

Thanks,
Chris.

Andy Bierman  writes:


On Thu, Mar 7, 2019 at 10:37 AM William Lupton 
wrote:


This remark might be out of context (I haven't been following the details)
but this reference to prefixes makes me wonder whether there's any way that
registered URN namespaces could be regarded as valid prefixes.
https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml




looks like a great solution and would be less duplication of registries

Andy






On Thu, 7 Mar 2019 at 18:28, Andy Bierman  wrote:




On Wed, Mar 6, 2019 at 2:51 PM 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 definition in s4.2 REQUIRES that all
tags have a
> prefix.  For clarity, it would better if this read:
>All tags MUST begin with a prefix; it is intended that this prefix
SHOULD
>   [or maybe 'should'] indicate
>  the ownership or origination of the definition.

The intent was to not put the MUST on users. As the final arbiters of
tags, users should be free to do whatever they want and not have
implementations or standards superfluously block them from doing so. How
about we carry the SHOULD into the typedef in the YANG model as well? That
seems reasonable to me, i.e.,

  typedef tag {
type string {
  length "1..max";
  pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+';
}
description
  "A tag is a type 'string' value that does not include carriage
   return, newline or tab characters. It SHOULD begin with a
   standard prefix.";





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)


Andy

> S2, para 1: s/yang type/YANG type/ (I think)

>
> S2.2: s/follwing/following/
>
> S3.1, para 2:
> OLD:
> If the module definition is IETF standards track, the tags MUST also
be Section
> 2.1. Thus, new modules can drive the addition of new standard tags to
the IANA
> registry, and the IANA registry can serve as a check against
duplication.
>
> NEW:
> If the module is defined in an IETF standards track document, the tags
MUST use
> the prefix defined in Section 2.1. Thus, definitions of new modules
can drive
> the addition of new standard tags to the IANA registry defined in
Section 7.2,
> and the IANA registry can serve as a check against duplication.
>
> ENDS
>
> S3.2: s/standard/IETF Standard/
>
> S3.3: It would be useful to introduce the term 'masking' used later in
the YANG
> module definition.

How about:

"Tags of any kind can be assigned and removed by the user using normal
configuration mechanisms. In order to remove a tag from the
operational datastore the user adds a matching =masked-tag= entry for
a given module."

> S4.1: I think this usage of RFC 8340 makes it normative.

Covered earlier (BCP).

> S4.2, extension module-tag definition: This should contain a pointer
to RFC
> 8342 which discusses the system origin concept.

Added.

Thanks,
Chris.

>
> Major issues:
>
> Minor issues:
>
> Nits/editorial comments:
>
>
> ___
> 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


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







signature.asc
Description: PGP signature
___
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

[Christian Hopps]

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 strong supporter of the included prefixes registry as 
well then. :)

Thanks,
Chris.




Andy


signature.asc
Description: PGP signature
___
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

[Christian Hopps]

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 documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-netmod-module-tags-06
> Reviewer: Elwyn Davies
> Review Date: 2019-03-05
> IETF LC End Date: 2019-03-03
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> Almost ready.  There are a couple of minor issues and a small number of nits.
> Apologies for the slightly late delivery of the review.
> 
> Major issues:
> None
> 
> 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.

> S4.2: using the Netmod working group as contact point for the module is not
> future proof.  I am  not sure what the correct contact ought to be: IESG?

Speaking of 8407 guidelines... It gives guidance here. I will follow it. :)

  "The "contact" statement MUST be present.  If the module is contained
   in a document intended for Standards Track status, then the WG web
   and mailing information SHOULD be present, and the main document
   author or editor contact information SHOULD be present."

> S7.2: [This is a thought that occurred to me...] ought there to be an ietf:
> security tag?

Yes, added.

> S9: I would consider RFCs 8199, 8340, 8342 and 8407 to be normative

8199: Informational
8340: BCP
8407: BCP

8342: Standard, and I think your right, moved to Normative.

> 
> Nits/editorial comments:
> Abstract: s/modules/module's/
> 
> Abstract:
> OLD:
> This document also provides guidance to future model writers, as such, this
> document updates RFC8407.
> 
> NEW:
> This document also provides guidance to future model writers; as such, this
> document updates RFC8407.
> 
> ENDS
> 
> S1.1, title: s/use cases of/use cases for/
> 
> S1.1, para 1: s/documents progression/document's development/
> 
> S1.1, paras 2, 3 and 5: Suggest s/E.g./For example/
> 
> S1.1, para 4: s/e.g./e.g.,/

Updated with your suggestions.

> S2, para 1:
>> All tags SHOULD begin with a prefix indicating who owns their definition.
> 
> If I read correctly, the YANG definition in s4.2 REQUIRES that all tags have a
> prefix.  For clarity, it would better if this read:
>All tags MUST begin with a prefix; it is intended that this prefix SHOULD
>   [or maybe 'should'] indicate
>  the ownership or origination of the definition.

The intent was to not put the MUST on users. As the final arbiters of tags, 
users should be free to do whatever they want and not have implementations or 
standards superfluously block them from doing so. How about we carry the SHOULD 
into the typedef in the YANG model as well? That seems reasonable to me, i.e.,

  typedef tag {
type string {
  length "1..max";
  pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+';
}
description
  "A tag is a type 'string' value that does not include carriage
   return, newline or tab characters. It SHOULD begin with a
   standard prefix.";

> S2, para 1: s/yang type/YANG type/ (I think)
> 
> S2.2: s/follwing/following/
> 
> S3.1, para 2:
> OLD:
> If the module definition is IETF standards track, the tags MUST also be 
> Section
> 2.1. Thus, new modules can drive the addition of new standard tags to the IANA
> registry, and the IANA registry can serve as a check against duplication.
> 
> NEW:
> If the module is defined in an IETF standards track document, the tags MUST 
> use
> the prefix defined in Section 2.1. Thus, definitions of new modules can drive
> the addition of new standard tags to the IANA registry defined in Section 7.2,
> and the IANA registry can serve as a check against duplication.
> 
> ENDS
> 
> S3.2: s/standard/IETF Standard/
> 
> S3.3: It would be useful to introduce the term 'masking' used later in the 
> YANG
> module definition.

How about:

"Tags of any kind can be assigned and removed by the user using normal
configuration mechanisms. In order to remove a tag from the
operational datastore the user adds a matching =masked-tag= entry for
a given module."

> S4.1: I think this usage of RFC 8340 makes it normative.

Covered earlier (BCP).

> S4.2, extension module-tag definition: This should contain a pointer to RFC
> 8342 which discusses the system origin concept.

Added.

Thanks,
Chris.

> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod



signature.asc
Description: Message signed with OpenPGP

Re: [netmod] I-D Action: draft-chopps-netmod-geo-location-00.txt

[Christian Hopps]

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. :)
> >
> > Printable ASCII characters are ' ' (space) through '~' (tilde) so
> > naively [
> > -~] should work ... but perhaps that makes unacceptable assumptions
> > -about
> > the locale and/or character encoding? (Certainly it should be OK if we
> > can
> > assume UTF-8, because all printable ASCII characters retain their
> > ASCII
> > representations in UTF-8.)
>
> I think your suggestion is a good one!

Not sure I get it.  What exactly is the suggestion?



Presumably the suggestion of using the [ -~] ("space through tilde")
closure. I forgot to include other whitespace characters (CR, LF, FF) so if
those are to be included it could be [\s!-~] ("whitespace plus exclamation
mark through tilde").



I mis-poke earlier, it's all printable lowercase ASCII.

I'm going to use the pattern: '[ -@\[-\^_-~]*'

These 3 ranges seem to make pyang happy. I don't know why I need to break up 
the second range into 2 adjacent ranges like that to make pyang not complain, 
but complain it does if I just use: '[ -@\[-~]*'

Thanks,
Chris.


signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-chopps-netmod-geo-location-00.txt

[Christian Hopps]

William Lupton  writes:


The intent was "ascii-printable". Would be nice if there was an easier

way to specify this. :)

Printable ASCII characters are ' ' (space) through '~' (tilde) so naively [
-~] should work ... but perhaps that makes unacceptable assumptions about
the locale and/or character encoding? (Certainly it should be OK if we can
assume UTF-8, because all printable ASCII characters retain their ASCII
representations in UTF-8.)


I think your suggestion is a good one!

YANG references <https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#dt-regex> says it 
will 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:



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
> should not have to be escaped.
>
> The pattern allows double quote (") but not single quote (').  Is
> that intentional?

The intent was "ascii-printable". Would be nice if there was an easier way
to specify this. :)

> [a simple way to test the patterns is to have a "default" statement
> and a YANG complier that verifies defaults]

Does pyang do this?

> I recommend that you rename the example module in section to
> "example-uses-geo-location" (and change the namespace to
> urn:example:uses-geo-location).   We should not use the "ietf"
> namespace for examples.

Will do.

Thanks,
Chris.

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





signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] New tool: Using Emacs Org Mode for writing RFCs

[Christian Hopps]

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 announce it's 
availability. Basically you write your RFC in Org Mode and export it to XML. 
The back-end supports exporting to XML (for manual xml2rfc), but also supports 
exporting to text, HTML, or PDF, including directly into a buffer for easy 
previewing.

Highlights:
- Powerful Org Mode
- Simple Citations/References.
- Lists (Numbered, Unnumbered)
- Definition Lists (term + definition)
- Tables
- Embedded Code (Literate Programming e.g., embed yang model, trees, examples)

In particular YANG embedding is pretty neat. There's no need for separate files 
and tree generation (and example validation) can be automated from the embedded 
text.

Check out the README and the examples (currently in the ert-tests directory).

Thanks,
Chris.


signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-chopps-netmod-geo-location-00.txt

[Christian Hopps]

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
should not have to be escaped.

The pattern allows double quote (") but not single quote (').  Is
that intentional?


The intent was "ascii-printable". Would be nice if there was an easier way to 
specify this. :)


[a simple way to test the patterns is to have a "default" statement
and a YANG complier that verifies defaults]


Does pyang do this?


I recommend that you rename the example module in section to
"example-uses-geo-location" (and change the namespace to
urn:example:uses-geo-location).   We should not use the "ietf"
namespace for examples.


Will do.

Thanks,
Chris.


/martin


signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Fwd: I-D Action: draft-chopps-netmod-geo-location-01.txt

[Christian Hopps]

FYI, Updated to make motion vector 3d vs 2d, also added some more non-normative 
explanation text, on nesting and out-of-scope non-location attributes.

internet-dra...@ietf.org writes:


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : 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.  The geographical location grouping is intended to be used
   in YANG models for specifying a location on or in reference to the
   Earth or any other astronomical object.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-chopps-netmod-geo-location/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-chopps-netmod-geo-location-01
https://datatracker.ietf.org/doc/html/draft-chopps-netmod-geo-location-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-chopps-netmod-geo-location-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-chopps-netmod-geo-location-00.txt

[Christian Hopps]

Kent Watsen  writes:


This is a neat draft.   Reminds me of when I worked on the Virtual Reality and
real-time simulations.I once wrote a class to convert locations, vectors, 
and
orientations to and from WGS84 geocentric coordinate space and topocentric
coordinate space systems.   I was fresh out of college with a Math degree, so
of course they gave it to the new guy (me) to figure out  ;)


Thanks. :)


Anyway, while WGS84 appears to still be applicable, it looks like a lot of other
standards work has occurred since.   I'd have to dig into it to provide a deeper
comment.   From a gap-perspective, it seems that this module covers locations,
but not vectors or orientations (intentional?) Note: "heading" defines a value 
in
just a single dimension, so doesn't work for VR.   From an add-perspective, I'm
surprised to see "speed" included here, at least we always had 1st (and 2nd)
order temporal information defined elsewhere.


So yeah, there seems to be limitless amounts of work going on at least related 
or involving this topic.

Regarding WGS84, the WGS84 geoid has been updated multiple times that's what 
the EGM96 and EGM08 are all about. Each one getting better at handling local 
gravitational variance, which affects actual sea levels. The original WGS84 was 
actually very inaccurate. The EGM (earth gravitational model) updates have been 
fixing this based on data from various satellite missions.

Regarding movement: The point here is to define a geographical location -- so 
there is a concept of stability involved. It seemed reasonable to include 
relatively stable movement as well, key thing being stable (e.g., continental 
drift). Once you start trying to describe motion, all bets are off and we 
aren't really talking about geographical locations anymore. The text 
specifically mentions it's not trying to handle 2nd and further derivative 
motion (or I thought it did :)

I do think I may need to add a second value to the velocity vector to handle 3d 
movement though as continents are actually moving in 3 dimensions (rising and 
sinking as well as moving on the globe).

I may also need to add something to indicate the height value being relative to 
ground (or more). At first I thought this could be captured by a variation of 
the geodeditc-datum value, but on further thought I think that might not be the 
right solution -- we also may want to be able to specify multiple different 
things the height could be relative too (e.g., the ground floor or basement of 
a building), not just the ground itself.

Orientation (e.g., the way a camera is pointed or what it's focal length is, 
etc) seems out of scope -- those aren't attributes 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.org>
Subject: I-D Action: draft-chopps-netmod-geo-location-00.txt
Date: February 26, 2019 at 3:59:23 PM EST
To: mailto:i-d-annou...@ietf.org>>
Reply-To: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>


A New Internet-Draft is available from 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-26

Abstract:
  This document defines a generic geographical location object YANG
  grouping.  The geographical location grouping is intended to be used
  in YANG models for specifying a location on or in reference to the
  Earth or any other astronomical object.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-chopps-netmod-geo-location/ 
<https://datatracker.ietf.org/doc/draft-chopps-netmod-geo-location/>

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-chopps-netmod-geo-location-00
https://datatracker.ietf.org/doc/html/draft-chopps-netmod-geo-location-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt



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


signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] I-D Action: draft-chopps-netmod-geo-location-00.txt

[Christian Hopps]

FYI.

> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: I-D Action: draft-chopps-netmod-geo-location-00.txt
> Date: February 26, 2019 at 3:59:23 PM EST
> To: 
> Reply-To: internet-dra...@ietf.org
> 
> 
> A New Internet-Draft is available from 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-26
> 
> Abstract:
>   This document defines a generic geographical location object YANG
>   grouping.  The geographical location grouping is intended to be used
>   in YANG models for specifying a location on or in reference to the
>   Earth or any other astronomical object.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-chopps-netmod-geo-location/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-chopps-netmod-geo-location-00
> https://datatracker.ietf.org/doc/html/draft-chopps-netmod-geo-location-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Last Call: (YANG Module Tags) to Proposed Standard

[Christian Hopps]

Perhaps we could add some more text in the "Tag Values" section to make this 
clearer:

   
   Except for the conflict-avoiding prefix, this document is not specifying any 
structure on (i.e., restricting) the tag values on purpose. The intent here is 
to avoid arbitrarily restricting 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 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 tags SHOULD begin with a prefix indicating who owns their
   definition. An IANA registry is used to support standardizing
   tag prefixes. Currently 3 prefixes are defined with all others
   reserved. No further structure is imposed by this document on
   the value following the standard prefix, and the value can
   contain any yang type 'string' characters except
   carriage-returns, newlines and tabs.
 

"NO FURTHER STRUCTURE..."

There's no structure. People are free to pick any value they want for the tag. 
If a vendor or an operator wants to create their own sub-structure they are 
free to do so; however, the base specification does not and should not say this 
as we specifically do *not* want to restrict things.

I think the problem is that some people want to start restricting this concept 
and get into specifying and limiting tags to some arbitrary structure, and so 
they say it's missing. It's not missing, it's intentionally designed to not 
have it. Its simple, and it's powerful in it's simplicity.

I don't know why there would be any objection to using IANA to create a 
registry for specifying standard values for a specific use (module tags). 
That's what IANA is for. There are countless examples of standardizing values 
w/o using URNs to do it.

Thanks,
Chris.


tom petch  writes:


This I-D creates  new way of specifying names for objects; why?

We have several existing ways, such as urn: (currently being used by
IPPM for its registry, in form of urn:ietf:.. ) and YANG already makes
extensive use of urn: so that is part of the vocabulary of YANG modules,
so why do we need a new one?

And for a new one, the specification seems vague; again, urn or, more
generally, uri provides an example of how to specify things.

More specifically,

- the body of the document fails to specify the syntax. Delve into the
YANG module and I find
 pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+';
but I expect something in the body, ABNF perhaps.

- that pattern allows an infinite depth and is accompnied by
 length "1..max";
so we could have thousands of characters and the structure seems to be a
tree yet the I-D fails to specify how the tree is used, who can create
what where. Can I, or someone else, create
ietf:hardware:cisco:router:2513:trn
Well, the I-D says
"   No further structure is imposed by this document on the value"
so the answer is yes: not a good way to start IMHO - better to start
small and expand as needs arise.  The I-D cites #hashtags as part of its
justification; for me, the opposite is true, where standards work is
concerned.

In the same vein,
"If the module definition is IETF standards track, the tags MUST also be
IETF standard tags"
but I see nothing to stop proprietary modules using ietf: tags.

- CR NL tab are excluded but type string allows
any Unicode or ISO/IEC 10646 character
so scope there for i18n

- there is work for IANA but the I-D references the obsolete RFC5226 and
so, e.g., fails to specify a Group name (which I find makes the
difference between being able to find something readily on the IANA
website and not).

- "   Other SDOs (standard organizations) wishing to standardize their
own
   set of tags could allocate a top level prefix from this registry."
How?  Documents like those on URI give guidelines, an e-mail to IANA
perhaps.

-   "The allocation policy for this registry is Specification Required"
So what should a Designated Expert look for?  It is customary for an I-D
to give guidance, if only to the IESG who have to appoint the expert.

Then there are a number of glitches.

The Abstract contains
 this document updates [RFC8407].
which looks like a reference, not allowed in Abstract

The YANG module contains
"  described in BCP 14 [RFC2119] [RFC8174] "
which again looks like a reference whereas YANG modules must be plain
text.

Copyright is 2018

YANG module import statement lacks a reference statement

The I-D contains an update to RFC8407 which says
"The module writer can use existing standard tags"
The phrase "

Re: [netmod] Last Call: (YANG Module Tags) to Proposed Standard

[Christian Hopps]

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 tags SHOULD begin with a prefix indicating who owns their
   definition. An IANA registry is used to support standardizing
   tag prefixes. Currently 3 prefixes are defined with all others
   reserved. No further structure is imposed by this document on
   the value following the standard prefix, and the value can
   contain any yang type 'string' characters except
   carriage-returns, newlines and tabs.
 

"NO FURTHER STRUCTURE..."

There's no structure. People are free to pick any value they want for the tag. 
If a vendor or an operator wants to create their own sub-structure they are 
free to do so; however, the base specification does not and should not say this 
as we specifically do *not* want to restrict things.

I think the problem is that some people want to start restricting this concept 
and get into specifying and limiting tags to some arbitrary structure, and so 
they say it's missing. It's not missing, it's intentionally designed to not 
have it. Its simple, and it's powerful in it's simplicity.

I don't know why there would be any objection to using IANA to create a 
registry for specifying standard values for a specific use (module tags). 
That's what IANA is for. There are countless examples of standardizing values 
w/o using URNs to do it.

Thanks,
Chris.


tom petch  writes:


This I-D creates  new way of specifying names for objects; why?

We have several existing ways, such as urn: (currently being used by
IPPM for its registry, in form of urn:ietf:.. ) and YANG already makes
extensive use of urn: so that is part of the vocabulary of YANG modules,
so why do we need a new one?

And for a new one, the specification seems vague; again, urn or, more
generally, uri provides an example of how to specify things.

More specifically,

- the body of the document fails to specify the syntax. Delve into the
YANG module and I find
 pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+';
but I expect something in the body, ABNF perhaps.

- that pattern allows an infinite depth and is accompnied by
 length "1..max";
so we could have thousands of characters and the structure seems to be a
tree yet the I-D fails to specify how the tree is used, who can create
what where. Can I, or someone else, create
ietf:hardware:cisco:router:2513:trn
Well, the I-D says
"   No further structure is imposed by this document on the value"
so the answer is yes: not a good way to start IMHO - better to start
small and expand as needs arise.  The I-D cites #hashtags as part of its
justification; for me, the opposite is true, where standards work is
concerned.

In the same vein,
"If the module definition is IETF standards track, the tags MUST also be
IETF standard tags"
but I see nothing to stop proprietary modules using ietf: tags.

- CR NL tab are excluded but type string allows
any Unicode or ISO/IEC 10646 character
so scope there for i18n

- there is work for IANA but the I-D references the obsolete RFC5226 and
so, e.g., fails to specify a Group name (which I find makes the
difference between being able to find something readily on the IANA
website and not).

- "   Other SDOs (standard organizations) wishing to standardize their
own
   set of tags could allocate a top level prefix from this registry."
How?  Documents like those on URI give guidelines, an e-mail to IANA
perhaps.

-   "The allocation policy for this registry is Specification Required"
So what should a Designated Expert look for?  It is customary for an I-D
to give guidance, if only to the IESG who have to appoint the expert.

Then there are a number of glitches.

The Abstract contains
 this document updates [RFC8407].
which looks like a reference, not allowed in Abstract

The YANG module contains
"  described in BCP 14 [RFC2119] [RFC8174] "
which again looks like a reference whereas YANG modules must be plain
text.

Copyright is 2018

YANG module import statement lacks a reference statement

The I-D contains an update to RFC8407 which says
"The module writer can use existing standard tags"
The phrase "module writer" is not used by RFC8407.

Tom Petch

- Original Message -
From: "The IESG" 
To: "IETF-Announce" 
Cc: ; ; "Joel Jaeggli"
; ;

Sent: Monday, February 18, 2019 3:49 AM
Subject: Last Call:  (YANG Module
Tags) to Proposed Standard




The IESG has received a request from the Network Modeling WG (netmod)

to

consider the following document: - 'YANG Module Tags'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits

final

comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2019-03-03. Exceptionally, comments may

be

sent to 

Re: [netmod] Few Comments //RE: Publication has been requested for draft-ietf-netmod-module-tags-04

[Christian Hopps]

> On Feb 20, 2019, at 10:40 PM, Rohit R Ranade  wrote:
> 
> Hi Christian,
> 
> 2 points are missing from the IANA registry, "Updates to the IETF XML 
> Registry" and "Updates to the YANG Module Names Registry", you can refer to 
> RFC 8342 section 8 for registering the new module and namespace.

Will add, thanks.

> Also w.r.t "ietf:", whether we can make it "sdo:" and ask ietf modules to 
> start their tags as "sdo:ietf:" , because all the other SDO will need to 
> register their organization prefixes once with IANA.  This will also keep it 
> at the same level where each vendor will also define his tags as 
> "vendor:vendor-name:x" etc.

Since this isn't fixing something that's broken, and in fact is going against 
what was talked about and agreed to in the WG during the 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 R Ranade 
> Cc: Christian Hopps ; Joel Jaeggli ; 
> ibagd...@gmail.com; netmod-cha...@ietf.org; iesg-secret...@ietf.org; 
> netmod@ietf.org
> Subject: Re: [netmod] Few Comments //RE: Publication has been requested for 
> draft-ietf-netmod-module-tags-04
> 
> 
> Rohit R Ranade  writes:
> 
>> Hi,
>> 
>> Thank you for accepting the comments. Few more comments from my side.
>> 
>> Technical:
>> 1. Section 8.1, " could allocate a top level prefix ", I think there is no 
>> concept of top-level prefix now. I think this is a remnant of the versions 
>> posted earlier where you had examples of multiple prefixes in a tag. Can be 
>> removed now I think.
> 
> Indeed! I'll remove "top level", as there are no levels.
> 
>> 2. Why should the prefix contain ietf: , vendor:, user: ?  I think the 
>> second part of the prefix is more important for classification because most 
>> of the vendors / sdo already define their own prefixes for their module-name 
>> based on RFC7950 guideline in Section 5.1. By adding the prefix, I feel it 
>> will reduce the re-usability by other SDO / vendors.
> 
> Well the second part of the tag is the tag itself, the prefix is simply there 
> to avoid collision between the module authors in various SDOs, the module 
> implementers, and the module users.
> 
>> 3. Consider we have defined a module example-bgp which is similar to 
>> ietf-bgp.
>> If we need to add tags to example-bgp, then we need to define new "vendor:" 
>> prefixes for this even if it uses some IETF protocols ?
> 
> "ietf:" tags are allocated with IETF documents which is what the registry 
> policy "IETF Review" indicates.
> 
> However, this is an allocation policy not a USE policy. As module designer 
> you get to pick whatever tags you think apply (which is what section 4.1 
> says).
> 
>> I think we need to add more clarity in this document as to when the "ietf:" 
>> prefix can be used by a module ? Whether a vendor module can/cannot use 
>> standard tags ?
>> Consider a module which has some part of vendor and some part of IETF 
>> protocol , whether vendor can use "ietf:" tags then ?
>> I suggest adding one more example in this document which may 
>> indicate/clarify your stand regarding this point.
> 
> Again, if you are creating your own module then you can choose whatever tags 
> you want to add to it (section 4.1).
> 
> I've changed the headings under section 4 to:
> 
>  4.1 "Module Definition Tagging"
>  4.2 "Implementation Tagging"
>  4.3 "User Tagging"
> 
> and split 4.1 into 2 paragraphs (at "If the") to better separate the IETF 
> part away from the anyone part.
> 
>> 4. By defining a module tag as an extension, there is no way to validate 
>> this extension's argument during YANG compilation (even though a pattern is 
>> defined). The existing YANG compiler tools will be forced to do hard-coding 
>> for this. Whether there should be a note to Yang Compiler Developers in this 
>> document for clarity ?
> 
> Well the WG wanted the extension, originally it was just part of a comment in 
> the module definition. I think yang compiler developers (a very small group 
> compared to the other users of this document) can probably figure this out 
> without extra text. :)
> 
>> Please not that all these points originated in my mind, by thinking as to 
>> how I will use these tags. On the whole, I like the idea and than

Re: [netmod] Few Comments //RE: Publication has been requested for draft-ietf-netmod-module-tags-04

[Christian Hopps]

Rohit R Ranade  writes:


Hi,

Thank you for accepting the comments. Few more comments from my side.

Technical:
1. Section 8.1, " could allocate a top level prefix ", I think there is no 
concept of top-level prefix now. I think this is a remnant of the versions posted earlier 
where you had examples of multiple prefixes in a tag. Can be removed now I think.


Indeed! I'll remove "top level", as there are no levels.


2. Why should the prefix contain ietf: , vendor:, user: ?  I think the second 
part of the prefix is more important for classification because most of the 
vendors / sdo already define their own prefixes for their module-name based on 
RFC7950 guideline in Section 5.1. By adding the prefix, I feel it will reduce 
the re-usability by other SDO / vendors.


Well the second part of the tag is the tag itself, the prefix is simply there 
to avoid collision between the module authors in various SDOs, the module 
implementers, and the module users.


3. Consider we have defined a module example-bgp which is similar to ietf-bgp.
If we need to add tags to example-bgp, then we need to define new "vendor:" 
prefixes for this even if it uses some IETF protocols ?


"ietf:" tags are allocated with IETF documents which is what the registry policy 
"IETF Review" indicates.

However, this is an allocation policy not a USE policy. As module designer you 
get to pick whatever tags you think apply (which is what section 4.1 says).


I think we need to add more clarity in this document as to when the "ietf:" 
prefix can be used by a module ? Whether a vendor module can/cannot use standard tags ?
Consider a module which has some part of vendor and some part of IETF protocol , whether 
vendor can use "ietf:" tags then ?
I suggest adding one more example in this document which may indicate/clarify 
your stand regarding this point.


Again, if you are creating your own module then you can choose whatever tags 
you want to add to it (section 4.1).

I've changed the headings under section 4 to:

 4.1 "Module Definition Tagging"
 4.2 "Implementation Tagging"
 4.3 "User Tagging"

and split 4.1 into 2 paragraphs (at "If the") to better separate the IETF part 
away from the anyone part.


4. By defining a module tag as an extension, there is no way to validate this 
extension's argument during YANG compilation (even though a pattern is 
defined). The existing YANG compiler tools will be forced to do hard-coding for 
this. Whether there should be a note to Yang Compiler Developers in this 
document for clarity ?


Well the WG wanted the extension, originally it was just part of a comment in 
the module definition. I think yang compiler developers (a very small group 
compared to the other users of this document) can probably figure this out 
without extra text. :)


Please not that all these points originated in my mind, by thinking as 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 ; Joel Jaeggli ; 
ibagd...@gmail.com; netmod-cha...@ietf.org; iesg-secret...@ietf.org; netmod@ietf.org
Subject: Re: [netmod] Few Comments //RE: Publication has been requested for 
draft-ietf-netmod-module-tags-04




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 by using normal configuration"


Done


3.  Description of statement "leaf-list tag", in the Step 1), " System added tags are added" can be 
replaced with "tags of 'system' origin are added" as it associates System with "system" origin in a 
better way.


Adopted with modification. Trying to keep things more readable but still well 
specified.

   1) System tags (i.e., tags of 'system' origin) are added.
   2) User configured tags (i.e., tags of 'intended' origin)
   are added.
   3) Any tag that is equal to a masked-tag is removed.";


4.  Description of statement "leaf-list tag", " The operational view of this list", can 
be replaced with "The applied configuration of this list", as it uses is a well-known term from RFC 
8342.


NEW:
   The 'operational' state [RFC8342] view of this list is
   constructed using the following steps:



5.  Description of statement "leaf-list tag", " User configured tags"
can be replaced with "tags of 'intended' origin" as it uses a
well-known NMDA term from RFC8342


Adopted with mod,

Re: [netmod] Yangdoctors last call review of draft-ietf-netmod-module-tags-04

[Christian Hopps]

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 all IETF documents being processed by the IESG.  
> These
> comments were written with the intent of improving the operational aspects of
> the IETF drafts. Comments that are not addressed in last call may be included
> in AD reviews during the IESG review.  Document editors and WG chairs should
> treat these comments just like any other last call comments.
> 
> I've already reviewed the previous revision of this document as part of WG LC,
> and any significant comments have already been addressed.  What remains are
> minor nits, that would probably be spotted/addressed by the RFC editor, and I
> leave it to the authors discretion as to whether/how they address these:
> 
> 1. It may be helpful for the introduction to state that the module conforms to
> NMDA (from YANG guidelines section 3.5).  I.e. add the following text +
> reference.
> 
>  The YANG data model in this document conforms to the Network
> Management Datastore Architecture defined in
> RFC 8342.
> 
> 2. Paragraph 4.1, perhaps "will be" => "is"?
> 
> 3. Section 4.3, "removed with using" => "removed using"
> 
> 4. The YANG module itself:
> 
> 4i) NetMod => NETMOD (two places)
> 
> 4ii) The RFC 2119 boilerplate should probably be updated to cover RFC 8174.
> 
> 4iii) Line length is a bit long in places.  I checked using pyang against 69
> chars and got this, so at least line 89 should be fixed (but the RFC editor
> will also fix this): ietf-module-t...@2018-10-17.yang:56: warning: line length
> 72 exceeds 69 characters ietf-module-t...@2018-10-17.yang:57: warning: line
> length 71 exceeds 69 characters ietf-module-t...@2018-10-17.yang:63: warning:
> line length 71 exceeds 69 characters ietf-module-t...@2018-10-17.yang:64:
> warning: line length 71 exceeds 69 characters
> ietf-module-t...@2018-10-17.yang:86: warning: line length 72 exceeds 69
> characters ietf-module-t...@2018-10-17.yang:89: warning: line length 86 
> exceeds
> 69 characters
> 
> 4iv) Possibly add ", but they have no operational effect" to the end of the
> description of masked-tag.  Although, it is pretty obvious to me that they
> would just be ignored.
> 
> 5) Section 6.
>  - Suggest "It's" => "It is", "2" => "two", "3" => "three".
>  - Suggest "is classifying modules in only a logical manner" => "only
>  classifies modules in a logical manner"
> 
> 6) Section 7.1.
> - Since these are guidelines, I suggest "can" => "MAY".
> 
> 7) Section 8.1.
> - I note that this section uses "SHOULD", and section 3.4 just says reserved.
> Should section 3.4 also use RFC2119 language to be aigned at all?
> 



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Few Comments //RE: Publication has been requested for draft-ietf-netmod-module-tags-04

[Christian Hopps]

> 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 
> by using normal configuration"

Done

> 3.  Description of statement "leaf-list tag", in the Step 1), " System added 
> tags are added" can be replaced with "tags of 'system' origin are added" as 
> it associates System with "system" origin in a better way.

Adopted with modification. Trying to keep things more readable but still well 
specified.

   1) System tags (i.e., tags of 'system' origin) are added.
   2) User configured tags (i.e., tags of 'intended' origin)
   are added.
   3) Any tag that is equal to a masked-tag is removed.";

> 4.  Description of statement "leaf-list tag", " The operational view of this 
> list", can be replaced with "The applied configuration of this list", as it 
> uses is a well-known term from RFC 8342.

NEW:
   The 'operational' state [RFC8342] view of this list is
   constructed using the following steps:


> 5.  Description of statement "leaf-list tag", " User configured tags" can be 
> replaced with "tags of 'intended' origin" as it uses a well-known NMDA term 
> from RFC8342

Adopted with mod, See above.

> Technical:
> 1. Section 4.2, "These tags may be standard or vendor specific tags".  Does 
> this statement exclude other tags from being added by implementations ? If it 
> does not exclude, I feel this statement can be removed.

Going to leave this, standard tags and vendor tags are tags with a specific 
prefix.

> 2. In the description of Yang statement "leaf-list tag", is there any reason 
> why System tags should be added first and then User configured tags ? Not 
> clear.

This is just the way it worked out on the mailing list. Doesn't hurt to specify 
an order.

> 3. Description of statement "leaf-list masked-tag", " This user can remove 
> (mask) tags", I think we need to clarify that it will not "apply" the tags 
> which have been configured as "masked-tags", because they are not "removed" 
> from any configuration datastore.
> The tags which have been masked will be present in , but will not 
> be present in .
> Suggested description
> " The list of tags that will not be applied to this
> module. By adding tags to this list, the user can prevent
> such tags from being applied. It is not an error to add
> tags to this list that are not associated with the module."

I'm not sure about making these changes. I think the current text (with the 
modification below) is pretty clear in what is meant, and delving so deeply 
into NMDA gets distracting, and could in fact end up being wrong (e.g., I think 
of tags being associated with a module not applied to them).

 I did make the change to the enumerated list to show what is meant by "System" 
and "User", and in the spirit of your suggestion, I did change it to be more 
specific about operational state datastore.

  "The list of tags that should not be associated with this
   module. The user can remove (mask) tags from the
   operational state datastore [RFC8342] by adding them to
   this list. It is not an error to add tags to this list
   that are not associated with the module, but they have no
   operational effect.";

Thanks for the review!

Chris.


> 
> 
> With Regards,
> Rohit R
> 
> 
> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Joel Jaeggli
> Sent: 13 February 2019 05:20
> To: ibagd...@gmail.com
> Cc: netmod-cha...@ietf.org; Joel Jaeggli ; 
> iesg-secret...@ietf.org; netmod@ietf.org
> Subject: [netmod] Publication has been requested for 
> draft-ietf-netmod-module-tags-04
> 
> 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 
> https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/
> 
> ___
> 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
> 



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Publication has been requested for draft-ietf-netmod-module-tags-04

[Christian Hopps]

Martin Bjorklund  writes:


Hi,

I think one concern with "rfc8199-xxx" is that if this RFC gets reved,
the name will be misleading.  I also agree that "element" is too
vague.


Isn't this why we have "Updates" and "Obsoletes" for? If this all didn't work we could never refer to our 
standards by RFC number anywhere, right? Also, the value in the registry is going to point at us and us to RFC8199 no matter what 
string we end up with. I'm not stuck on this though, so if you still think we need to change I'll take your suggestion, but add 
the suffix "-class" to be more specific and avoid conflicting with "ietf:network-service" at the same time. 
Also can change to "sdo-defined-class".

Thanks,
Chris.


Since 8199 doesn't use the terms "element" and "service", but "network
element" and "network service", how about these changes:

  ietf:rfc8199-element  -->  ietf:network-element
  ietf:rfc8199-service  -->  ietf:network-service
  ietf:rfc8199-vendor   -->  ietf:vendor-defined
  ietf:rfc8199-user -->  ietf:user-defined
  ietf:rfc8199-standard -->  ietf: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, 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 supposed
>> to be. It'll need to be something like "ietf:module-class-element" or
>> "ietf:an-rfc8199-elemenet" or nothing I guess.
>
> Seems arbitrary what we call too generic and what not. To me,
> ietf:protocol is also quite generic.

But, "ietf:protocol" is in fact intended and defined to be generic,
"ietf:rfc8199-element" is not defined as generic at all. It's defined
very clearly in RFC8199. Using a broad tag "ietf:element" for such a
narrow definition is not appropriate.

Again the normative text should take precedence here, so I'm inclined
to leave things as they are, unless you'd like a more restricted
alternative.

>> I have this suspicion that if it had been "ietf:an-rfc8199-element"
>> you might not have brought up this introducing scope stuff. What if
>> there was no "-" symbol used (i.e., "ietf:rfc8199element"?
>
> You may miss the point I am making.
>
>> The normative text says that we are defining no structure outside the
>> prefix (i.e., it's flat). I believe what your saying is that if you
>> ignore this normative text and just look at the "ietf:rfc8199-element"
>> tags by themselves, one might imagine some meaning of scope. Do we
>> need to repeat or reword the fact we are defining no structure beyond
>> the prefix to make this more clear so people don't start imagining
>> structures where we've normatively said they don't exist?
>>
>
> You apparently use rfc8199- to scope 'element'...

This is getting a bit too abstract for me. Its a tag with a defined
meaning. I actually think its very clear and informative as written. I
think someone seeing it will immediately open RFC8199 and find the
definition for what it means. And, if that's what happens then it's a
good choice, not a bad one.

>> > > Please help clear your objections here as we're in the final stages of
>> > > publication, and raising objections now I think should be accompanied
>> > > with suggestions on how to clear them as well.
>> >
>> > I am not raising objections. I asked a question. And it is fine to be
>> > told that I should shut up because we are past WG last call and the WG
>> > likes what we have (and the WG or the IETF we will later figure out
>> > what lets say ietf:protocol is really good for or whether scopes like
>> > 'rfc8199-' are a good or bad idea).
>>
>> Your opinion rightly carries a lot of weight in this group, and so
>> your questions need to be addressed even though they are coming late
>> in the process.
>
> Not true. I am happy to be shut down.

In that case, seeing as we have normative text that directly addresses
the flatness of the space,
unless you have some suggestions on simple changes I'd like to move
on. :)

Thanks,
Chris.

>
> /js



signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Publication has been requested for draft-ietf-netmod-module-tags-04

[Christian Hopps]

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 supposed to be. It'll need to be something like 
"ietf:module-class-element" or "ietf:an-rfc8199-elemenet" or nothing I guess.


Seems arbitrary what we call too generic and what not. To me,
ietf:protocol is also quite generic.


But, "ietf:protocol" is in fact intended and defined to be generic, 
"ietf:rfc8199-element" is not defined as generic at all. It's defined very clearly in RFC8199. 
Using a broad tag "ietf:element" for such a narrow definition is not appropriate.

Again the normative text should take precedence here, so I'm inclined to leave 
things as they are, unless you'd like a more restricted alternative.


I have this suspicion that if it had been "ietf:an-rfc8199-element" you might not have brought up 
this introducing scope stuff. What if there was no "-" symbol used (i.e., 
"ietf:rfc8199element"?


You may miss the point I am making.


The normative text says that we are defining no structure outside the prefix (i.e., it's 
flat). I believe what your saying is that if you ignore this normative text and just look 
at the "ietf:rfc8199-element" tags by themselves, one might imagine some 
meaning of scope. Do we need to repeat or reword the fact we are defining no structure 
beyond the prefix to make this more clear so people don't start imagining structures 
where we've normatively said they don't exist?



You apparently use rfc8199- to scope 'element'...


This is getting a bit too abstract for me. Its a tag with a defined meaning. I 
actually think its very clear and informative as written. I think someone 
seeing it will immediately open RFC8199 and find the definition for what it 
means. And, if that's what happens then it's a good choice, not a bad one.


> > Please help clear your objections here as we're in the final stages of 
publication, and raising objections now I think should be accompanied with 
suggestions on how to clear them as well.
>
> I am not raising objections. I asked a question. And it is fine to be
> told that I should shut up because we are past WG last call and the WG
> likes what we have (and the WG or the IETF we will later figure out
> what lets say ietf:protocol is really good for or whether scopes like
> 'rfc8199-' are a good or bad idea).

Your opinion rightly carries a lot of weight in this group, and so your 
questions need to be addressed even though they are coming late in the process.


Not true. I am happy to be shut down.


In that case, seeing as we have normative text that directly addresses the 
flatness of the space,
unless you have some suggestions on simple changes I'd like to move on. :)

Thanks,
Chris.



/js




signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Publication has been requested for draft-ietf-netmod-module-tags-04

[Christian Hopps]

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 different meanings in
> different contexts is common. If scopes are not needed, then I would
> argue 'rfc8199-' is not needed. Or it is needed and then it would be
> useful as well for ietf-qos and friends.

RFC8199 defines an element vs service. Given those definitions these 2 tags seem USEFUL. So what do you 
suggest we call these tags to remove your "adding scope" objection? Would 
"ietf:module-class-element" and "ietf:module-class-service"? and reference RFC8199 in the 
doc/registry, clear your objection?


I simply asked why we are inconsistent with the initial tags that we
allocate. Others will want to allocate tags in the future, what do we
tell them how to do it? If the idea is to go with a true flat
namespace, then simply remove 'rfc8199-' from the tags and we have
ietf:element, ietf:service, ietf:standard, ietf:vendor, ietf:user,
which lines up with ietf:routing and the like.


But, ietf:element is too generic to assign the meaning "RFC8199 module classification of element" which is 
what "rfc8199-element" is supposed to be. It'll need to be something like 
"ietf:module-class-element" or "ietf:an-rfc8199-elemenet" or nothing I guess.

I have this suspicion that if it had been "ietf:an-rfc8199-element" you might not have brought up 
this introducing scope stuff. What if there was no "-" symbol used (i.e., 
"ietf:rfc8199element"?

The normative text says that we are defining no structure outside the prefix (i.e., it's 
flat). I believe what your saying is that if you ignore this normative text and just look 
at the "ietf:rfc8199-element" tags by themselves, one might imagine some 
meaning of scope. Do we need to repeat or reword the fact we are defining no structure 
beyond the prefix to make this more clear so people don't start imagining structures 
where we've normatively said they don't exist?


Please help clear your objections here as we're in the final stages of 
publication, and raising objections now I think should be accompanied with 
suggestions on how to clear them as well.


I am not raising objections. I asked a question. And it is fine to be
told that I should shut up because we are past WG last call and the WG
likes what we have (and the WG or the IETF we will later figure out
what lets say ietf:protocol is really good for or whether scopes like
'rfc8199-' are a good or bad idea).


Your opinion rightly carries a lot of weight in this group, and so your 
questions need to be addressed even though they are coming late in the process.

Thanks,
Chris.



/js




signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Publication has been requested for draft-ietf-netmod-module-tags-04

[Christian Hopps]

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 meaning.


Frankly, I can't really tell where ietf:protocol applies or not or
what exactly is ietf:signaling vs some of the other closely related
tags. The descriptions are rather open ended.


Please make suggestions (descriptive text, remove the tag, etc) on how to fix 
things to clear your objections.


All that said, if these RFC8199 are inappropriate for inclusion in this document or confusing, I'd 
rather remove them than stall the work. To use a routing analogy, the intent of this work is to 
create a method for "signaling" values, not to define the "values" themselves.


Section 8.2 defines values, this section is not a signaling mechanism
alone anymore.


Section 8.2 is there to help get things started. I'd rather remove it than 
perfect it. Perfect is not possible IMO, and TBH in netmod it often feels like 
good enough is ridiculously hard to come by.


> the idea is to further scope IETF defined tags (there may be multiple
> 'element' tags), why does this additional scoping need not apply to

There is no intent to add additional scoping.  Indeed this was part of the motivation 
behind the addition of the final sentence in the "Tag Value" text in v3 of the 
document:

   All tags begin with a prefix indicating who owns their definition.
   An IANA registry is used to support standardizing tag prefixes.
   Currently 3 prefixes are defined with all others reserved.  No
   further structure is imposed by this document on the value following
   the standard prefix, and the value can contain any yang type 'string'
   characters except carriage-returns, newlines and tabs.


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 different meanings in
different contexts is common. If scopes are not needed, then I would
argue 'rfc8199-' is not needed. Or it is needed and then it would be
useful as well for ietf-qos and friends.


RFC8199 defines an element vs service. Given those definitions these 2 tags seem USEFUL. So what do you 
suggest we call these tags to remove your "adding scope" objection? Would 
"ietf:module-class-element" and "ietf:module-class-service"? and reference RFC8199 in the 
doc/registry, clear your objection?

Please help clear your objections here as we're in the final stages of 
publication, and raising objections now I think should be accompanied with 
suggestions on how to clear them as well.

Thanks,
Chris.



/js




signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Publication has been requested for draft-ietf-netmod-module-tags-04

[Christian Hopps]

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 
https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/



I just looked at the latest diff and I stumbled over the example using
tags like ietf:rfc8199-element and ietf:routing and while I had an
intuitive idea what ietf:routing may mean, I was pretty clueless what
ietf:rfc8199-element is. Back in the old SNMP days, we actually
learned that using RFC numbers in labels is not always a good idea
because definitions sometimes get replaced or moved to other RFCs. If


You were clueless after you read RFC8199? :) We could change the tag names to:

 ietf-class-service
 ietf-class-element

And point at RFC8199 in the document for their definition. However, this only 
seems to further obfuscate the meaning from the user requiring 2 hops to reach 
the meaning vs. 1 hop. Repeating RFC8199 inside the modules tag draft to remove 
the reference seems ill-advised if that was your intention.

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 meaning.

All that said, if these RFC8199 are inappropriate for inclusion in this document or confusing, I'd 
rather remove them than stall the work. To use a routing analogy, the intent of this work is to 
create a method for "signaling" values, not to define the "values" themselves.


the idea is to further scope IETF defined tags (there may be multiple
'element' tags), why does this additional scoping need not apply to


There is no intent to add additional scoping.  Indeed this was part of the motivation 
behind the addition of the final sentence in the "Tag Value" text in v3 of the 
document:

   All tags begin with a prefix indicating who owns their definition.
   An IANA registry is used to support standardizing tag prefixes.
   Currently 3 prefixes are defined with all others reserved.  No
   further structure is imposed by this document on the value following
   the standard prefix, and the value can contain any yang type 'string'
   characters except carriage-returns, newlines and tabs.

Thanks,
Chris.


ietf:routing? So bottom line, should the tags _all_ be of the form

- ietf:rfc:label or
- ietf:rfc-label or
- ietf:scope-label or
- ietf:scope:label or
- ietf:label

where scope indicates the topic of the RFC defining the label
(avoiding the embedding of the RFC number). I think it will be good if
the ietf: namespace is somewhat organized from the start and it is not
so good if the initial document is already using different forms.

/js

PS: I also wonder why this document defines ietf:lmp or more precisely
what exactly this is. When do I use ietf:protocol? When does it
apply and when not? Does it apply to ietf-system.yang since it
among other things sets parameters for ntp? I also wonder what the
life cycle management of these tag definitions is. If it turns out
that tags are underspecified, can I deprecate or obsolete them?


signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call

[Christian Hopps]

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 problems (that you highlight) with the servers *not* storing 
the tags.

I think this is a rather simple thing we’ve proposed, and the server is the 
seemingly natural/simple place to do it.

I think it would be good to get some justification for *not* having the server 
store tags for it’s own modules.

Thanks,
Chris.



> On Nov 15, 2018, at 19:54, Kent Watsen  wrote:
> 
> 
>> The servers implement the modules which can have predefined tags from
>> the module designer as well as the implementer (vendor) which literally
>> cannot come from anywhere *but* the server that implements the module.
> 
> Predefined tags from the implementer only needs to come from the 
> implementor.  Whether it is provided by the server itself or via
> some out-of-band mechanism (e.g., module catalog) seems to be the
> question.
> 
> Of course, one might say that user-tags must be provided by the 
> server itself, in order to provide an inter-client communication 
> mechanism of some sort, as otherwise a single client, even if 
> distributed, could keep the user-tags in its local database.
> 
> Though this begs the question, would it be better for the clients
> to use a centralized service of some sort (perhaps within the
> deployment's infrastructure, assuming the user-tags are private)
> to have user-tags once per module, rather than (redundantly?) on
> each server, thus ensuring consistency as well as avoiding 
> potential race conditions?  Or are these user-tags truly 
> server-specific (not just module-specific)?
> 
> Is it accurate to assume that two servers running identical 
> software would have identical user-tags?  Of course, the servers
> might be running different software (either different releases
> for the same hardware, or different hardware, potentially from
> different vendors).  Accommodating such would complicate the
> construction of a centralized module-tagging service, though
> it could still be done.
> 
> I suppose that the value of this document is not in any one of
> the use-cases, as they each seem minor and having alternate 
> (potentially better) workarounds, but in the multitude of them
> all, and how a single mechanism can help.
> 
> 
>> This is not what I thought would hold this work up.
> 
> My experience is that Last Calls tend to drive people to question
> basics again.  By example, it's rather common for a draft's title
> to change during a Last Call.  That said, this suitability question
> has been lingering since the day Joel kicked off the Adoption Call,
> that it is still with us seems to be the problem.
> 
> 
> Kent // contributor
> 
> 
> 

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