date:20151109

Re: [netmod] yang 1.1 last call comment resolution

2015-11-09 Thread Martin Bjorklund

Andy Bierman  wrote:
> On Mon, Nov 9, 2015 at 11:55 AM, Randy Presuhn  > wrote:
> 
> > Hi -
> >
> > >From: Martin Bjorklund 
> > >Sent: Nov 9, 2015 10:27 AM
> > >To: a...@yumaworks.com
> > >Cc: netmod@ietf.org
> > >Subject: Re: [netmod] yang 1.1 last call comment resolution
> > ...
> > >> > - Old function: unique module names
> > >> >
> > >> >   I think the resolution is to adopt the compromise solution.
> > >> >
> > >>
> > >> which was what?
> > >
> > >The (revised) proposal is:
> > >
> > >  The names of all standard modules and submodules MUST be unique.
> > >  Developers of enterprise modules are RECOMMENDED to choose names for
> > >  their modules that will have a low probability of colliding with
> > >  standard or other enterprise modules, e.g., by using the enterprise
> > >  or organization name as a prefix for the module name.  Witin a
> > >  server, all module names MUST be unique.
> >
> > This doesn't make sense from the perspective of the RFC 2119
> > guidelines.  The choice between MUST and RECOMMENDED is effectively
> > governed by the question "would failure to comply with this
> > constraint prevent successful interoperation".  It's *not* a
> > question of whether the modules are "standard" (does that include
> > non-IETF efforts?) or "enterprise".  Either they're both "MUST"
> > or they're both "SHOULD/RECOMMENDED".
> >
> >
> I agree the first sentence is odd.
> It does not include Experimental modules that bypass the WG process,
> like the time-capability module.
> 
> NEW:
> 
> Developers of YANG modules are RECOMMENDED to choose names for
> their modules that will have a low probability of colliding with
> standard or other enterprise modules, e.g., by using the enterprise
> or organization name as a prefix for the module name.  Within a
> server, all module names MUST be unique.

Ok with me.

> The YANG guidelines will say that any YANG module in
> an RFC MUST have uniqueu module and submodule names.

Ok.


/martin

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

Re: [netmod] Y10 clarification

2015-11-09 Thread Martin Bjorklund

Andy Bierman  wrote:
> On Mon, Nov 9, 2015 at 10:38 AM, Martin Bjorklund  wrote:
> 
> > Hi,
> >
> > I implemented most of the 1.1 features that affect the compiler in
> > pyang on the flight back from Yokohama.  (if you have 1.1 modules, I'd
> > appreciate if you could try it out).
> >
> > In doing this, I realized that I forgot one part of Y10 - "allow
> > restrictions on enumerations".  If we allow:
> >
> > typedef foo2 {
> >   type enumeration {
> > enum a;
> > enum b;
> >   }
> > }
> > typedef bar2 {
> >   type foo2 {
> > enum a;
> >   }
> > }
> >
> > we should also allow:
> >
> > typedef foo2 {
> >   type bits {
> > bit a;
> > bit b;
> >   }
> > }
> > typedef bar2 {
> >   type foo2 {
> > bit a;
> >   }
> > }
> >
> > It is briefly mentioned in the description of Y10.
> >
> >
> > Comments?
> >
> >
> Yet more complexity without any real use-cases?

It is a matter of removing CLRs and inconsistencies.

> How does auto-numbering work in both cases?
> 
> 
> typedef foo2 {
>   type enumeration {
> enum a;
> enum b;
>   }
> }
> 
> typedef foo3 {
>   type foo2 {
> enum b;
>   }
> }
> 
> typedef bar1 {
>   type enumeration {
> enum b;
>   }
> }
> 
> 
> What is the auto-numbering of enum 'b' in type foo3?

There is none.  The text says:

  When an existing enumeration type is restricted, the "value"
  statement MUST either have the same value as in the base type or not
  be present, in which case the value is the same as in the base type.


> What value does type foo3 have over bar1?

Unless the type has some semantics, there is none.   But when the type
has some semantics, the possibility to restrict an existing type is
useful.  If it not useful for enumerations and bits, why should we
have it for strings and ints, for example.


/martin

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

Re: [netmod] Y10 clarification

2015-11-09 Thread Andy Bierman

