Re: [netmod] 6991bis: domain-name

[Ladislav Lhotka]

On Tue, 2019-07-23 at 00:07 +0200, Juergen Schoenwaelder wrote:
> On Mon, Jul 22, 2019 at 04:55:33PM -0400, Ladislav Lhotka wrote:
> > Juergen Schoenwaelder  writes:
> > 
> > > Lada,
> > > 
> > > I do not think we can simply enlarge the value set of inet:domain-name,
> > > existing implementations using inet:domain-name may (rightfully) not
> > > expect wildcards.
> > 
> > On the other hand, the description says:
> > 
> >It is designed to hold various types of domain names,including
> >names used for A or  records (host names) and otherrecords, ...
> > 
> > So one could expect that all values that can appear e.g. in A/ records
> > of DNS zone data are supported, which is not the case.
> 
> The pattern does not allow wildcards and it did so back in RFC 6021.
> We can discuss whether this is wrong but allowing wildcards or other
> new characters I think should be done with care and considering
> existing implementations.
>  
> > > What we can do is to create a new definition that has a larger value
> > > space. We can also consider to define inet:domain-name as a subset of
> > > such a larger type as long as it results in the same value space.
> > 
> > My suggestion is to remove the above sentence from the description in the
> > next revision, and leave the rest to DNS folks. There are other interesting
> > issues, such as how to model internationalized domain names.
> 
> I am not sure which problem is solved by removing the sentence.

There are many places where domain names are used. The description mentions
A//SRV resource records even those the type is actually not well suited for
this use case.

> 
> I would perhaps understand the suggestion to _add_ an explicit
> statement right at the top that wildcards or slashes are not
> supported:
> 
> OLD:
> 
> "The domain-name type represents a DNS domain name.  The
>  name SHOULD be fully qualified whenever possible.
> 
> NEW:
> 
> "The domain-name type represents a DNS domain name.  The
>  name SHOULD be fully qualified whenever possible. Domain
>names including wildcards or forward slashes are not
>supported.

But these two unsupported cases only make sense in the context of DNS zone data.
I would suggest instead

NEW:

"The domain-name type represents a DNS domain name.  The
 name SHOULD be fully qualified whenever possible.
 This type is not intended for modeling DNS zone data, as
 it does not support wildcards [RFC 4592] and classless
 in-addr.arpa delegations [RFC 2317]." 

Lada

> 
> This would help clarify things. People that need to represent
> wildcards etc. then know that this type is not the right one for
> them.
> 
> /js
> 
> > Lada
> > 
> > > /js
> > > 
> > > On Fri, Mar 29, 2019 at 11:20:13AM +0100, Ladislav Lhotka wrote:
> > > > Hi,  as a follow-up to my comment during the NETMOD session, I want
> > > > to propose the following update to the the inet:domain-name type.
> > > > The aim is to include use cases that are currently rejected:  -
> > > > classless in-addr.arpa delegations [RFC 2317], i.e. labels like
> > > > "128/26"  - wildcards [RFC 4592], e.g. "*.example.net"  OLD
> > > > pattern
> > > > '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' +
> > > > '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'  + '|\.';
> > > > NEW  pattern
> > > > '((\*\.)?(([a-zA-Z0-9_]([a-zA-Z0-9\-/_]){0,61})?[a-zA-Z0-9]\.)*'
> > > > + '([a-zA-Z0-9_]([a-zA-Z0-9\-/_]){0,61})?[a-zA-Z0-9]\.?)' +
> > > > '|\.';  Lada  --  Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID:
> > > > 0xB8F92B08A9F76C67 ___
> > > > 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 
> > 
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

[netmod] IETF YANG Side meeting reminder

[Qin Wu]

Hi, all:
Thanks Benoit to remind the YANG side meeting at the end of netmod session.
For folks who might be interested in to talk about the gap between IETF YANG 
and industry needs, please join the following side meeting scheduled on Tuesday 
morning.
Side meeting: Next Step of IETF YANG; The goal is to discuss the gap between 
IETF YANG and Industry needs; In additional objective is to collect 
requirements form Industry regarding YANG models. More details are shown below:

