Subject: Re: [Netconf] Pre-13 Notification (take 2)

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Thu, 5 Jun 2008 00:57:42 +0200

Andy and David,

Sharon was/is trying to clarify some text in the security 
considerations section in order to address comments from 
the IESG review.

I don't think we want to go through a long process of
debating all the option we have for notifications. We do not 
have a (satndardized) ACM for NETCONF, and so we do not have 
to be explicit as to what exactly happens in all cases,
do we? We have to warn/explain to the user what he needs
to look out for when supporting enabling notifications.

If you are not happy with the new text, can you then pls 
propose your text (as a minimum).

Bert Wijnen 

> -----Oorspronkelijk bericht-----
> Van: [email-masked] [mailto:[email-masked]]Namens
> Andy Bierman
> Verzonden: vrijdag 30 mei 2008 21:30
> Aan: David B Harrington
> CC: [email-masked]
> Onderwerp: Re: [Netconf] Pre-13 Notification (take 2)
> 
> 
> David B Harrington wrote:
> >  
> > 
> >> The text is also confusing me because access control for <get>
> >> and <notification> are not the same at all.  A <get> response
> >> will only exclude the unauthorized nested elements, and return
> >> any other content the user is authorized to view.
> >>
> >> A <notification> must be buffered by the agent so that if any
> >> unauthorized sub-nodes are encountered, the entire <notification>
> >> is considered unauthorized (and dropped for that session).
> >>
> >> This makes some assumptions about how/why the
> >> internal ACM is behaving in certain ways.  Why iFrom [email-masked]  Wed Jun  4 15:57:39 2008
From: "Bert Wijnen - IETF" <[email-masked]>
To: "Andy Bierman" <[email-masked]>,
	"David B Harrington" <[email-masked]>
Date: Thu, 5 Jun 2008 00:57:42 +0200
Importance: Normal
Cc: [email-masked]
Subject: Re: [Netconf] Pre-13 Notification (take 2)
Sender: [email-masked]

Andy and David,

Sharon was/is trying to clarify some text in the security 
considerations section in order to address comments from 
the IESG review.

I don't think we want to go through a long process of
debating all the option we have for notifications. We do not 
have a (satndardized) ACM for NETCONF, and so we do not have 
to be explicit as to what exactly happens in all cases,
do we? We have to warn/explain to the user what he needs
to look out for when supporting enabling notifications.

If you are not happy with the new text, can you then pls 
propose your text (as a minimum).

Bert Wijnen 