On Mon, Nov 9, 2015 at 1:11 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Mon, Nov 9, 2015 at 10:38 AM, Martin Bjorklund 
> wrote:
> >
> > > Hi,
> > >
> > > I implemented most of the 1.1 features that affect the compiler in
> > > pyang on the flight back from Yokohama.  (if you have 1.1 modules, I'd
> > > appreciate if you could try it out).
> > >
> > > In doing this, I realized that I forgot one part of Y10 - "allow
> > > restrictions on enumerations".  If we allow:
> > >
> > > typedef foo2 {
> > >   type enumeration {
> > > enum a;
> > > enum b;
> > >   }
> > > }
> > > typedef bar2 {
> > >   type foo2 {
> > > enum a;
> > >   }
> > > }
> > >
> > > we should also allow:
> > >
> > > typedef foo2 {
> > >   type bits {
> > > bit a;
> > > bit b;
> > >   }
> > > }
> > > typedef bar2 {
> > >   type foo2 {
> > > bit a;
> > >   }
> > > }
> > >
> > > It is briefly mentioned in the description of Y10.
> > >
> > >
> > > Comments?
> > >
> > >
> > Yet more complexity without any real use-cases?
>
> It is a matter of removing CLRs and inconsistencies.
>
> > How does auto-numbering work in both cases?
> >
> >
> > typedef foo2 {
> >   type enumeration {
> > enum a;
> > enum b;
> >   }
> > }
> >
> > typedef foo3 {
> >   type foo2 {
> > enum b;
> >   }
> > }
> >
> > typedef bar1 {
> >   type enumeration {
> > enum b;
> >   }
> > }
> >
> >
> > What is the auto-numbering of enum 'b' in type foo3?
>
> There is none.  The text says:
>
>   When an existing enumeration type is restricted, the "value"
>   statement MUST either have the same value as in the base type or not
>   be present, in which case the value is the same as in the base type.
>
>

good

Is the refinement allowed to add, remove, or change if-feature-stmts?
I don't remember seeing any text on that.



> > What value does type foo3 have over bar1?
>
> Unless the type has some semantics, there is none.   But when the type
> has some semantics, the possibility to restrict an existing type is
> useful.  If it not useful for enumerations and bits, why should we
> have it for strings and ints, for example.
>
>

so the reason to do this would be to restrict the value set but
maintain the value and position assignments.  OK




> /martin
>

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

Re: [netmod] JSON encoding of anyxml

2015-11-09 Thread Andy Bierman

Hi,

I am not in favor of anything XML or JSON specific in YANG.
In reality, nobody uses anyxml as a configuration data node,
so an improper roundtrip translation from JSON to XML
is not going to happen.

Encoding anyxml as a string is not going to happen either.
Not sure what the difference between 'anyxml' and 'type string'
is at that point.

Why does YANG even need a special type of leaf that is a blob of XML?
Can't a single-quoted string serve that purpose?


Andy


On Mon, Nov 9, 2015 at 2:39 PM, Robert Varga  wrote:

> On 11/05/2015 09:56 AM, Ladislav Lhotka wrote:
>
>> Given the resolution of Y34 in YANG 1.1, Martin's proposal to encode
>>> >anyxml as a string that has XML inside makes sense.
>>>
>> The possibility of sending arbitrary (non-YANG) data in the native
>> encoding can occassionally be useful, and even more so in JSON. For
>> example, I have to work with a JSON-based format for specifying DNSSEC
>> signing policies. While my plan is to eventually replace this format with
>> YANG-modelled data, it would help me, as an interim solution, to simply
>> send the data in the legacy format. That's why I want to retain the
>> existing rules for JSON encoding of anyxml, unless something else is
>> available. Sending XML documents as strings is still possible although IMO
>> next to useless.
>>
>
> I fear requiring JSON in anyxml will render RESTCONF-to-NETCONF proxies
> non-transparent in case the sender (a NETCONF NE) and receiver (an RESTCONF
> application) have out-of-band knowledge of the data being sent over anyxml.
> Given the proxy does not have this knowledge, it cannot reliably deal with
> lists, as they lack a container element in XML encoding.
>
> Can we perhaps indicate the encoding of the anyxml data chunk in JSON as a
> separate well-known attribute?
>
> Bye,
> Robert
>
> ___
> 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] Y10 clarification

2015-11-09 Thread Martin Bjorklund

Hi,

I implemented most of the 1.1 features that affect the compiler in
pyang on the flight back from Yokohama.  (if you have 1.1 modules, I'd
appreciate if you could try it out).

In doing this, I realized that I forgot one part of Y10 - "allow
restrictions on enumerations".  If we allow:

typedef foo2 {
  type enumeration {
enum a;
enum b;
  }
}
typedef bar2 {
  type foo2 {
enum a;
  }
}

we should also allow:

typedef foo2 {
  type bits {
bit a;
bit b;
  }
}
typedef bar2 {
  type foo2 {
bit a;
  }
}

It is briefly mentioned in the description of Y10.


Comments?


/martin

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

Re: [netmod] yang 1.1 last call comment resolution

2015-11-09 Thread Andy Bierman

On Mon, Nov 9, 2015 at 11:55 AM, Randy Presuhn  wrote:

> Hi -
>
> >From: Martin Bjorklund 
> >Sent: Nov 9, 2015 10:27 AM
> >To: a...@yumaworks.com
> >Cc: netmod@ietf.org
> >Subject: Re: [netmod] yang 1.1 last call comment resolution
> ...
> >> > - Old function: unique module names
> >> >
> >> >   I think the resolution is to adopt the compromise solution.
> >> >
> >>
> >> which was what?
> >
> >The (revised) proposal is:
> >
> >  The names of all standard modules and submodules MUST be unique.
> >  Developers of enterprise modules are RECOMMENDED to choose names for
> >  their modules that will have a low probability of colliding with
> >  standard or other enterprise modules, e.g., by using the enterprise
> >  or organization name as a prefix for the module name.  Witin a
> >  server, all module names MUST be unique.
>
> This doesn't make sense from the perspective of the RFC 2119
> guidelines.  The choice between MUST and RECOMMENDED is effectively
> governed by the question "would failure to comply with this
> constraint prevent successful interoperation".  It's *not* a
> question of whether the modules are "standard" (does that include
> non-IETF efforts?) or "enterprise".  Either they're both "MUST"
> or they're both "SHOULD/RECOMMENDED".
>
>
I agree the first sentence is odd.
It does not include Experimental modules that bypass the WG process,
like the time-capability module.

NEW:

Developers of YANG modules are RECOMMENDED to choose names for
their modules that will have a low probability of colliding with
standard or other enterprise modules, e.g., by using the enterprise
or organization name as a prefix for the module name.  Within a
server, all module names MUST be unique.


The YANG guidelines will say that any YANG module in
an RFC MUST have uniqueu module and submodule names.



 Randy
>


Andy


>
> ___
> 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] Y10 clarification

2015-11-09 Thread Andy Bierman

On Mon, Nov 9, 2015 at 10:38 AM, Martin Bjorklund  wrote:

> Hi,
>
> I implemented most of the 1.1 features that affect the compiler in
> pyang on the flight back from Yokohama.  (if you have 1.1 modules, I'd
> appreciate if you could try it out).
>
> In doing this, I realized that I forgot one part of Y10 - "allow
> restrictions on enumerations".  If we allow:
>
> typedef foo2 {
>   type enumeration {
> enum a;
> enum b;
>   }
> }
> typedef bar2 {
>   type foo2 {
> enum a;
>   }
> }
>
> we should also allow:
>
> typedef foo2 {
>   type bits {
> bit a;
> bit b;
>   }
> }
> typedef bar2 {
>   type foo2 {
> bit a;
>   }
> }
>
> It is briefly mentioned in the description of Y10.
>
>
> Comments?
>
>
Yet more complexity without any real use-cases?
How does auto-numbering work in both cases?


typedef foo2 {
  type enumeration {
enum a;
enum b;
  }
}

typedef foo3 {
  type foo2 {
enum b;
  }
}

typedef bar1 {
  type enumeration {
enum b;
  }
}


What is the auto-numbering of enum 'b' in type foo3?
What value does type foo3 have over bar1?



> /martin
>


Andy


>
> ___
> 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] Y10 clarification

2015-11-09 Thread Martin Bjorklund

