Subject: Re: [netmod] system-creatable

From: Gerhard Muenz <[email-masked]>
Date: Thu, 22 Oct 2009 10:09:46 +0200

Hi,

>>> Part of my problem may be a failure of imagination. I have trouble
>>> imagining a field for which the data model requires that the field
>>> exist the system can reliably know the value and the client can not
>>> reasonably be expected to know the value.
> 
> Joel
> 
> Gerhard said that this was a use case for IPFIX at the back end of
> August last year. As one of the few people to have used YANG in
> anger, I take that as a clear requirement.

Correct. In IPFIX, we always say something like:

    "If not configured, the Selector ID is assigned by the Monitoring
    Device."

in the description clause. We could add a MUST in these sentences to 
make it clear.

I went through the IPFIX configuration data model and found two reasons 
for system-created-if-not-provided-by-user parameters:

- device-specific defaults
   Example: sendBufferSize (of a socket)
   IMO, it does not make sense to set a default value in the data model.
   It does not make sense to make this parameter mandatory, either.

- logical identifiers which are mapped to (physical) resources
   Example: observationPointId
   This ID is mapped to an ifIndex or an entPhysicalIndex.
   The user might be interested in configuring this mapping. In other
   cases, however, he may let the device choose an appropriate value.
   In the later case, the user will be relieved from coping for the
   uniqueness of observationPointIds.

That's it.

Regards,
Gerhard