> -----Oorspronkelijk bericht-----
> Van: [email-masked] [mailto:[email-masked]]Namens
> Andy Bierman
> Verzonden: vrijdag 30 mei 2008 21:30
> Aan: David B Harrington
> CC: [email-masked]
> Onderwerp: Re: [Netconf] Pre-13 Notification (take 2)
> 
> 
> David B Harrington wrote:
> >  
> > 
> >> The text is also confusing me because access control for <get>
> >> and <notification> are not the same at all.  A <get> response
> >> will only exclude the unauthorized nested elements, and return
> >> any other content the user is authorized to view.
> >>
> >> A <notification> must be buffered by the agent so that if any
> >> unauthorized sub-nodes are encountered, the entire <notification>
> >> is considered unauthorized (and dropped for that session).
> >>
> >> This makes some assumptions about how/why the
> >> internal ACM is behaving in certain ways. s is OK
> >> for a <get> to drop only the unauthorized content, but
> >> it is not OK for a <notification> to do the same thing,
> >> even for the exact same subset of data?
> > 
> > I agree with this concern about embedded assumptions.
> > 
> > In SNMPv3, if a principal is not allowed access to all the varbinds in
> > the notification, the notification gets dropped. This makes sense in
> > SNMP because we define the varbinds that must be in the notification
> > (although even if an appended varbind is not authorized the whole
> > thing gets dropped). 
> > 
> > I am not sure this must-drop-behavior should be a requirement for the
> > **protocol** definition of Netconf notifications, especially if
> > Netconf notifications might carry data from SNMP or syslog. This
> > should probably be a function of the access control model(s), not the
> > protocol.
> 
> I am also concerned about a MUST drop directive cast-in-stone,
> without much thought about the overall access control model or
> security use cases.
> 
> Clearly, the <get> method needs to work as currently defined.
> NETCONF would be completely unusable if an operator had to
> specify exact leafs to retrieve because access control on some
> nested subtree causes normal <get> filters to be unusable.
> 
> Won't the all-or-nothing restriction cause similar problems
> for operators wrt/ notification receiver applications?
> Won't this force data model writers to create multiple
> versions of any notification that includes some (but not all)
> sensitive data?
> 
> SNMP is somewhat different because the varbinds are all leafs
> and non-extensible.  NETCONF content can be complex, nested,
> and include multiple namespaces.  The likelihood that a
> complex structure sill have some optional (yet sensitive) data
> is much higher. SNMP is UDP-based, and very few mandatory varbinds
> are usually defined for a notification.  If implementors take
> advantage of NETCONF's unlimited notification payload size,
> this all-or-nothing restriction is going to become a DM design
> factor.  This would be a serious protocol design flaw.
> 
> It should be up to the network administrator, not the protocol,
> to decide how access control should handle notification content
> (and all other content).
> 
> At a minimum, the draft should explain in detail why the
> entire notification must be dropped but no access control
> restrictions for other types of NETCONF operations exist at all.
> Explain the access control model in detail or take out the
> ad-hoc bits and pieces.
> 
> Andy
> 
> 
> > 
> > --
> > There may be a case for arguing that notifications are different than
> > <gets>. If a system reports on an event, specifying certain related
> > information, and the subscription only allows the operator to see a
> > subset of the information, might that be misleading to the operator?
> > In SNMPv1, we had to deal with implementations that, when they didn't
> > support a counter, returned a zero value. This was misleading because,
> > even if the underlying functionality was operating, and the events
> > that were to be counted (e.g., packets out) occurred, the SNMP
> > counters still said '0'. We want to avoid misleading the operator. 
> > 
> > Would reporting only part of the data, and not reporting exceptions
> > for the missing data, be worse than reporting no data for some events?
> > Would reporting exceptions for the missing data be a problem because
> > it gives an attacker information about what a user is not authorized
> > to see?
> > 
> > Maybe the data model for notification definitions should be able to
> > specify whether 1) all info must be authorized or do not send, or 2)
> > unauthorized data should have an exception reported, or 3) partial
> > data is acceptable.
> > 
> > I think an access control model is a better place than either the
> > protocol or the data model to make such a determination. I can
> > envision wanting to let the helpdesk (support level 1) receive an
> > alert with only partial information to make him aware that an event
> > occurred, while a level 2 support  Why is is OK
> >> for a <get> to drop only the unauthorized content, but
> >> it is not OK for a <notification> to do the same thing,
> >> even for the exact same subset of data?
> > 
> > I agree with this concern about embedded assumptions.
> > 
> > In SNMPv3, if a principal is not allowed access to all the varbinds in
> > the notification, the notification gets dropped. This makes sense in
> > SNMP because we define the varbinds that must be in the notification
> > (although even if an appended varbind is not authorized the whole
> > thing gets dropped). 
> > 
> > I am not sure this must-drop-behavior should be a requirement for the
> > **protocol** definition of Netconf notifications, especially if
> > Netconf notifications might carry data from SNMP or syslog. This
> > should probably be a function of the access control model(s), not the
> > protocol.
> 
> I am also concerned about a MUST drop directive cast-in-stone,
> without much thought about the overall access control model or
> security use cases.
> 
> Clearly, the <get> method needs to work as currently defined.
> NETCONF would be completely unusable if an operator had to
> specify exact leafs to retrieve because access control on some
> nested subtree causes normal <get> filters to be unusable.
> 
> Won't the all-or-nothing restriction cause similar problems
> for operators wrt/ notification receiver applications?
> Won't this force data model writers to create multiple
> versions of any notification that includes some (but not all)
> sensitive data?
> 
> SNMP is somewhat different because the varbinds are all leafs
> and non-extensible.  NETCONF content can be complex, nested,
> and include multiple namespaces.  The likelihood that a
> complex structure sill have some optional (yet sensitive) data
> is much higher. SNMP is UDP-based, and very few mandatory varbinds
> are usually defined for a notification.  If implementors take
> advantage of NETCONF's unlimited notification payload size,
> this all-or-nothing restriction is going to become a DM design
> factor.  This would be a serious protocol design flaw.
> 
> It should be up to the network administrator, not the protocol,
> to decide how access control should handle notification content
> (and all other content).
> 
> At a minimum, the draft should explain in detail why the
> entire notification must be dropped but no access control
> restrictions for other types of NETCONF operations exist at all.
> Explain the access control model in detail or take out the
> ad-hoc bits and pieces.
> 
> Andy
> 
> 
> > 
> > --
> > There may be a case for arguing that notifications are different than
> > <gets>. If a system reports on an event, specifying certain related
> > information, and the subscription only allows the operator to see a
> > subset of the information, might that be misleading to the operator?
> > In SNMPv1, we had to deal with implementations that, when they didn't
> > support a counter, returned a zero value. This was misleading because,
> > even if the underlying functionality was operating, and the events
> > that were to be counted (e.g., packets out) occurred, the SNMP
> > counters still said '0'. We want to avoid misleading the operator. 
> > 
> > Would reporting only part of the data, and not reporting exceptions
> > for the missing data, be worse than reporting no data for some events?
> > Would reporting exceptions for the missing data be a problem because
> > it gives an attacker information about what a user is not authorized
> > to see?
> > 
> > Maybe the data model for notification definitions should be able to
> > specify whether 1) all info must be authorized or do not send, or 2)
> > unauthorized data should have an exception reported, or 3) partial
> > data is acceptable.
> > 
> > I think an access control model is a better place than either the
> > protocol or the data model to make such a determination. I can
> > envision wanting to let the helpdesk (support level 1) receive an
> > alert with only partial information to make him aware that an event
> > occurred, while a level 2 superson can subscribe for the same
> > notification, and get more (potentially sensitive) information in the
> > notification he receives. 
> > 
> > But I am not an operator, and operators may be fine with an
> > all-or-nothing decision.
> > 
> > dbh
> > 
> > 
> > 
> > 
> > 
> 
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
> 
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