Room: Notre Dame - Tuesday 23 July
Location: ​Notre 
Dame

Meeting Name

Area

Contact

Meeting Description

More information

08:30

Next Step of IETF YANG

OPS Area

bill.wu@…

Discuss the gap between IETF YANG and Industry needs

Time length is 1 hour 15 minutes. We will cover note well and record the 
minutes and provide audio stream. IETF secretariat kindly offer polycom for 
audio stream.

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

Re: [netmod] 6991bis: domain-name

[Juergen Schoenwaelder]

On Mon, Jul 22, 2019 at 04:55:33PM -0400, Ladislav Lhotka wrote:
> Juergen Schoenwaelder  writes:
> 
> > Lada,
> > 
> > I do not think we can simply enlarge the value set of inet:domain-name,
> > existing implementations using inet:domain-name may (rightfully) not
> > expect wildcards.
> 
> On the other hand, the description says:
> 
>It is designed to hold various types of domain names,including
>names used for A or  records (host names) and otherrecords, ...
> 
> So one could expect that all values that can appear e.g. in A/ records
> of DNS zone data are supported, which is not the case.

The pattern does not allow wildcards and it did so back in RFC 6021.
We can discuss whether this is wrong but allowing wildcards or other
new characters I think should be done with care and considering
existing implementations.
 
> > What we can do is to create a new definition that has a larger value
> > space. We can also consider to define inet:domain-name as a subset of
> > such a larger type as long as it results in the same value space.
> 
> My suggestion is to remove the above sentence from the description in the
> next revision, and leave the rest to DNS folks. There are other interesting
> issues, such as how to model internationalized domain names.

I am not sure which problem is solved by removing the sentence.

I would perhaps understand the suggestion to _add_ an explicit
statement right at the top that wildcards or slashes are not
supported:

OLD:

"The domain-name type represents a DNS domain name.  The
 name SHOULD be fully qualified whenever possible.

NEW:

"The domain-name type represents a DNS domain name.  The
 name SHOULD be fully qualified whenever possible. Domain
 names including wildcards or forward slashes are not
 supported.

This would help clarify things. People that need to represent
wildcards etc. then know that this type is not the right one for
them.

/js

> Lada
> 
> > 
> > /js
> > 
> > On Fri, Mar 29, 2019 at 11:20:13AM +0100, Ladislav Lhotka wrote:
> > > Hi,  as a follow-up to my comment during the NETMOD session, I want
> > > to propose the following update to the the inet:domain-name type.
> > > The aim is to include use cases that are currently rejected:  -
> > > classless in-addr.arpa delegations [RFC 2317], i.e. labels like
> > > "128/26"  - wildcards [RFC 4592], e.g. "*.example.net"  OLD
> > > pattern
> > > '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' +
> > > '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'  + '|\.';
> > > NEW  pattern
> > > '((\*\.)?(([a-zA-Z0-9_]([a-zA-Z0-9\-/_]){0,61})?[a-zA-Z0-9]\.)*'
> > > + '([a-zA-Z0-9_]([a-zA-Z0-9\-/_]){0,61})?[a-zA-Z0-9]\.?)' +
> > > '|\.';  Lada  --  Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID:
> > > 0xB8F92B08A9F76C67 ___
> > > 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 
> 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] 6991bis: host

[Ladislav Lhotka]

Juergen Schoenwaelder  
writes:


Lada, 

the definition of inet:domain-name already has text that 
Internet host names have a stricter syntax. Perhaps we should 
simply state explicitely in the definition of host that the 
stricter rules apply? 

I understand that you want to capture more in the definition 
itself.  Perhaps this makes sense and is backwards compatible 
(for implementations that followed the advice in the descriptin 
of inet:domain-name).


Yes. In this case the constraint is easy to express it in a 
"pattern" statement, which is of course considerably more useful 
than having it only in the description.


Lada 


/js 