Andy Bierman  wrote:
> On Mon, Nov 9, 2015 at 1:11 PM, Martin Bjorklund  wrote:
> 
> > Andy Bierman  wrote:
> > > On Mon, Nov 9, 2015 at 10:38 AM, Martin Bjorklund 
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > I implemented most of the 1.1 features that affect the compiler in
> > > > pyang on the flight back from Yokohama.  (if you have 1.1 modules, I'd
> > > > appreciate if you could try it out).
> > > >
> > > > In doing this, I realized that I forgot one part of Y10 - "allow
> > > > restrictions on enumerations".  If we allow:
> > > >
> > > > typedef foo2 {
> > > >   type enumeration {
> > > > enum a;
> > > > enum b;
> > > >   }
> > > > }
> > > > typedef bar2 {
> > > >   type foo2 {
> > > > enum a;
> > > >   }
> > > > }
> > > >
> > > > we should also allow:
> > > >
> > > > typedef foo2 {
> > > >   type bits {
> > > > bit a;
> > > > bit b;
> > > >   }
> > > > }
> > > > typedef bar2 {
> > > >   type foo2 {
> > > > bit a;
> > > >   }
> > > > }
> > > >
> > > > It is briefly mentioned in the description of Y10.
> > > >
> > > >
> > > > Comments?
> > > >
> > > >
> > > Yet more complexity without any real use-cases?
> >
> > It is a matter of removing CLRs and inconsistencies.
> >
> > > How does auto-numbering work in both cases?
> > >
> > >
> > > typedef foo2 {
> > >   type enumeration {
> > > enum a;
> > > enum b;
> > >   }
> > > }
> > >
> > > typedef foo3 {
> > >   type foo2 {
> > > enum b;
> > >   }
> > > }
> > >
> > > typedef bar1 {
> > >   type enumeration {
> > > enum b;
> > >   }
> > > }
> > >
> > >
> > > What is the auto-numbering of enum 'b' in type foo3?
> >
> > There is none.  The text says:
> >
> >   When an existing enumeration type is restricted, the "value"
> >   statement MUST either have the same value as in the base type or not
> >   be present, in which case the value is the same as in the base type.
> >
> >
> 
> good
> 
> Is the refinement allowed to add, remove, or change if-feature-stmts?
> I don't remember seeing any text on that.

The refine statement cannot address individual enums/bits (it can only
address structure) so the answer is that it is not possible to change
if-feature on enums/bits in refinements.

> > > What value does type foo3 have over bar1?
> >
> > Unless the type has some semantics, there is none.   But when the type
> > has some semantics, the possibility to restrict an existing type is
> > useful.  If it not useful for enumerations and bits, why should we
> > have it for strings and ints, for example.
> >
> >
> 
> so the reason to do this would be to restrict the value set but
> maintain the value and position assignments.  OK



/martin

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

Re: [netmod] yang 1.1 last call comment resolution

2015-11-09 Thread Ladislav Lhotka

Andy Bierman  writes:

> On Thu, Nov 5, 2015 at 1:20 AM, Martin Bjorklund  wrote:
>
>> Juergen Schoenwaelder  wrote:
>>

...

>> > - Old function: make auto-delete for choice and when non-NETCONF specific
>> >
>> >   Revision -08 of YANG 1.1 defines auto-deletion as a property of the
>> >   NETCONF edit-config operation and the issue is whether this
>> >   auto-deletion behaviour is a NETCONF specific edit-config property
>> >   or a general YANG datastore validation property that equally applies
>> >   to RESTCONF, COMI, ...
>> >
>> >   It is unclear where we are with this. More input would be welcome.
>>
>> I think it would be very confusing if e.g. RESTCONF behaved
>> differently than NETCONF.  However, I can see how it might make sense
>> for a server on a constrained device to not do auto-delete - but OTOH
>> such a server probably don't do "must" and "when" checking at all.
>> And it might have specialized data models that don't use such
>> constructs.
>>
>>
>>
> I don't like any of the NETCONF-specific text in YANG 1.1.
> YANG datastore constraints refer to a conceptual "valid datastore".
> There is no reason to talk about specific protocol behavior,
> except that we are too lazy to put protocol text where it belongs.

Agreed.

>
> It should at least be clear that datastore validation does not at all depend
> on how the datastore contents were changed.  The current text does
> not even fully support , so it does not even support NETCONF,
> let alone RESTCONF.
>
> IMO auto-deletion should not be changed.
> It works fine and the only issue that has ever come up is
> auto-deleting data from an edit-config payload.

IMO a scarier prospect is the ripple effect where an edit-config causes
some remote part(s) of the data tree to disappear.

I looked into the existing uses of "when" and none of them seems to be
really designed for the auto-deletion option. That is, auto-deletion is
either impossible (e.g. if "when" involves just a list key) or otherwise
it would clearly be an operator error (e.g. if interface type is changed
by mistake).

Lada


>
>
>
>
>
> /martin
>>
>>
>
> Andy
>
>
>> ___
>> 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

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

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

Re: [netmod] yang 1.1 last call comment resolution

Re: [netmod] Y10 clarification

Re: [netmod] Y10 clarification

Re: [netmod] JSON encoding of anyxml

[netmod] Y10 clarification

Re: [netmod] yang 1.1 last call comment resolution

Re: [netmod] Y10 clarification

Re: [netmod] Y10 clarification

Re: [netmod] yang 1.1 last call comment resolution

9 matches

Site Navigation

Mail list logo

Footer information