pport person can subscribe for the same
> > notification, and get more (potentially sensitive) information in the
> > notification he receives. 
> > 
> > But I am not an operator, and operators may be fine with an
> > all-or-nothing decision.
> > 
> > dbh
> > 
> > 
> > 
> > 
> > 
> 
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
> 
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Wed, 04 Jun 2008 17:36:34 -0700

> propose your text (as a minimum).

I am not happy with the text because typical notification
receiver deployment (via a dispatcher) may break because of 3 words.
Even the <config-change> use-case that Sharon proposed breaks
if the tree showing the edit-config or commit changes contains
any restricted config.  IMO, the operator should decide if
circumstances favor pruning a restricted subtree, rather
than dropping the whole notification.

pg 35, para 7, sentence 2:

OLD:

    If a user is not
    authorized to view all elements in the content of the notification,
    the notification is not sent to that user.
                     ^^^^^^

NEW:

    If a user is not
    authorized to view all elements in the content of the notification,
    the notification SHOULD NOT be sent to that user.
                     ^^^^^^^^^^^^^

This new text leaves some room for conditions under which
it would be OK to prune instead of drop.  When the WG
adds a coherent and well-thought-out ACM in the future
for all of NETCONF (not just one verb), this issue might
come up again.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 04 Jun 2008 17:36:34 -0700

OLD:

    If a user is not

NEW:

    If a user is not

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 4 Jun 2008 20:39:42 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Bert Wijnen - IETF" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, June 04, 2008 5:36 PM
...
>     the notification SHOULD NOT be sent to that user.
...

I don't see how the new text permits what you seem to want.
It's still phrased in terms of whether the notification is sent,
not in terms of permissible transformations of the notification
payload, which is what you seem to be talking about.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 4 Jun 2008 20:39:42 -0700

Hi -

...
...

Randy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 05 Jun 2008 04:08:49 -0700

---

From: Andy Bierman <[email-masked]>
Date: Thu, 05 Jun 2008 04:08:49 -0700

Randy Presuhn wrote:
>> it would be OK to prune instead of drop.  When t>> adds a coherent and well-thought-out ACM in the future

I prefer to remove this sentence from the draft entirely.
If I am the only one who thinks that blindly following
what SNMP did is a bad idea, then fine.

I ask newbie security questions like "how come pruning data
is fine for <get> but not for <notification>?"  Clearly, any
data that can be retrieved with a <get> can also be transported
as a <notification>, yet they generate very different security
concerns within the IESG.

Andy

he WG
> payload, which is what you seem to be talking about.

I prefer to remove this sentence from the draft entirely.
If I am the only one who thinks that blindly following
what SNMP did is a bad idea, then fine.

I ask newbie security questions like "how come pruning data
is fine for <get> but not for <notification>?"  Clearly, any
data that can be retrieved with a <get> can also be transported
as a <notification>, yet they generate very different security
concerns within the IESG.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Jun 2008 13:15:14 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> is fine for <get> but not for <notification>?"

I agree with Andy that the text should not preclude pruning data in
notifications.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Jun 2008 13:15:14 +0200 (CEST)

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 05 Jun 2008 14:26:46 +0200

I also agree with Andy and Martin.
Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 05 Jun 2008 14:26:46 +0200

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 5 Jun 2008 11:22:24 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, June 05, 2008 4:08 AM
...
...

I'm agnostic on the question.  My concern was simply that the proposed
edit did not appear to have the desired effect.