On Fri, Mar 29, 2019 at 03:29:05PM +0100, Ladislav Lhotka wrote: 
Hi,  the inet:host type should not use the inet:domain-name as 
its member because the latter type doesn't satisfy the 
requirements of RFC 952 and 1123 on host names.  For example, 
the type now permits a single dot (".") as the value or the 
underscore character.   I propose to change the "host" type as 
follows:  OLD  
typedef host { 
  type union { 
type inet:ip-address; type inet:domain-name; 
  } ... 
} 
 NEW  
typedef host { 
  type union { 
type inet:ip-address; type inet:host-name; 
  } ... 
} 
 A reasonable definition of "host-name" is IMO a domain name 
whose labels are NR- LDH (non-registered letter-digit-hyphen 
label) [RFC 5890]:  
typedef host-name { 
  type string { 
pattern 
  '((([a-zA-Z0-9]([a-zA-Z0-9\-]){0,61})?[a-zA-Z0-9]\.)*' 
+ '([a-zA-Z0-9]([a-zA-Z0-9\-]){0,61})?[a-zA-Z0-9]\.?)'; 
pattern '(.*\.)?..\-\-.*' { 
  modifier invert-match; 
} length "2..253"; ... 
  } 
} 
 Lada  --  Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 
0xB8F92B08A9F76C67 
___ 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 
 


--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] 6991bis: domain-name

[Ladislav Lhotka]

Juergen Schoenwaelder  
writes:


Lada, 

I do not think we can simply enlarge the value set of 
inet:domain-name, existing implementations using 
inet:domain-name may (rightfully) not expect wildcards.


On the other hand, the description says:

   It is designed to hold various types of domain names, 
   including
   names used for A or  records (host names) and other 
   records, ...


So one could expect that all values that can appear e.g. in A/ 
records of DNS zone data are supported, which is not the case. 


What we can do is to create a new definition that has a larger 
value space. We can also consider to define inet:domain-name as 
a subset of such a larger type as long as it results in the same 
value space.


My suggestion is to remove the above sentence from the description 
in the next revision, and leave the rest to DNS folks. There are 
other interesting issues, such as how to model internationalized 
domain names.


Lada



/js 

On Fri, Mar 29, 2019 at 11:20:13AM +0100, Ladislav Lhotka wrote: 
Hi,  as a follow-up to my comment during the NETMOD session, I 
want to propose the following update to the the 
inet:domain-name type. The aim is to include use cases that are 
currently rejected:  - classless in-addr.arpa delegations [RFC 
2317], i.e. labels like "128/26"  - wildcards [RFC 4592], 
e.g. "*.example.net"  OLD  
pattern 
  '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' 
+ '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'  + 
'|\.'; 
 NEW  
pattern 
  '((\*\.)?(([a-zA-Z0-9_]([a-zA-Z0-9\-/_]){0,61})?[a-zA-Z0-9]\.)*' 
+ '([a-zA-Z0-9_]([a-zA-Z0-9\-/_]){0,61})?[a-zA-Z0-9]\.?)' 
+ '|\.'; 
 Lada  --  Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 
0xB8F92B08A9F76C67 
___ 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 
 


--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] Instance-data-format - shall we define etag and last-modified annotation ?

[Juergen Schoenwaelder]

On Mon, Jul 22, 2019 at 07:23:59PM +, Balázs Lengyel wrote:
> Hello,
> 
> Restconf (rfc8040) defined to useful bits of metadata about a YANG defined
> datastore: entity-tag and the last-modified timestamp.
> 
> These can be very useful in instance data sets, however Restconf defines an
> encoding for these (as part of the http headers) that can not be used in
> instance-data-sets.