> I disagree with the current formulation of system-creatable on this
> (I want MUST and not MAY), on restricting the system to be able
> to create only nodes with system-creatable (that for me came from
> nowhere) and with the leaf only existing after validation and so not
> being available to any of the extra logic that YANG adds:-(
> 
> So as currently formulated, I find it of no additional value.
> Tom Petch
> 
>>> 
>>> The userid case is not actually a good example of this, because the
>>>  system may not need userids. As something the system may create,
>>> if it needs them, it makes sense to me. As a global requirement
>>> that the user model MUST have valid userids, I don't follow it.
>>> (Requiring that IDs, if they are used, be unique, makes sense
>>> because good security practice says to avoid confusing users.)
>>> 
>>> We can give up on all notion of knowing what the system may modify,
>>> and take the view that since multi-manager means that you can never
>>> know anyway, the client effectively must refresh his model before
>>> beginning any operation, and after any commit if operation is
>>> continuing. But folks have repeatedly said that thye do not want
>>> clients to have to fetch everything in sight. (There are meaningful
>>> alternatives for dealing with multi-manager, but they will not cope
>>> with system-created very well.)
>>> 
>>> Yours, Joel
>>> 
>>> Randy Presuhn wrote:
>>>>> Hi -
>>>>> 
>>>>>>> From: "Joel M. Halpern" <[email-masked]> To: "Randy
>>>>>>> Presuhn" <[email-masked]> Sent: Monday,
>>>>>>> October 19, 2009 1:30 PM Subject: Re: [netmod]
>>>>>>> system-creatable
>>>>>>> 
>>>>>>> I do not follow your reasoning about the relationship
>>>>>>> between whether
>>>>>>> S-C is a must and the user-id example.
>>>>>>> 
>>>>>>> If user-id is mandatory, then the client better be prepared
>>>>>>> to create it.
>>>>> 
>>>>> It is not mandatory, at least not in the Yang sense.
>>>>> 
>>>>>>> If user-id is optional, then clients do not have to create
>>>>>>> it if they
>>>>>>> don't want to.
>>>>> 
>>>>> Agreed.
>>>>> 
>>>>>>> If user-id is optional and system-createable, then the
>>>>>>> client is not
>>>>>>> required to create it, but the client should be aware that
>>>>>>> the system
>>>>>>> may choose to assign it a value, for example, if it uses
>>>>>>> userids.
>>>>> 
>>>>> replace "may" with "MUST".
>>>>> 
>>>>>>> I suppose we could add the mixed case of a leaf declared as
>>>>>>> both mandatory and system-createable, to indicate that the
>>>>>>> system is required
>>>>>>> to create it if the client does not. The verbiage would be
>>>>>>> pretty strange, but at least we don't use the optional case
>>>>>>> that I think is useful.
>>>>> 
>>>>> I don't want to go there.
>>>>> 
>>>>> I think the confusion may come from the shorthand. When I say 
>>>>> "MAY" and "MUST" here, I am referring to the replacement of the
>>>>> "MAY" in the proposed text with "MUST" The "MAYs" in the 
>>>>> proposed text all had to do with *server* requirements, not 
>>>>> client requirements.
>>>>> 
>>>>> Randy
>>>>> 
>>>>> 
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 22 Oct 2009 03:39:53 -0700

>   uniqueness of observationPointIds.

I just reviewed http://www.ietf.org/id/draft-ietf-ipfix-configuration-model-03.txt
and I can't find any indication whatsoever that the objects marked
as "If not configured..." cannot be selected by the server during
the edit-config to candidate.  None of these objects seem to have the
special property shared with the 'uid' example of being unknowable
until after the commit.  (Even in the uid example,
the server could reserve a value during the edit-config.)

IMO, s-c is currently unworkable because of this 'invisible to validation'
requirement.  It seems like an extreme corner-case.  The server MUST
figure out what value to use during the edit-commit, and s-c leafs
MUST be part of candidate validation.  I do not see any problem
with ipfix-psamp.yang wrt/ this requirement.

>> So as currently formulated, I find it of no additional value.

The only minor value of the current s-c is if it is set to false,
then the client knows the server will not create a leaf
that the client doesn't care about anyway.

>> Tom Petch

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 22 Oct 2009 09:24:49 -0400

>with ipfix-psamp.yang wrt/ this requirement.

If s-c leafs are required for validation, then the client
cannot validate config before sending it to the server.  Since
we want clients to be able to validate config before sending
it to the server, we have to say that s-c leafs are not created
until after validation.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Thu, 22 Oct 2009 10:23:46 -0400

>   It does not make sense to make this parameter mandatory, either.

Are you really wanting device-specific defaults to appear
as part of the config data?

>   uniqueness of observationPointIds.

I think this one fits in the "twin leafs" discussion, where you
have one leaf that allows the user to configure a fixed value
(via a config=true node) and a distinct leaf where the current
value can be retrieve (via a config=false node).  

Thanks,
 Phil

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 22 Oct 2009 17:01:24 +0200

Hello,
According to an earlier suggestion:

The device MUST create s-c values in a way, that the configuration remains valid. This ensures 
that although they are not part of the validation, it is ensured that the configuration stays 
valid. Is this acceptable?

In rare cases you should be able to set data that makes it impossible for the device to set 
valid s-c values, but that seems to need some really strange rules. Anyway YANG rules will 
never be able to cover everything.

Balazs

On 10/22/09 15:24, Phil Shafer wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320                  email: [email-masked]

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 22 Oct 2009 18:19:46 +0200

Hi Joel,

Joel M. Halpern wrote:
> I had forgotten about some of this, and I apologize.
> With regard to the IDs (like observationPointId), for constructs being 
> defined (not for references, etc), what is the use case for user 
> definition of the ID?  Thre may well be a need for such, but if not, 
> then that field could be state data, making things much simpler.

Yes, probably that's the way to go.

I was thinking of one use-case:

selectionSequenceId defines a filter chain in the monitoring device.
The ID value reappears in the exported data, labeling the flows whose 
packets passed this filter chain. So, if I configure the 
selectionSequenceId, I know what I have to look for in the output.

But I might as well retrieve the ID value assigned by the device (as 
state parameter) and than search for this value in the output. The 
retrieval of the state parameter is on more step for the user, but not a 
big deal.

Regards,
Gerhard

> Yours,

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 22 Oct 2009 18:24:09 +0200

> as part of the config data?

I don't care. I, as a data model writer, just do not want to define an 
arbitrary default value. The vendor should define one for his device.

If there is a way to force vendors to provide a deviation or whatever 
defining vendor-specific defaults for these specific leafs, I'm also 
fine with that.

Regards,
Gerhard

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 22 Oct 2009 09:33:20 -0700

Hi -

> From: "Phil Shafer" <[email-masked]>
> To: "Andy Bierman" <[email-masked]>
> Cc: <[email-masked]>; "Gerhard Muenz" <[email-masked]>
> Sent: Thursday, October 22, 2009 6:24 AM
> Subject: Re: [netmod] system-creatable
...
> it to the server, we have to say that s-c leafs are not created
...

There's validation, and then there's validation.  Talking about validation
as though it only happens once is not helpful.  Way back in the
rcdml discussions, it quickly became clear that there were multiple
kinds (or phases) of validation, differing primarily in the completeness
of the information available to the validating entity.  There are things that
a client simply is not in a position to validate, and s-c items are just
one of many examples.  It might be helpful to the discussion to be
explicit about the possible kinds of validations, and their limitations.

Randy

---

From: "tom.petch" <[email-masked]>
Date: Fri, 23 Oct 2009 14:38:39 +0200

---- Original Message ----- 
From: "Randy Presuhn" <[email-masked]>
Sent: Thursday, October 22, 2009 6:33 PM
 
> explicit about the possible kinds of validations, and their limitations.

Absolutely.  What we need is a 'validate and fix' where the server provides,
as and where permitted by YANG, all the values needed to make the config
in candidate valid.  S-C nodes could be part of this and could then be referred
to by all the logic that YANG adds to data modelling.

Then a second stage would be commit to running with all the S-C nodes
already provided as part of the 'validate and fix'.

Edits must then be different (quite right too - people who edit running
configurations deserve all that happens to them :-)

Tom Petch

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 Oct 2009 16:27:37 +0200

> configurations deserve all that happens to them :-)

I agree. I tried to outline a validation procedure in the DSDL mapping
draft, including two different phases - "full" and "noref" (the latter
doesn't check referential integrity). However, I believe these issues
are not specific to DSDL validation, so they should be addressed
probably in the architecture draft.

The split between our two camps probably has to do with the dual role
that a data model plays - validation capabilities versus guidelines for
server implementors. I do admit I put emphasis on the former role.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C