Regarding the underlying question of "pruning" notification payloads,
I think it's a question not just of security policy, but also of what
conformance to a notification type means.  If any arbitrary piece of
a notification payload may be omitted, then the bar for claiming to
support a particular notification is rather low.  This might be ok,
but it should be a conscious decision.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 5 Jun 2008 11:22:24 -0700

Hi -

...
...

Randy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 05 Jun 2008 13:23:50 -0700

> edit did not appear to have the desired effect.

I know.  I realized a sentence was missing after I sent
the original mail:

    If a user is not authorized to view all elements in the
    content of the notification, the notification SHOULD NOT
    be sent to that user.  The agent MUST NOT include any content
    which the user is not authorized to view.

> RegaFrom [email-masked]  Thu Jun  5 13:23:58 2008
Date: Thu, 05 Jun 2008 13:23:50 -0700
From: Andy Bierman <[email-masked]>
To: Randy Presuhn <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Pre-13 Notification (take 2)
Sender: [email-masked]

> edit did not appear to have the desired effect.

I know.  I realized a sentence was missing after I sent
the original mail:

    If a user is not authorized to view all elements in the
    content of the notification, the notification SHOULD NOT
    be sent to that user.  The agent MUST NOT include any content
    which the user is not authorized to view.

rding the underlying question of "pruning" notification payloads,
> but it should be a conscious decision.

The problem is data-model dependent, not protocol-dependent.
That is what Dave and I have been trying to point out.
When a proper ACM is created for NETCONF, the WG may in fact
decide on some constraints and control knobs, or decide
not to ever allow pruning of notification data.

I guess I am clueless on security, but I fail to
see how a manager application would handle pruned data
from a <get> differently than from a <notification>.
If access control is in effect, and some data is hidden
from the user's view, than the application either breaks
or copes with the partial data set.  I don't see what
<get> vs. <notification> has to do with it.

Andy

> but it should be a conscious decision.

The problem is data-model dependent, not protocol-dependent.
That is what Dave and I have been trying to point out.
When a proper ACM is created for NETCONF, the WG may in fact
decide on some constraints and control knobs, or decide
not to ever allow pruning of notification data.

I guess I am clueless on security, but I fail to
see how a manager application would handle pruned data
from a <get> differently than from a <notification>.
If access control is in effect, and some data is hidden
from the user's view, than the application either breaks
or copes with the partial data set.  I don't see what
<get> vs. <notification> has to do with it.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 07 Jun 2008 08:45:29 -0700

Hi Randy,

>> but it should be a conscious decision.

I misinterpreted your comment.
Conformance levels for data model definitions
and operational decisions to restrict data access for better
security are two very different issues.

Data is not really omitted.  Think of the <get> and <get-config>
operations as requests to retrieve the (possibly filtered)
subset of the configuration database that the user is authorized
to view.  IMO, the access control is conceptually applied to
the target database before the <get> filters.  That means an
agent would never return an 'access-denied' error for a <get>
in this case -- it would just return an empty data set,
but that is how current implementations work.

The most important problem with the notification-13 draft
is that it contains sloppy normative text that will almost
certainly impact future access control standardization efforts.

I would rather put aside the notification RFC until
a standard access model is done, than to decide now
and forever how access control MUST work for notifications alone.

This one sentence should be sufficient (to replace the paragraph
in question):

    The agent MUST NOT include any content in a notification
    which the user is not authorized to view.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 07 Jun 2008 08:45:29 -0700

Hi Randy,

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 08 Jun 2008 09:44:28 -0700

> propose your text (as a minimum).

Since I'm the one who seems to be holding this up,
let me ask if the IESG considered this use case:

Notifications should be conceptually divided into a header
and a payload section.  This was originally built into Sharon's
draft, but the WG could not agree on any content for the header
except 'eventTime'.  IMO, more standard header fields will be
needed, and eventually added (e.g. eventType, eventSeverity).

One simple 'partial data' use case is the ability for
an application to receive at least the headers for
the notifications it requested (and is authorized to receive).

Remember that this corner-case occurs when a user is authorized
to receive the specific notification, but not some data within
the conceptual payload sectFrom [email-masked]  Sun Jun  8 09:44:21 2008
Date: Sun, 08 Jun 2008 09:44:28 -0700
From: Andy Bierman <[email-masked]>
To: Bert Wijnen - IETF <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Pre-13 Notification (take 2)
Sender: [email-masked]

> propose your text (as a minimum).

Since I'm the one who seems to be holding this up,
let me ask if the IESG considered this use case:

Notifications should be conceptually divided into a header
and a payload section.  This was originally built into Sharon's
draft, but the WG could not agree on any content for the header
except 'eventTime'.  IMO, more standard header fields will be
needed, and eventually added (e.g. eventType, eventSeverity).

One simple 'partial data' use case is the ability for
an application to receive at least the headers for
the notifications it requested (and is authorized to receive).

Remember that this corner-case occurs when a user is authorized
to receive the specific notification, but not some data within
the conceptual payloaion.  This scenario could easily
occur if the notification contained arbitrary config snippets
(e.g., configChangeEvent).

Andy

d section.  This scenario could easily
occur if the notification contained arbitrary config snippets
(e.g., configChangeEvent).

Andy

---

From: "David Harrington" <[email-masked]>
Date: Tue, 10 Jun 2008 21:32:07 +0800

Hi, 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Monday, June 09, 2008 12:44 AM
> To: Bert Wijnen - IETF
> Cc: [email-masked]

I don't think you're the only one holding this up. I am too.

The problem is that the loose wording in this document imposes
restrictions on future access control models, including using RFC2119
reserved words "informally". It should not do that. 

We have proposed alternate text that would resolve the problem, but
the editor usually insists on rewording the proposed text, and puts
the problem back in. I think we finally got the most egregious
paragraph fixed, and another paragraph (I think it was introduced in
the new revision) now does the same thing.

One of the big problems Andy has raised is that what is meant to be
non-normative text ends up being normative. Remember the whole debate
about RFC3411's title being "An Architecture" rather than "The
Architecture" because it was not meant to be normative? Well all
subsequent IETF WG work has had the RFC3411 treated as normative; all
subsequent approved charters have insisted that the WGs MUST NOT
violate the RFC3411 architecture. That took non-normative text and
made it normative. Andy and I have experience with non-normative text
becoming normative and we want to avoid that happening here. It is not
acceptable to argue that "it's just informal and not normative"; we
should not be making vague informal statements that could be treated
as normative in the future.

Another big problem is that consensus is that netconf notifications
can carry data from syslog and/or snmp notifications. Without
addressing access control models now, and the interaction between
netconf/syslog/snmp data models and possibly interactions between the
authentication of identities used by the protocols, we cannot possibly
understand the implications of saying something like "if the user does
not have access to all the data contained in the notification, then
the netconf notification will not be sent." The netconf implementation
will presumably have no idea what access the user will have to syslog
data elements or syslog messages or snmp objects; therefore, if the
notification contains syslog or snmp data, it cannot tell whether to
send the netconf notification or not.

A third problem, as raised by Andy, is that the document should not
say that the notification will or will not be sent based on user
access to all the content according to some other operation, because
the matching alforithm for operations might differ. We have not
decided what content must be in a notification or how the access
controls will work, and the decision on those points should be made
explicitly, not as a side-effect of some sloppy text in the
notifications document. 

We need to make sure the notifications document makes no presumptions
about the content of the notifications, or the user's access to that
content, as long as user identities, data models and access controls
have not been standardized yet.

The loose wording in this document imposes restrictions on future
models. It should not do that.

---

From: "David Harrington" <[email-masked]>
Date: Tue, 10 Jun 2008 21:32:07 +0800

Hi,

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 10 Jun 2008 10:00:15 -0400

Hi

The text we are arguing about at the moment was added a long time ago
(May 2007). The goal at the time was to try and drive consistent
behaviour in the case where the Notification contained information the
user was not allowed to see. The agreement at the time was to just not
send anything. I think some good points have been raised, particularly
with Andy's analogy to the <get> operation, that question whether the
working group made the right decision at the time.

So, we have three options here. Please indicate your preference:

1) Leave it ambiguous as to whether any of the Notification message is
sent. I.e., delete the sentence "If a user is not authorized to view all
elements in the content of the notification, the notification is not
sent to that user."

2) Clarify that nothing is sent. I.e., keep text the same.

3) Clarify that those portions the user is permitted to see are sent.
I.e., replace the above sentence with something along the lines of
"Similar to a <get> operation, the user only sees content within a
Notification that they are From [email-masked]  Tue Jun 10 07:00:11 2008
Content-class: urn:content-classes:message
Date: Tue, 10 Jun 2008 10:00:15 -0400
From: "Sharon Chisholm" <[email-masked]>
To: "David Harrington" <[email-masked]>,
	"Andy Bierman" <[email-masked]>,
	"Bert Wijnen - IETF" <[email-masked]>
Cc: [email-masked]
Subject: [Netconf] Choosing Solution for partial authorization (was RE:
	Pre-13 Notification (take 2))
Sender: [email-masked]

Hi