This may actually point out a flaw or omission of RFC 8527. RFC 8040
defines an entity-tag for its "unified" datastore and it says "if the
RESTCONF server is co-located with a NETCONF server, then this
entity-tag MUST be for the "running" datastore". So it is a bit
unclear what happens with other NMDA datastores and I did not quickly
find something in RFC 8527. (For example, can have a distinct etag for
?
 
> draft-ietf-netmod-yang-instance-file-format-03#section-7.2
>  section-7.2> defines metadata annotations for these two, that can be
> used in instance data
> 
>   md:annotation entity-tag {
>   type string;
>   description "Used to encode the entity-tag …";
> }
> md:annotation last-modified {
>   type yang:date-and-time;
>   description "Contains the date and time when the annotated
> instance was last modified (or created).";
> }
> 
> In order to be able to include this data, the annotations need to be defined
> in some YANG module.
> 
> The question has been raised whether 
> 
> 1.these annotations should be defined in the ietf-yang-instance-data
> module as it needs them, as that is open or
> 2.the annotations should be defined in another draft in a separate
> YANG module as any other annotation
> 
> The first option is better because the instance-data needs these
> annotations, and at this point we see no other user for the annotation, and
> in this case the ongoing instance data draft will define it
> 
> The second option is better because, if later there are other users for
> these annotations, it might be strange to reference the
> ietf-yang-instance-data module. Also why provide special treatment to these
> 2 annotations?
> 
> The authors support option 1 and don’t have the time to start a new draft to
> define these annotations.
> 
> On IETF105 in the room there was more support for option 1. 
> 
> Please indicate if you have an opinion about the choice of 1 or 2

Version -03 only defines these annotations but does not do anything
specific with these definitions. So if the annotations are defined
elsewhere, the ID is as complete as before. If entity-tag and
last-modified are actually seen as datastore properties, it would be
nice to have them defined in the NMDA documents (and it seems we
overlooked this when we did the NMDA work).

I think this needs a bit of discussion whether these are actually seen
as datastore properties. But in this case, I would lean towards option 2.

/js

-- 
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] Instance-data-format -additional simplified format to define content schema

[Balázs Lengyel]

Hello,

At the IETF 105 Netmod meeting it was stated that the flexible solution to
define the context schema inline (requested earlier on the mailing list) is
quite complex, so a fourth simpler method to define content schema inline is
needed.

The fourth method would add one more choice to “choice content-schema-spec
“

 

case simplified-inline {

  leaf-list module  {

type string {

   pattern '.+@\d{4}-\d{2}-\d{2}\.yang';

 }

 description “The list of content defining YANG 

   modules including the revision date for each. 

   Usage of this leaf-list implies the modules are 

   used without any deviations and with all features 

   supported.”;

  }

}

 

An example instant data example could be:



  read-only-acm-rules

  ietf-yang-libr...@2019-01-04.yang

  ietf-netconf-...@2012-02-22.yang
  
1776-07-04
Initial version
  
  Access control rules for a read-only role.
  ...

 

Do you like it ? Adding this case are you OK with the content-schema-spec
definition?

Regards Balazs



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

Re: [netmod] status terms in YANG and IANA registries

[Ladislav Lhotka]

On Mon, 2019-07-22 at 21:08 +0200, Juergen Schoenwaelder wrote:
> Lada,
> 
> it seems the IANA 'deprecated' and 'obsolete' as defined in RFC 8126
> section 9.6 both map to YANG's 'obsolete'.

Yes, a short-term fix (e.g. for iana-dns-class-rr-type that is now in DNSOP WG)
could indeed be to map IANA's "deprecated" to "obsolete". But of course it is
seriously confusing.

BTW, it is already weird that YANG defines "deprecated" in terms of "obsolete",
which is another status term being defined.