The text we are arguing about at the moment was added a long time ago
(May 2007). The goal at the time was to try and drive consistent
behaviour in the case where the Notification contained information the
user was not allowed to see. The agreement at the time was to just not
send anything. I think some good points have been raised, particularly
with Andy's analogy to the <get> operation, that question whether the
working group made the right decision at the time.

So, we have three options here. Please indicate your preference:

1) Leave it ambiguous as to whether any of the Notification message is
sent. I.e., delete the sentence "If a user is not authorized to view all
elements in the content of the notification, the notification is not
sent to that user."

2) Clarify that nothing is sent. I.e., keep text the same.

3) Clarify that those portions the user is permitted to see are sent.
I.e., replace the above sentence with something along the lines of
"Similar to a <get> operation, the user only sees content within a
Notification that theauthorized to see."

Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David Harrington
Sent: Tuesday, June 10, 2008 9:32 AM
To: 'Andy Bierman'; 'Bert Wijnen - IETF'
Cc: [email-masked]
Subject: Re: [Netconf] Pre-13 Notification (take 2)

Hi, 

> > considerations section in order to address comments from the IESG 
> > review.
> > 
> > I don't think we want to go through a long process of debating all 
> > the option we have for notifications. We do not have a 
> > (satndardized) ACM for NETCONF, and so we do not have to be explicit

> > as to what exactly happens in all cases, do we? We have to 
> > warn/explain to the user what he needs to look out for when 
> > supporting enabling notifications.
> > 
> > If you are not happy with the new text, can you then pls propose 
> > your text (as a minimum).
> 

We have proposed alternate text that would resolve the problem, but the
editor usually insists on rewording the proposed text, and puts the
problem back in. I think we finally got the most egregious paragraph
fixed, and another paragraph (I think it was introduced in the new
revision) now does the same thing.

One of the big problems Andy has raised is that what is meant to be
non-normative text ends up being normative. Remember the whole debate
about RFC3411's title being "An Architecture" rather than "The
Architecture" because it was not meant to be normative? Well all
subsequent IETF WG work has had the RFC3411 treated as normative; all
subsequent approved charters have insisted that the WGs MUST NOT violate
the RFC3411 architecture. That took non-normative text and made it
normative. Andy and I have experience with non-normative text becoming
normative and we want to avoid that happening here. It is not acceptable
to argue that "it's just informal and not normative"; we should not be
making vague informal statements that could be treated as normative in
the future.

Another big problem is that consensus is that netconf notifications can
carry data from syslog and/or snmp notifications. Without addressing
access control models now, and the interaction between
netconf/syslog/snmp data models and possibly interactions between the
authentication of identities used by the protocols, we cannot possibly
understand the implications of saying something like "if the user does
not have access to all the data contained in the notification, then the
netconf notification will not be sent." The netconf implementation will
presumably have no idea what access the user will have to syslog data
elements or syslog messages or snmp objects; therefore, if the
notification contains syslog or snmp data, it cannot tell whether to
send the netconf notification or not.

A third problem, as raised by Andy, is that the document should not say
that the notification will or will not be sent based on user access to
all the content according to some other operation, because the matching
alforithm for operations might differ. We have not decided what content
must be in a notification or how the access controls will work, and the
decision on those points should be made explicitly, not as a side-effect
of some sloppy text in the notifications document. 

y are authorized to see."

Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David Harrington
Sent: Tuesday, June 10, 2008 9:32 AM
To: 'Andy Bierman'; 'Bert Wijnen - IETF'
Cc: [email-masked]
Subject: Re: [Netconf] Pre-13 Notification (take 2)

Hi, 

> > considerations section in order to address comments from the IESG 
> > review.
> > 
> > I don't think we want to go through a long process of debating all 
> > the option we have for notifications. We do not have a 
> > (satndardized) ACM for NETCONF, and so we do not have to be explicit

> > as to what exactly happens in all cases, do we? We have to 
> > warn/explain to the user what he needs to look out for when 
> > supporting enabling notifications.
> > 
> > If you are not happy with the new text, can you then pls propose 
> > your text (as a minimum).
> 

We have proposed alternate text that would resolve the problem, but the
editor usually insists on rewording the proposed text, and puts the
problem back in. I think we finally got the most egregious paragraph
fixed, and another paragraph (I think it was introduced in the new
revision) now does the same thing.

One of the big problems Andy has raised is that what is meant to be
non-normative text ends up being normative. Remember the whole debate
about RFC3411's title being "An Architecture" rather than "The
Architecture" because it was not meant to be normative? Well all
subsequent IETF WG work has had the RFC3411 treated as normative; all
subsequent approved charters have insisted that the WGs MUST NOT violate
the RFC3411 architecture. That took non-normative text and made it
normative. Andy and I have experience with non-normative text becoming
normative and we want to avoid that happening here. It is not acceptable
to argue that "it's just informal and not normative"; we should not be
making vague informal statements that could be treated as normative in
the future.