Lada  
> 
> /js
> 
> On Mon, Jul 22, 2019 at 02:49:18PM -0400, Ladislav Lhotka wrote:
> > Hi,
> > 
> > I haven't received any responses to my message below but, given the recent
> > discussion in DNSOP and IETF mailing list, I believe it is important to
> > address this discrepancy in order not to give ammunition to those who oppose
> > mirroring IANA registries in YANG modules.
> > 
> > Lada
> > 
> > Ladislav Lhotka  writes:
> > 
> > > Hi,
> > > 
> > > sec. 7.21.2 of RFC 7950 defines the "deprecated" and "obsolete" statuses
> > > as follows:
> > > 
> > >o  "deprecated" indicates an obsolete definition, but itpermits
> > > new/continued implementation in order to foster   interoperability
> > > with older/existing implementations.
> > > 
> > >o  "obsolete" means that the definition is obsolete andSHOULD NOT
> > > be   implemented and/or can be removed from implementations.
> > > 
> > > Then, RFC 7224 contains these instructions in the IANA Considerations
> > > section:
> > > 
> > >   "status": Include only if a registration has been   deprecated
> > > (use the value "deprecated") or obsoleted (use the
> > > value "obsolete").
> > > 
> > > However, RFC 8126 defines the meaning of the status terms in IANA
> > > registries (sec. 9.6) in the following way:
> > > 
> > >Specific entries in a registry can be marked as "obsolete"(no
> > > longer in use) or "deprecated" (use is not recommended).
> > > 
> > > I would say that "deprecated" means something else here than in YANG.
> > > For example, the RSA/MD5 algorithm in [1] is marked as "deprecated"
> > > because it was found weak, and implementing it to "foster
> > > interoperability" can hardly be recommended. Instead, "SHOULD NOT
> > > implement" applies here, too.
> > > 
> > > I think it would be good to either align the semantics of "deprecated"
> > > in YANG with IANA registries, or at least map both IANA terms to
> > > "obsolete" in YANG.
> > > 
> > > Lada
> > > 
> > > [1] 
> > > https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
> > > 
> > > --  Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
> > > 
> > > ___ 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
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

[netmod] Instance-data-format - shall we define etag and last-modified annotation ?

[Balázs Lengyel]

Hello,

Restconf (rfc8040) defined to useful bits of metadata about a YANG defined
datastore: entity-tag and the last-modified timestamp.

These can be very useful in instance data sets, however Restconf defines an
encoding for these (as part of the http headers) that can not be used in
instance-data-sets.

draft-ietf-netmod-yang-instance-file-format-03#section-7.2
 defines metadata annotations for these two, that can be
used in instance data

  md:annotation entity-tag {
  type string;
  description "Used to encode the entity-tag …";
}
md:annotation last-modified {
  type yang:date-and-time;
  description "Contains the date and time when the annotated
instance was last modified (or created).";
}

In order to be able to include this data, the annotations need to be defined
in some YANG module.

 

The question has been raised whether 

1.  these annotations should be defined in the ietf-yang-instance-data
module as it needs them, as that is open or
2.  the annotations should be defined in another draft in a separate
YANG module as any other annotation

The first option is better because the instance-data needs these
annotations, and at this point we see no other user for the annotation, and
in this case the ongoing instance data draft will define it

The second option is better because, if later there are other users for
these annotations, it might be strange to reference the
ietf-yang-instance-data module. Also why provide special treatment to these
2 annotations?

 

The authors support option 1 and don’t have the time to start a new draft to
define these annotations.

On IETF105 in the room there was more support for option 1. 

 

Please indicate if you have an opinion about the choice of 1 or 2

 

Regards Balazs

 



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

Re: [netmod] Instance data and annotations

[Ladislav Lhotka]

On Mon, 2019-07-22 at 18:46 +, Joe Clarke (jclarke) wrote:
> I’ve had a chance to digest the question asked in the meeting about should the
> last-modified and entity-tag should be defined in the instance data draft.
> 
> I feel they should be removed and moved to a separate draft.  First, the draft
> doesn’t present a use case for these.  There is already an overall timestamp
> field, which provides last-modified for the set itself.  Finally, think of
> 8040 and yang-data.  Having to pull in the instance data draft just to get
> these annotations seems wasteful.

Agreed. I simply don't see entity-tag and last-modified as something generally
useful. Out of the nine use cases mentioned in the draft, only two of them (UC5
and UC7) can potentially make use of them.

Lada  

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

Re: [netmod] status terms in YANG and IANA registries

[Juergen Schoenwaelder]

Lada,

it seems the IANA 'deprecated' and 'obsolete' as defined in RFC 8126
section 9.6 both map to YANG's 'obsolete'.

/js