Another big problem is that consensus is that netconf notifications can
carry data from syslog and/or snmp notifications. Without addressing
access control models now, and the interaction between
netconf/syslog/snmp data models and possibly interactions between the
authentication of identities used by the protocols, we cannot possibly
understand the implications of saying something like "if the user does
not have access to all the data contained in the notification, then the
netconf notification will not be sent." The netconf implementation will
presumably have no idea what access the user will have to syslog data
elements or syslog messages or snmp objects; therefore, if the
notification contains syslog or snmp data, it cannot tell whether to
send the netconf notification or not.

A third problem, as raised by Andy, is that the document should not say
that the notification will or will not be sent based on user access to
all the content according to some other operation, because the matching
alforithm for operations might differ. We have not decided what content
must be in a notification or how the access controls will work, and the
decision on those points should be made explicitly, not as a side-effect
of some sloppy text in the notifications document.

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 10 Jun 2008 10:21:05 -0400

Hi

For option 3, a slight modification to some text suggested by Andy (we
don't have agents ;-)) would work nicely

   The NETCONF server MUST NOT include any content in a notification
    which the user is not authorized to view. 

Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Chisholm, Sharon (CAR:ZZ00)
Sent: Tuesday, June 10, 2008 10:00 AM
To: David Harrington; Andy Bierman; Bert Wijnen - IETF
Cc: [email-masked]
Subject: [Netconf] Choosing Solution for partial authorization (was RE:
Pre-13 Notification (take 2))

Hi

3) Clarify that those portions the user is permitted to see are sent.
I.e., replace the above sentence with something along the lines of
"Similar to a <get> operation, the user only sees content within a
Notification that they are authorized to see."

Sharon 

-----Original Message-----

Hi,

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 10 Jun 2008 10:21:05 -0400

Hi

Sharon

-----Original Message-----

Hi

Sharon 

-----Original Message-----

Hi,

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Jun 2008 16:24:00 +0200 (CEST)

Hi,

>     which the user is not authorized to view. 

I prefer this one.  It leaves the decision to drop or prune the
notification to the future authorization discussions.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Jun 2008 16:24:00 +0200 (CEST)

Hi,

/martin

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 10 Jun 2008 10:17:07 -0700

Shouldn't there be a 4th option, to indicate whether users are
authorized to view/receive the notification (as opposed to specifying it
indirectly)?  I can see the appeal of 2 and 3, but both are somewhat
unsatisfactory.  2 will lead to some unintended and difficult to explain
side effects from the perspective of end users, who may be unaware of
the fact that a conflict exists with regards to one parameter with
regards to a particular message.  Similarly, option 3 appears to lead to
unexpected "heterogeneity" regarding the same type of message.    

--- Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sharon Chisholm
Sent: Tuesday, June 10, 2008 7:00 AM
To: David Harrington; Andy Bierman; Bert Wijnen - IETF
Cc: [email-masked]
Subject: [Netconf] Choosing Solution for partial authorization (was
RE:Pre-13 Notification (take 2))

Hi

Sharon 

-----Original Message-----

Hi,

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 10 Jun 2008 10:17:07 -0700

--- Alex

-----Original Message-----

Hi

Sharon 

-----Original Message-----

Hi,

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 10 Jun 2008 15:23:07 -0400

Hi

Let me see if I understand what you are saying. You are saying that
option 3 is still ambiguous (which I think I agree with after Martin's
comment) so you are looking for a fourth option where either
  4a. While defining the notification it is captured whether or not
Notifications get sent for partial authorization
  4b. It is left strictly to the authorization policy whether partially
authorized Notifications get sent.

If I understand these options, I think I still prefer some form of 3.

3a. The Andy text I indicated below
3b. A stricter version that indicates that the Notification is still
sent without the non-authorized information.

Sharon 

-----Original Message-----
From: Alexander Clemm (alex) [mailto:[email-masked]] 
Sent: Tuesday, June 10, 2008 1:17 PM
To: Chisholm, Sharon (CAR:ZZ00); David Harrington; Andy Bierman; Bert
Wijnen - IETF
Cc: [email-masked]
Subject: RE: [Netconf] Choosing Solution for partial authorization (was
RE:Pre-13 Notification (take 2))

--- Alex

-----Original Message-----

Hi

Sharon 

-----Original Message-----

Hi,

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 10 Jun 2008 15:23:07 -0400

Hi

Sharon 