On Mon, Jul 22, 2019 at 02:49:18PM -0400, Ladislav Lhotka wrote:
> Hi,
> 
> I haven't received any responses to my message below but, given the recent
> discussion in DNSOP and IETF mailing list, I believe it is important to
> address this discrepancy in order not to give ammunition to those who oppose
> mirroring IANA registries in YANG modules.
> 
> Lada
> 
> Ladislav Lhotka  writes:
> 
> > Hi,
> > 
> > sec. 7.21.2 of RFC 7950 defines the "deprecated" and "obsolete" statuses
> > as follows:
> > 
> >o  "deprecated" indicates an obsolete definition, but itpermits
> > new/continued implementation in order to foster   interoperability
> > with older/existing implementations.
> > 
> >o  "obsolete" means that the definition is obsolete andSHOULD NOT
> > be   implemented and/or can be removed from implementations.
> > 
> > Then, RFC 7224 contains these instructions in the IANA Considerations
> > section:
> > 
> >   "status": Include only if a registration has been   deprecated
> > (use the value "deprecated") or obsoleted (use the
> > value "obsolete").
> > 
> > However, RFC 8126 defines the meaning of the status terms in IANA
> > registries (sec. 9.6) in the following way:
> > 
> >Specific entries in a registry can be marked as "obsolete"(no
> > longer in use) or "deprecated" (use is not recommended).
> > 
> > I would say that "deprecated" means something else here than in YANG.
> > For example, the RSA/MD5 algorithm in [1] is marked as "deprecated"
> > because it was found weak, and implementing it to "foster
> > interoperability" can hardly be recommended. Instead, "SHOULD NOT
> > implement" applies here, too.
> > 
> > I think it would be good to either align the semantics of "deprecated"
> > in YANG with IANA registries, or at least map both IANA terms to
> > "obsolete" in YANG.
> > 
> > Lada
> > 
> > [1] 
> > https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
> > 
> > --  Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > ___ 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

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

Re: [netmod] status terms in YANG and IANA registries

[Ladislav Lhotka]

Hi,

I haven't received any responses to my message below but, given 
the recent discussion in DNSOP and IETF mailing list, I believe it 
is important to address this discrepancy in order not to give 
ammunition to those who oppose mirroring IANA registries in YANG 
modules.


Lada

Ladislav Lhotka  writes:

Hi, 

sec. 7.21.2 of RFC 7950 defines the "deprecated" and "obsolete" 
statuses as follows: 

   o  "deprecated" indicates an obsolete definition, but it 
   permits 
  new/continued implementation in order to foster 
  interoperability with older/existing implementations. 

   o  "obsolete" means that the definition is obsolete and 
   SHOULD NOT be 
  implemented and/or can be removed from implementations. 

Then, RFC 7224 contains these instructions in the IANA 
Considerations section: 

  "status": Include only if a registration has been 
  deprecated (use 
the value "deprecated") or obsoleted (use the 
value "obsolete"). 

However, RFC 8126 defines the meaning of the status terms in 
IANA registries (sec. 9.6) in the following way: 

   Specific entries in a registry can be marked as "obsolete" 
   (no longer in use) or "deprecated" (use is not recommended). 

I would say that "deprecated" means something else here than in 
YANG. For example, the RSA/MD5 algorithm in [1] is marked as 
"deprecated" because it was found weak, and implementing it to 
"foster interoperability" can hardly be recommended. Instead, 
"SHOULD NOT implement" applies here, too. 

I think it would be good to either align the semantics of 
"deprecated" in YANG with IANA registries, or at least map both 
IANA terms to "obsolete" in YANG. 

Lada 

[1] 
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml 

--  Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 
0xB8F92B08A9F76C67 

___ 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] Instance data and annotations

[Joe Clarke (jclarke)]

I’ve had a chance to digest the question asked in the meeting about should the 
last-modified and entity-tag should be defined in the instance data draft.

I feel they should be removed and moved to a separate draft.  First, the draft 
doesn’t present a use case for these.  There is already an overall timestamp 
field, which provides last-modified for the set itself.  Finally, think of 8040 
and yang-data.  Having to pull in the instance data draft just to get these 
annotations seems wasteful.

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