-----Original Message-----
From: Alexander Clemm (alex) [mailto:[email-masked]] 
Sent: Tuesday, June 10, 2008 1:17 PM
To: Chisholm, Sharon (CAR:ZZ00); David Harrington; Andy Bierman; Bert
Wijnen - IETF
Cc: [email-masked]

--- Alex

-----Original Message-----

Hi

Sharon 

-----Original Message-----

Hi,

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Jun 2008 12:26:54 -0700

> notification to the future authorization discussions.

yes -- it might turn out (when a well-designed and agreed-upon
access control model is done) that there is some good reason
to treat <get> access differently than <notification> access.
Until then, the standard should be silent on the issue.

Can we get consensus on this edit and close the thread?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Jun 2008 12:26:54 -0700

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 11 Jun 2008 11:36:42 -0400

Hi

Does anyone then disagree with making this change (3a)

Replace

"If a user is not authorized to view all elements in the content of the
notification, the notification is not sent to that user."

With

" The NETCONF server MUST NOT include any content in a notification
     which the user is not authorized to view." 

If not, then I will make this change, publish as -14 and then I think we
can send the document on its way. I believe this means sending it back
to the IESG for approval again.

Sharon 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Tuesday, June 10, 2008 3:27 PM
To: Martin Bjorklund
Cc: Chisholm, Sharon (CAR:ZZ00); [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Netconf] Choosing Solution for partial authorization

Martin Bjorklund wrote:
>> For option 3, a slight modification to some text suggested by Andy 
>> (we don't have agents ;-)) would work nicely
>>
>>    The NETCONF server MUST NOT include any content in a notificaFrom [email-masked]  Wed Jun 11 08:37:23 2008
Content-class: urn:content-classes:message
Date: Wed, 11 Jun 2008 11:36:42 -0400
From: "Sharon Chisholm" <[email-masked]>
To: "Andy Bierman" <[email-masked]>,
	"Martin Bjorklund" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Choosing Solution for partial authorization
Sender: [email-masked]

Hi

Does anyone then disagree with making this change (3a)

Replace

"If a user is not authorized to view all elements in the content of the
notification, the notification is not sent to that user."

With

" The NETCONF server MUST NOT include any content in a notification
     which the user is not authorized to view." 

If not, then I will make this change, publish as -14 and then I think we
can send the document on its way. I believe this means sending it back
to the IESG for approval again.

Sharon 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Tuesday, June 10, 2008 3:27 PM
To: Martin Bjorklund
Cc: Chisholm, Sharon (CAR:ZZ00); [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Netconf] Choosing Solution for partial authorization

Martin Bjorklund wrote:
>> For option 3, a slight modification to some text suggested by Andy 
>> (we don't have agents ;-)) would work nicely
>>
>>    The NETCONF server MUST NOT include any content in a notion

yes -- it might turn out (when a well-designed and agreed-upon access
control model is done) that there is some good reason to treat <get>
access differently than <notification> access.
Until then, the standard should be silent on the issue.

Andy

tification
> notification to the future authorization discussions.

yes -- it might turn out (when a well-designed and agreed-upon access
control model is done) that there is some good reason to treat <get>
access differently than <notification> access.
Until then, the standard should be silent on the issue.

Andy

---

From: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
Date: Wed, 11 Jun 2008 18:00:51 +0200

Hi Sharon, All,

I personally support the proposed text change.

Let us close the issue and have a consensus on this edit 
asap. If there is anybody who has any objections (hopefully 
not) please speak up.

Otherwise, as Sharon says, we will send it as -14 back to 
the IESG. 

Cheers, 
Mehmet

> [mailto:[email-masked]] On Behalf Of ext Sharon Chisholm
> Sent: Wednesday, June 11, 2008 5:37 PM
> To: Andy Bierman; Martin Bjorklund
> Cc: [email-masked]

---

From: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
Date: Wed, 11 Jun 2008 18:00:51 +0200

Hi Sharon, All,

Cheers, 
Mehmet

---

From: "tom.petch" <[email-masked]>
Date: Tue, 10 Jun 2008 18:22:24 +0200

+1

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Tue, 10 Jun 2008 18:22:24 +0200

+1

Tom Petch

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 12 Jun 2008 10:21:16 +0200

I like the text.
Balazs

Sharon Chisholm wrote:
> SharFrom [email-masked]  Thu Jun 12 01:21:18 2008
Date: Thu, 12 Jun 2008 10:21:16 +0200
From: Balazs Lengyel <[email-masked]>
To: Sharon Chisholm <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Choosing Solution for partial authorization
Sender: [email-masked]

I like the text.
Balazs

Sharon Chisholm wrote:
> on