Subject: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 23 Apr 2008 14:41:02 -0400

Hi

This is the list of proposed edits from the Discuss issues. The
originators of the issues have confirmed they are Ok with these
resolutions. This list includes the ones that I felt were more
contentious and had therefore previously aired with the working group.

I will now start working on the update and will send a draft of to the
mailing list when it is ready as some may find that easier to review.

Proposed Edits
--------------

A. In section 2.1.1, for both instances and in section 2.2.1 Replace
     This parameter is of type dateTime.
With
     This parameter is of type dateTime and compliant to [RFC3339] and
[ISO.8601.1988].
In the normative reference section, add the following two references
   [ISO.8601.1988]
              International Organization for Standardization, "Data
              elements and interchange formats - Information interchange
              - Representation of dates and times", ISO Standard 8601,
              June 1988.
   [RFC3339]  Klyne, G., Ed. and C. Newman, "Date and Time on the
              Internet: Timestamps", RFC 3339, July 2002.

B. In section 2.1.1, for both instances and in section 2.2.1, add the
following after the text indicating that the time fields are dateTime
(this covers eventTime, startTime and stopTime). 
  Implementations must support time zones.

C. In Section 3.6.1 
>>   parameter.  A Filter only exist as a parameter to the subscription.
> s/exist/exists/

D. In Section 7: 
>>   that it is viewed only by authorized users.  If a user does not
have
>From [email-masked]  Wed Apr 23 11:42:32 2008
Content-class: urn:content-classes:message
Date: Wed, 23 Apr 2008 14:41:02 -0400
From: "Sharon Chisholm" <[email-masked]>
To: <[email-masked]>
Subject: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues
Sender: [email-masked]

Hi

This is the list of proposed edits from the Discuss issues. The
originators of the issues have confirmed they are Ok with these
resolutions. This list includes the ones that I felt were more
contentious and had therefore previously aired with the working group.

I will now start working on the update and will send a draft of to the
mailing list when it is ready as some may find that easier to review.

Proposed Edits
--------------

A. In section 2.1.1, for both instances and in section 2.2.1 Replace
     This parameter is of type dateTime.
With
     This parameter is of type dateTime and compliant to [RFC3339] and
[ISO.8601.1988].
In the normative reference section, add the following two references
   [ISO.8601.1988]
              International Organization for Standardization, "Data
              elements and interchange formats - Information interchange
              - Representation of dates and times", ISO Standard 8601,
              June 1988.
   [RFC3339]  Klyne, G., Ed. and C. Newman, "Date and Time on the
              Internet: Timestamps", RFC 3339, July 2002.

B. In section 2.1.1, for both instances and in section 2.2.1, add the
following after the text indicating that the time fields are dateTime
(this covers eventTime, startTime and stopTime). 
  Implementations must support time zones.

C. In Section 3.6.1 
>>   parameter.  A Filter only exist as a parameter to the subscription.
> s/exist/exists/

D. In Section 7: 
>>   that it is viewed only by authorized users.  If a user does not
>   permission to view content via other NETCONF operations, it must
not
>>   have access that content via Notifications.
> s/it/she/
> s/access that/access to that/

E. In section 3.3.2
Replace 
   The NETCONF server will then accept <rpc> operations.
With
   The NETCONF server will then accept <rpc> operations even if the
server
   did not previously accept such operations due to lack of interleave
support.

F. In section 3.3.2
Replace
   A <replayComplete> notification is sent to indicate that all of the
   replay notifications have been sent.  If this subscription has a stop
   time, then this session becomes a normal NETCONF session again.  When
   a <stopTime> has been specified, <notificationComplete> notification
   is the last notification sent on the subscription before it
   terminates and the NETCONF session returns to being a normal NETCONF
   session. 
With
   A <replayComplete> notification is sent to indicate that all of the
   replay notifications have been sent. When
   a <stopTime> has been specified, <notificationComplete> notification
   is the last notification sent on the subscription before it
   terminates and the NETCONF session returns to being a normal NETCONF
   session. 

G. In section 3.3.2
Replace
   A <replayComplete> notification is sent to indicate that all of the
   replay notifications have been sent.
With
   A <replayComplete> notification is sent to indicate that all of the
   replay notifications have been sent and must not be sent for any
other reason.

H. In section 3.3.1
Replace
   A notification stream that supports replay is not expected to have an
   unlimited supply of saved notifications available to accommodate any
   replay request.
With
   A notification stream that supports replay is not expected to have an
   unlimited supply of saved notifications available to accommodate any
   replay request. Clients can query <replayLogCreationTime> and
<replayLogAgedTime>
   to learn about the availability of notifications for replay.

I.  In section 3.2, replace
   Figure 2 illustrates the notification flow and concepts identified in
   this document.
With
   Figure 2 illustrates the notification flow and concepts identified in
   this document. It does not mandate and/or preclude an implementation.

J. In section 6.1, add the following text
  This capability helps scalability by reducing the total number of
NETCONF sessions required by a given operator or management application.

K. In section 3.6, delete (keeps confusing people)
  When multiple filter elements are specified, they are applied
   collectively, so event notifications need to pass all specified
   filter elements in order to be sent to the subscriber. 

L. In section 7 (Security Considerations) after the bullets add the
following:

Secure execution means ensuring that a secure transport is used as well
as ensuring that the user has sufficient authorization to perform the
function they are requesting against the specific piece of NETCONF
content involved.  When a <get> is received against the content defined
in this memo, clients should only be able to view the content for which
they have sufficient privileges. A create <create-subscription>
operation can be considered like a deferred <get>, and the content that
different users can access may vary. This different access is reflected
in the <notification> that different users are able to subscribe to. 

M. Replace

<xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
    schemaLocation=
     "http://www.iana.org/assignments/xml-registry/schema/netconf.xsd"/>
<xs:import namespace=
    "urn:ietf:params:xml:ns:netconf:notification:1.0"
      schemaLocation=
"http://www.iana.org/assignments/xml-registry/schema/notification.xsd"/>

With

<xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
    schemaLocation="netconf.xsd"/>
<xs:import namespace=
    "urn:ietf:params:xml:ns:netconf:notification:1.0"
      schemaLocation="notification.xsd"/>

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada
_______________________________________________
Netconf mailing lihave
>>   permission to view content via other NETCONF operations, it must
not
>>   have access that content via Notifications.
> s/it/she/
> s/access that/access to that/

E. In section 3.3.2
Replace 
   The NETCONF server will then accept <rpc> operations.
With
   The NETCONF server will then accept <rpc> operations even if the
server
   did not previously accept such operations due to lack of interleave
support.

F. In section 3.3.2
Replace
   A <replayComplete> notification is sent to indicate that all of the
   replay notifications have been sent.  If this subscription has a stop
   time, then this session becomes a normal NETCONF session again.  When
   a <stopTime> has been specified, <notificationComplete> notification
   is the last notification sent on the subscription before it
   terminates and the NETCONF session returns to being a normal NETCONF
   session. 
With
   A <replayComplete> notification is sent to indicate that all of the
   replay notifications have been sent. When
   a <stopTime> has been specified, <notificationComplete> notification
   is the last notification sent on the subscription before it
   terminates and the NETCONF session returns to being a normal NETCONF
   session. 

G. In section 3.3.2
Replace
   A <replayComplete> notification is sent to indicate that all of the
   replay notifications have been sent.
With
   A <replayComplete> notification is sent to indicate that all of the
   replay notifications have been sent and must not be sent for any
other reason.

H. In section 3.3.1
Replace
   A notification stream that supports replay is not expected to have an
   unlimited supply of saved notifications available to accommodate any
   replay request.
With
   A notification stream that supports replay is not expected to have an
   unlimited supply of saved notifications available to accommodate any
   replay request. Clients can query <replayLogCreationTime> and
<replayLogAgedTime>
   to learn about the availability of notifications for replay.

I.  In section 3.2, replace
   Figure 2 illustrates the notification flow and concepts identified in
   this document.
With
   Figure 2 illustrates the notification flow and concepts identified in
   this document. It does not mandate and/or preclude an implementation.

J. In section 6.1, add the following text
  This capability helps scalability by reducing the total number of
NETCONF sessions required by a given operator or management application.

K. In section 3.6, delete (keeps confusing people)
  When multiple filter elements are specified, they are applied
   collectively, so event notifications need to pass all specified
   filter elements in order to be sent to the subscriber. 

L. In section 7 (Security Considerations) after the bullets add the
following:

Secure execution means ensuring that a secure transport is used as well
as ensuring that the user has sufficient authorization to perform the
function they are requesting against the specific piece of NETCONF
content involved.  When a <get> is received against the content defined
in this memo, clients should only be able to view the content for which
they have sufficient privileges. A create <create-subscription>
operation can be considered like a deferred <get>, and the content that
different users can access may vary. This different access is reflected
in the <notification> that different users are able to subscribe to. 

M. Replace

<xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
    schemaLocation=
     "http://www.iana.org/assignments/xml-registry/schema/netconf.xsd"/>
<xs:import namespace=
    "urn:ietf:params:xml:ns:netconf:notification:1.0"
      schemaLocation=
"http://www.iana.org/assignments/xml-registry/schema/notification.xsd"/>

With

<xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
    schemaLocation="netconf.xsd"/>
<xs:import namespace=
    "urn:ietf:params:xml:ns:netconf:notification:1.0"
      schemaLocation="notification.xsd"/>

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada
_______________________________________________
Netconf mailst
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

ing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Apr 2008 12:04:11 -0700

> contentious and had therefore previously aired with the working group.

This list looks fine, except M should list 3 imports
(missing the 1 in the 2nd XSD).

Andy

Netconf mailing list

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Apr 2008 12:04:11 -0700

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 23 Apr 2008 21:46:39 +0200 (CEST)

Hi,

>   Implementations must support time zones.

Don't we have to be more strict here?  Just saying "must support"
seems to imply that I must be prepared to handle timezones, but not
that I have to use them.

Maybe say that clients MUST send timezone in startTime and stopTime
(otherwise it's an invalid-value error), and servers MUST send
timezone in eventTime, replayLogCreationTime, and replayLogAgedTime?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 23 Apr 2008 21:46:39 +0200 (CEST)

Hi,

/martin

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 23 Apr 2008 23:03:57 -0400

Hi,

> >>   have access that content via Notifications.

In SNMP, it is acceptable to have notify-only access to managed
objects, so, for example, a printer can send an "out of paper"
notification, but does not need to support GET/SET operations. Netconf
has different properties focused on configuration rather than
monitoriung. Are there instances where a device might send a
notification to a principal that does not have other access? Might a
security admin get notified when there are security breaches, but not
have access to <get> or <modify> a configuration?

you might want to change "it" to "he/she", or "the user"

>    replay notifications have been sent and must not be sent for any

Is the replay cache session-specific? Could another session request a
replay of the same information?

>    this document. It does not mandate and/or preclude an 

I don't understand this new sentence. I would hope the illustration
would not preclude an implementation; that would seem
counter-productive.

>    filter elements in order to be sent to the subscriber. 

This is still part of the design, right? Is this specified clearly
someplace?

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 23 Apr 2008 23:03:57 -0400

Hi,

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 23 Apr 2008 23:10:23 -0400

Hi,

a little bit further thought on this one:

> In SNMP, it is acceptable to have notify-only access to 
> managed objects, so, for example, a printer can send an "out 
> of paper" notification, but does not need to support GET/SET 
> operations. Netconf has different properties focused on 
> configuration rather than monitoriung. Are there instances 
> where a device might send a notification to a principal that 
> does not have other access? Might a security admin get 
> notified when there are security breaches, but not have 
> access to <get> or <modify> a configuration?

Netconf notifications can carry syslog content, but presumably no user
has permission to view that syslog content via other netconf
operations.

s/not have access that/not have access to that/ (if you keep the text)

_______________________________________________
Netconf mailing list
Netconf@ietFrom [email-masked]  Wed Apr 23 20:10:39 2008
From: "David B Harrington" <[email-masked]>
To: "'David B Harrington'" <[email-masked]>,
	"'Sharon Chisholm'" <[email-masked]>, <[email-masked]>
Date: Wed, 23 Apr 2008 23:10:23 -0400
Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss
	Issues
Sender: [email-masked]

Hi,

a little bit further thought on this one:

> In SNMP, it is acceptable to have notify-only access to 
> managed objects, so, for example, a printer can send an "out 
> of paper" notification, but does not need to support GET/SET 
> operations. Netconf has different properties focused on 
> configuration rather than monitoriung. Are there instances 
> where a device might send a notification to a principal that 
> does not have other access? Might a security admin get 
> notified when there are security breaches, but not have 
> access to <get> or <modify> a configuration?

Netconf notifications can carry syslog content, but presumably no user
has permission to view that syslog content via other netconf
operations.

s/not have access that/not have access to that/ (if you keep the text)

f.org

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 24 Apr 2008 08:04:16 -0400

Hi

From reading I did, if a client does not specify a time zone then we
should assume it is local time zone on the box. Perhaps we should
explicitly say this? Alternatively we could mandate that the client
always provide time zone like Martin suggests.

Sharon 

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Wednesday, April 23, 2008 3:47 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss
Issues

Hi,

Don't we have to be more strict here?  Just saying "must support"
seems to imply that I must be prepared to handle timezones, but not that
I have to use them.

Maybe say that clients MUST send timezone in startTime and stopTime
(otherwise it's an invalid-value error), and servers MUST send timezone
in eventTime, replayLogCreationTime, and replayLogAgedTime?

/martin

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 24 Apr 2008 08:04:16 -0400

Hi

Sharon 

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Wednesday, April 23, 2008 3:47 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss
Issues

Hi,

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Apr 2008 14:15:36 +0200

> always provide time zone like Martin suggests.

Do we want to make it impossible to be compliant on some devices
(until the owner configured a time zone) or do we want to invite
implementors to fake a timezone just to be compliant?

I prefer that a device which does not know its timezone says so by not
including a timezone. We should require that if an implementation
knows the timezone, it MUST include it. If on the otherFrom [email-masked]  Thu Apr 24 05:15:39 2008
Date: Thu, 24 Apr 2008 14:15:36 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Sharon Chisholm <[email-masked]>
Mail-Followup-To: Sharon Chisholm <[email-masked]>,
	Martin Bjorklund <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve
	Discuss	Issues
Reply-To: [email-masked]
Sender: [email-masked]

> always provide time zone like Martin suggests.

Do we want to make it impossible to be compliant on some devices
(until the owner configured a time zone) or do we want to invite
implementors to fake a timezone just to be compliant?

I prefer that a device which does not know its timezone says so by not
including a timezone. We should require that if an implementation
knows the timezone, it MUST include it. If on the hand a
timezone is not know, then a timezone it MUST NOT be included.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

 other hand a
timezone is not know, then a timezone it MUST NOT be included.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Phil Shafer <[email-masked]>
Date: Thu, 24 Apr 2008 09:33:17 -0400

Juergen Schoenwaelder writes:
>knows the timezone, it MUST include it. If on the other hand a

We should also allow the device to have a default timezone, such
as UTC/GMT.  If the device has such a default, it would be included
in the timestamps.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Thu, 24 Apr 2008 09:33:17 -0400

Thanks,
 Phil

---

From: Per Hedeland <[email-masked]>
Date: Thu, 24 Apr 2008 17:55:17 +0200

> as UTC/GMT.  If the device has such a default, it would be included

But isn't the real problem that the timestamps, and even more
importantly the startTime and stopTime, must have some well-defined
*meaning*? For starters, what does a timezone-less timestamp mean?  XML
Schema says "the time in the timezone of some unspecified locality as
prescribed by the appropriate legal authority" - presumably that
authority would be the RFC in this case, and it could reasonably say
"the local time in the server's location" (which of course opens up the
question of how the client can know the server's location, but...).

OK, so now we have a really stupid box that doesn't know anything about
time zones, that should be allowed to send timezone-less timestamps.
But this means that it "knows" that its clock is really running on local
time and not on UTC (or something else), otherwise those timestamps are
invalid - is this a reasonable assumption? And even if we decide to say
that in this context, a timezone-less timestamp really has a completely
unspecified (and probably not even constant) relation to UTC, we still
have the case that the client and server are supposed to be able to
agree on theFrom [email-masked]  Thu Apr 24 08:55:15 2008
Date: Thu, 24 Apr 2008 17:55:17 +0200
From: Per Hedeland <[email-masked]>
To: Phil Shafer <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve
	Discuss	Issues
Sender: [email-masked]

> as UTC/GMT.  If the device has such a default, it would be included

But isn't the real problem that the timestamps, and even more
importantly the startTime and stopTime, must have some well-defined
*meaning*? For starters, what does a timezone-less timestamp mean?  XML
Schema says "the time in the timezone of some unspecified locality as
prescribed by the appropriate legal authority" - presumably that
authority would be the RFC in this case, and it could reasonably say
"the local time in the server's location" (which of course opens up the
question of how the client can know the server's location, but...).

OK, so now we have a really stupid box that doesn't know anything about
time zones, that should be allowed to send timezone-less timestamps.
But this means that it "knows" that its clock is really running on local
time and not on UTC (or something else), otherwise those timestamps are
invalid - is this a reasonable assumption? And even if we decide to say
that in this context, a timezone-less timestamp really has a completely
unspecified (and probably not even constant) relation to UTC, we still
have the case that the client and server are supposed to be able to
agree  meaning of startTime and stopTime.

So take the case of the stupid box again - it doesn't know anything
about time zones, but it knows that its clock is running on local time,
and so has no problem interpreting timezone-less startTime and stopTime
from the client. We could even say that this covers the "completely
unspecified" definition. But what if it gets a replay request with a
timezoned start/stopTime? It can't possibly interpret it - should it
reply with an error? And does that mean that the client should always
retry with a timezone-less request if a timezoned one fails? Or always
only use timezone-less requests?

Also note that requiring a time zone doesn't mean that the server has to
"know about time zones" - it only needs to know UTC time (e.g. by
"knowing" that its clock runs on UTC). If it does, it can always send
Z-zoned timestamps, which are of course unambiguous and can be
translated to whatever time zone the end user wants. It can also
correctly interpret *all* timezoned requests from the client, since they
are either UTC or a specified offset from UTC. But this otherwise
well-behaved server can *not* interpret timezone-less requests if they
are defined as meaning "local time on the server" - it needs to at least
know its own time zone for that (and the specification of that can be
quite complex given the DST variatons).

It sure seems to me that the only sensible way out of this mess is to
always require a timezone (perhaps explicitly spelling out that Z/00:00
is also a timezone in this context), both on event timestamps from the
server and on startTime/stopTime.

--Per Hedeland

on the meaning of startTime and stopTime.

So take the case of the stupid box again - it doesn't know anything
about time zones, but it knows that its clock is running on local time,
and so has no problem interpreting timezone-less startTime and stopTime
from the client. We could even say that this covers the "completely
unspecified" definition. But what if it gets a replay request with a
timezoned start/stopTime? It can't possibly interpret it - should it
reply with an error? And does that mean that the client should always
retry with a timezone-less request if a timezoned one fails? Or always
only use timezone-less requests?

Also note that requiring a time zone doesn't mean that the server has to
"know about time zones" - it only needs to know UTC time (e.g. by
"knowing" that its clock runs on UTC). If it does, it can always send
Z-zoned timestamps, which are of course unambiguous and can be
translated to whatever time zone the end user wants. It can also
correctly interpret *all* timezoned requests from the client, since they
are either UTC or a specified offset from UTC. But this otherwise
well-behaved server can *not* interpret timezone-less requests if they
are defined as meaning "local time on the server" - it needs to at least
know its own time zone for that (and the specification of that can be
quite complex given the DST variatons).

It sure seems to me that the only sensible way out of this mess is to
always require a timezone (perhaps explicitly spelling out that Z/00:00
is also a timezone in this context), both on event timestamps from the
server and on startTime/stopTime.

--Per Hedeland

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 24 Apr 2008 13:13:20 -0400

hi

Attached is the promised draft update.

Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Chisholm, Sharon (CAR:ZZ00)
Sent: Wednesday, April 23, 2008 2:41 PM
To: [email-masked]
Subject: [Netconf] Notifications: Proposed Edits to Resolve Discuss
Issues

Hi

Proposed Edits
--------------

              IntFrom [email-masked]  Thu Apr 24 10:13:43 2008
Date: Thu, 24 Apr 2008 13:13:20 -0400

This is a multi-part message in MIME format.
 hi

Attached is the promised draft update.

Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Chisholm, Sharon (CAR:ZZ00)
Sent: Wednesday, April 23, 2008 2:41 PM
To: [email-masked]
Subject: [Netconf] Notifications: Proposed Edits to Resolve Discuss
Issues

Hi

Proposed Edits
--------------

           ernational Organization for Standardization, "Data

C. In Section 3.6.1 

have
not

E. In section 3.3.2
Replace 

F. In section 3.3.2
Replace

G. In section 3.3.2
Replace

H. In section 3.3.1
Replace

different users can    International Organization for Standardization, "Data

C. In Section 3.6.1 

have
not

E. In section 3.3.2
Replace 

F. In section 3.3.2
Replace

G. In section 3.3.2
Replace

H. In section 3.3.1
Replace

different useraccess may vary. This different access is reflected

M. Replace

With

Sharon Chisholm
Nortel
Ottawa, Ontario
Canada

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 24 Apr 2008 13:26:15 -0400

Hi

Inline 

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Wednesday, April 23, 2008 11:04 PM
To: Chisholm, Sharon (CAR:ZZ00); [email-masked]
Subject: RE: [Netconf] Notifications: Proposed Edits to Resolve Discuss
Issues

Hi,

> >>   have access that content via Notifications.

In SNMP, it is acceptable to have notify-only access to managed objects,
so, for example, a printer can send an "out of paper"
notification, but does not need to support GET/SET operations. Netconf
has different properties focused on configuration rather than
monitoriung. Are there instances where a device might send a
notification to a principal that does not have other access? Might a
security admin get notified when there are security breaches, but not
have access to <get> or <modify> a configuration?

<sharon>
I think that issues is orthogonal. The information was not available
because someone determined it didn't make operational sense to have it
available for a get, as oppose to the person not being authorized. It
was a permissions question. I think the existing text is correct.
</sharon>

you might want to change "it" to "he/she", or "the user"
<sharon>
There is an edit later on that does it. 
</sharon>

Is the replay cache session-specific? Could another session request a
replay of the same information?
<sharon> No. It is stream specific. Anyone can access the cache.
</sharon>

I don't understand this new sentence. I would hope the illustration
would not preclude an implementation; that would seem
counter-productive.
<sharon>
Someone wanted that clarified. No harm in clarifying.
</sharon>

This is still part of the design, right? Is this specified clearly
someplace?
<sharon>
The design has not been changed, but the fact that a filter was made up
of multiple parts which are called filter elements has consistently
confused people into thinking there are multiple filters. 
</sharon>

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 24 Apr 2008 13:26:15 -0400

Hi

Inline 

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Wednesday, April 23, 2008 11:04 PM
To: Chisholm, Sharon (CAR:ZZ00); [email-masked]
Subject: RE: [Netconf] Notifications: Proposed Edits to Resolve Discuss
Issues

Hi,

<sharon>

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Apr 2008 19:50:14 +0200

> question of how the client can know the server's location, but...).

Exactly. No timezone means the value is ambiguous. But timestamps are
still meaningful relative to other timestamps from the same box.

> invalid - is this a reasonable assumption?

If you don't know the timezone, you just don't know it. The box simply
might have no concept of a timezone at all. The timezone is unknown,
not UTC (or something else).

> reply with an error?

Yes.

> And does that mean that the client should always retry with a
> timezone-less request if a timezoned one fails? Or always only use
> timezone-less requests?

It depends on what the application is trying to do.

> quite complex given the DST variatons).

I don't get the DST variations argument. Either it is easy to
translate to/from UTC or it is not. My interpretation of no timezone
is that the timezone is unknown and any attempts to translate unknown
into something else is IMHO a waste of time. ;-)

> It sure seems to me that the only sensible way out of this mess is
> to always require a timezone (perhaps explicitly spelling out that
> Z/00:00 is also a timezone in this context), both on event
> timestamps from the server and on startTime/stopTime.

This means that implementations on devices where you can set the date
and time but not the timezone simply have to lie they are running UTC
even though this is likely not true on the majority of geographic
locations.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Apr 2008 19:50:14 +0200

Yes.

/js

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Fri, 25 Apr 2008 12:25:18 +0200

I believe that in the pre-13 document that Sharon posted she 
changed them all. Agreed?

Bert Wijnen 

> -----Oorspronkelijk bericht-----
> Van: [email-masked] [mailto:[email-masked]]Namens
> Andy Bierman
> Verzonden: woensdag 23 april 2008 21:04
> Aan: Sharon Chisholm
> CC: [email-masked]
> Onderwerp: Re: [Netconf] Notifications: Proposed Edits to Resolve
> DiscussIssues
> 
> 
> Sharon Chisholm wrote:
> > Hi
> >

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Fri, 25 Apr 2008 12:25:18 +0200

Bert Wijnen

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Fri, 25 Apr 2008 12:25:21 +0200

Dave, are you ahppy now with the document Sharon posted?

Bert Wijnen 

> David B Harrington
> Verzonden: donderdag 24 april 2008 5:10
> Aan: 'David B Harrington'; 'Sharon Chisholm'; [email-masked]

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Fri, 25 Apr 2008 12:25:21 +0200

Bert Wijnen

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Fri, 25 Apr 2008 12:26:46 +0200

Thanks Sharon and Hector.

WG members, pls check the text changes in the new document
that Sharon posted to the WG list yesterday. We're not opening
up the document for generic discussions, we're only
checking to make sure no-one sees a fatal flaw with the
changed text.

I think the changes that have been made (as a result of the
IESG comments and the comments from various Directorates) will
allow the document to clear all outstanding DISCUSSes of the
IESG. In case you want to see them they are listed here:
  https://datatracker.ietf.org/idtracker/ballot/2699/

Sharon has discussed (via email) all the changes with the
ADs that have a DISCUSS, and as far as I can tell from that
discussion, they will indeed clear their DISCUSS once we
post this new revision.

I don't think that there are any changes that warrant/need
long discussions. As I said, the changes were made to address
the comments from IESG. They are mainly additional explanatory
text. The 2 changes that seem a bit more than editorial
are

- The change of the IMPORT for schema location.
  So instead of
    <xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
     schemaLocation=
     "http://www.iana.org/assignments/xml-registry/schema/netconf.xsd"/>
    <xs:import namespace=
     "urn:ietf:params:xml:ns:netconf:notification:1.0"
     schemaLocation=
     "http://www.iana.org/assignments/xml-registry/schema/notification.xsd"/

  We now use:

  The actual schema location can still be found in the IANA considerations
  section.

  I also liked what we had in rev 12 better, but I do not
  think we want to hold up our doc to fight the generic
  issue that has been reaised. We can always fix the
  document once the generic issue has been solved.

- The Timezone change where we have added that a device
  "must send timezone info".
  I have not seen a clonclusion on that one yet on our mailing list.
  hopefully we arrive at that very soon.

So PLEASE do send in your comments/objections BEFORE May 1st.
That is in 6 days from posting the draft (to the list) and 7
days from posting the specific text edits on April 23rd

If anyone feels they need more time, pls let us (WG chairs)
know asap.

The reason for the urgency is that I would like this new
revision to be posted by the end of next week (so May 2nd or
so), so that the IESG can check if their DISCUSSes can be
cleared by the May 8th IESG telechat.

Bert Wijnen
Document shepherd.
co-chair Netconf WG

> Verzonden: donderdag 24 april 2008 19:13
> Aan: [email-masked]

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Fri, 25 Apr 2008 12:26:46 +0200

We now use:

Bert Wijnen
Document shepherd.
co-chair Netconf WG

---

From: Eliot Lear <[email-masked]>
Date: Fri, 25 Apr 2008 13:29:57 +0200

Hi Sharon,

> Proposed Edits

RFC 3339 specifically uses a subset of ISO.8601.1988.  As this 
discussion illustrates it is possible to construct times that are

---

From: Eliot Lear <[email-masked]>
Date: Fri, 25 Apr 2008 13:29:57 +0200

Hi Sharon,

RFC 3339 specifically uses a subset of ISO.8601.1988.  As this 
discussion illustrates it is possible to construct times thatcompliant with the latter and non-compliant with the former.  I believe 
that ISO.8601.1988 is a superset of RFC 3339.  If you wish compliance 
with "both", my recommendation would be to specify only ISO.8601.1988.  
This would meet Juergen's requirement of being able to specify an 
unqualified timezone.

ALTERNATIVELY, you could require times to be in ISO.8601.1988 format, as 
specified in Appendix A of RFC 3339. 

Pointing at two standards covering the precise same specification is 
just asking for a poke in the eye.

Eliot

 are 
compliant with the latter and non-compliant with the former.  I believe 
that ISO.8601.1988 is a superset of RFC 3339.  If you wish compliance 
with "both", my recommendation would be to specify only ISO.8601.1988.  
This would meet Juergen's requirement of being able to specify an 
unqualified timezone.

ALTERNATIVELY, you could require times to be in ISO.8601.1988 format, as 
specified in Appendix A of RFC 3339. 

Pointing at two standards covering the precise same specification is 
just asking for a poke in the eye.

Eliot

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 25 Apr 2008 13:44:07 +0200

> just asking for a poke in the eye.

Good bureaucratic comment. Reading section 4.4 or RFC 3339, I should
probably shut up and be fine with requiring a timezone to be known by
a conforming device and then we can perhaps go with the RFC 3339
subset.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 25 Apr 2008 13:44:07 +0200

/js

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 25 Apr 2008 08:23:10 -0400

Hi

Actually, I changed it in 4 places since I found another while editing.

Sharon 

-----Original Message-----
From: Bert Wijnen - IETF [mailto:[email-masked]] 
Sent: Friday, April 25, 2008 6:25 AM
To: Andy Bierman; Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: RE: [Netconf] Notifications: Proposed Edits to Resolve
DiscussIssues

I believe that in the pre-13 document that Sharon posted she changed
them all. Agreed?

Bert Wijnen 

> This list looks fine, except M should list 3 imports (missing the 1 in

> the 2nd XSD).

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 25 Apr 2008 08:23:10 -0400

Hi

Sharon 

-----Original Message-----
From: Bert Wijnen - IETF [mailto:[email-masked]] 
Sent: Friday, April 25, 2008 6:25 AM
To: Andy Bierman; Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: RE: [Netconf] Notifications: Proposed Edits to Resolve
DiscussIssues

Bert Wijnen

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 25 Apr 2008 12:02:44 -0600

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Eliot Lear" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, April 25, 2008 5:44 AM
> Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues
....
> a conforming device and then we can perhaps go with the RFC 3339
...

If the device truly doesn't know its timezone, wouldn't RFC 3339 section 4.3
apply anyway?

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 25 Apr 2008 12:02:44 -0600

Hi -

....
...

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 25 Apr 2008 21:28:01 +0200

On Fri, Apr 25, 2008 at 12:02:44PM -0600, Randy Presuhn wrote:
 
> If the device truly doesn't know its timezone, wouldn't RFC 3339
> section 4.3 apply anyway?

4.3 applies "if the time in UTC is known, but the offset to local time
is unknown". I am/was concerned about devices where "the local time is
known and the offset to UTC is unknown" - and this is where section
4.4 says "the interoperability problems of unqualified local time are
deemed unacceptable for the Internet."

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 25 Apr 2008 21:28:01 +0200

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 25 Apr 2008 13:00:08 -0600

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, April 25, 2008 1:28 PM
...

Ah.  Reminds me of the joke about the mathematician who'd rather have
a broken watch because it was certain to be correct twice a day, while
a running watch might never be right.  :-)

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 25 Apr 2008 13:00:08 -0600

Hi -

...

Randy

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 28 Apr 2008 13:28:20 -0400

I believe we should follow RFC3339 section 4.4

David Harrington
[email-masked]
[email-masked]
[email-masked]

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Friday, April 25, 2008 7:44 AM
> To: Eliot Lear
> Cc: [email-masked]
> > > [ISO.8601.From [email-masked]  Mon Apr 28 10:28:42 2008
From: "David B Harrington" <[email-masked]>
To: <[email-masked]>,
	"'Eliot Lear'" <[email-masked]>
Date: Mon, 28 Apr 2008 13:28:20 -0400
Cc: [email-masked]
Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss	Issues
Sender: [email-masked]

I believe we should follow RFC3339 section 4.4

David Harrington
[email-masked]
[email-masked]
[email-masked]

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Friday, April 25, 2008 7:44 AM
> To: Eliot Lear
> Cc: [email-masked]

1988].

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 28 Apr 2008 13:28:20 -0400

Hi bert,

There were a bunch of issues I raised on 4/23 that I think Sharon just
didn't understand and didn't fix. here's one:

--
In section 7, the text says "If a user does not have
   permission to view content via other NETCONF operations, she must
not
   have access to that content via Notifications." 

This creates a big CLR.

Can content from a syslog or SNMP notification stream be sent to a
user that does not have permission to access the syslog or SNMP
content using some other Netconf operation? What other Netconf
operation works with the syslog stream? Didn't we explicitly decide it
was not necessary to support <get> access to notication streams
(including syslog and SNMP streams)?

I am also concerned that this access control "policy" should be an
administrative one, not a hard choice of the protocol standard. In
most cases it is the right choice. But a NOC manager might want to
allow, say, the helpdesk to be alerted whenever a Netconf config is
being changed, or an intrusion detection application to be alerted
when there is an authentication failure. And yet, they may not want to
give the helpdesk or the IDS <get> permissions. With this CLR, a NOC
manager is simply not allowed to make such a decision.

I understand the intent; I think the wording is poorly chosen,
especially because it uses a "must", which has special RFC2119 meaning
and creates a huge CLR. And since access control will be done later, I
don't think the WG wants this CLR constraining all future AC designs. 

But I could be wrong; maybe the WG will decide this is exactly what
they want to say. If that is the case, then I think we need to review
this document to make sure everything else (like syslog streams) can
work with this CLR.

dbh

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 28 Apr 2008 13:28:20 -0400

Hi bert,

This creates a big CLR.

dbh

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 28 Apr 2008 13:30:40 -0400

Hi,

> Dave, are you ahppy now with the document Sharon posted?

No, I raised issues on 4/23 that have not been resolved.

--
In section 3.2, the text says, "It does not mandate and/or preclude an

 implementation." 

I think this text is inaccurate. I think it should say "It does not
mandate and/or preclude any particular choice of implementation."

--
In section 3.6, Sharon removed text that explained how to apply
multiple filter elements in a filter. The original text was not very
clear, but deleting the text might impact interoperability. We need a
clearer statement about how multiple filter elements are combined -
are they combined using AND logic? OR logic? The original text implied
AND logic. Is that the intent? Is that intent still communicated after
removing this paragraph?

-- 
I sent a separate mail discussing the access control CLR issue I
raised.

dbh

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 28 Apr 2008 13:30:40 -0400

Hi,

 implementation." 

dbh

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Tue, 29 Apr 2008 08:41:25 +0200

Inline

Bert Wijnen

> Van: David B Harrington [mailto:[email-masked]]
> Verzonden: maandag 28 april 2008 19:31
> Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; [email-masked]
> Onderwerp: Issue X: replaying replay
>
>
> Hi,
>

Your wording might indeed be a bit clearer.
I think SHaron's text was fine too, but your's is somewhat better (in my
reading). If Sharon/Hector agree, she can change it to yours.

Well, the text she removed was confuing IESG member(s).
If we need text, it seems like we possibly need much more text, because
it was unclear that we speak about just one filter, but multiple filter
elements. Can you suggest new text that you thFrom [email-masked]  Mon Apr 28 23:41:46 2008
From: "Bert Wijnen - IETF" <[email-masked]>
To: "David B Harrington" <[email-masked]>,
	"'Sharon Chisholm'" <[email-masked]>, <[email-masked]>
Date: Tue, 29 Apr 2008 08:41:25 +0200
Importance: Normal
Subject: Re: [Netconf] Issue X: replaying replay
Sender: [email-masked]

Inline

Bert Wijnen

> Van: David B Harrington [mailto:[email-masked]]
> Verzonden: maandag 28 april 2008 19:31
> Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; [email-masked]
> Onderwerp: Issue X: replaying replay
>
>
> Hi,
>

Your wording might indeed be a bit clearer.
I think SHaron's text was fine too, but your's is somewhat better (in my
reading). If Sharon/Hector agree, she can change it to yours.

Well, the text she removed was confuing IESG member(s).
If we need text, it seems like we possibly need much more text, because
it was unclear that we speak about just one filter, but multiple filter
elements. Can you suggest new text that ink would address the concern?
I need to check if we did post the concern and discussion we had with the
AD. But if it helps, we can post that, so you can see how it went.

Answered that separately.

Bert

you think would address the concern?
I need to check if we did post the concern and discussion we had with the
AD. But if it helps, we can post that, so you can see how it went.

Answered that separately.

Bert

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Tue, 29 Apr 2008 08:41:25 +0200

Dave, this is a clarification to an concern from an IESG member.
It is in the "Security Considerations" section, so it is not
a "hard choice of protocol standard". We are explaining in the
security considerations section what kind of access concerns 
there might be. Does that clarify?

Sharon, do you have other comments on Dave's concern?

Bert Wijnen 

> Verzonden: maandag 28 april 2008 19:28
> Onderwerp: Issue X: access to notification content
> 
> 
> Hi bert,
>

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Tue, 29 Apr 2008 08:41:25 +0200

Bert Wijnen

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 29 Apr 2008 10:25:00 -0400

Hi,

If it is only a discussion, then I suggest rewording "she must not
..." to "she probably should not ... depending on the access control
model and administrative policy." 

This does not create a CLR.

dbh

> Sent: Tuesday, April 29, 2008 2:41 AM
> To: David B Harrington; 'Sharon Chisholm'; [email-masked]
> Subject: RE: Issue X: access to notification content
>

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 29 Apr 2008 10:25:00 -0400

Hi,

dbh

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 29 Apr 2008 11:20:35 -0400

Hi,

The IESG concern was the ambiguity of "collectively"; the rules need
to be made clearer, not simply removed.
From David Ward: "The language rules of "collectively" need to be
disambiguated. What happens in error conditions? Conflicting requests?
Which wins?"

I think this is clearer:
"Multiple filter elements may be specified as part of a filter. When
multiple filter elements are specified, they are applied collectively
(using AND logic), so event notifications need to pass all specified
   filter elements in order to be sent to the subscriber. 

   For subtree filtering, a non-empty node set means that the filter
   matches.  For XPath filtering, the mechanisms defined in [XPATH]
   should be used to convert the returned value to boolean."

This does not address the question about error conditions. Does an
error condition ALWAYS mean the filter element fails? Is it possible
to get a non-empty node set AND an error condition when using subtree
filtering? Does an error condition always mean that an XPath
expression will evaluate to boolean false) or does it mean the boolean
is not determined? (Cf: an SNMPv1 error condition means you cannot
trust any values in the varbinds - they are just garbage values.) 

This does not address the concern about conflicting requests. I do not
understand what "conflicting request" means. We should get that
clarified.

When a server is evaluating multiple filter elements in a filter
expression, is there any requirement that the evaluation of different
elements be done "as if simultaneous"? 

David Harrington
[email-masked]
[email-masked]
[email-masked]

> Subject: RE: Issue X: replaying replay
> 
> Inline
> 
> Bert Wijnen
> 
> elements. Can you suggest new text that you think would 
> address the concern?

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 29 Apr 2008 11:20:35 -0400

Hi,

I think this is clearer:

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 30 Apr 2008 14:26:50 -0400

Hi

Inline 

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Monday, April 28, 2008 1:31 PM
To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); [email-masked]
Subject: Issue X: replaying replay

Hi,

 implementation." 

<sharon>
I'm fine with this change
</sharon>

--
In section 3.6, Sharon removed text that explained how to apply multiple
filter elements in a filter. The original text was not very clear, but
deleting the text might impact interoperability. We need a clearer
statement about how multiple filter elements are combined - are they
combined using AND logic? OR logic? The original text implied AND logic.
Is that the intent? Is that intent still communicated after removing
this paragraph?
<sharon>
Note there is only one filter, which is either Xpath of subtree. How to
combine Xpath together is defined in W3C documents and how to do subtree
is defined in the base prFrom [email-masked]  Wed Apr 30 11:27:06 2008
Content-class: urn:content-classes:message
Date: Wed, 30 Apr 2008 14:26:50 -0400
From: "Sharon Chisholm" <[email-masked]>
To: "David B Harrington" <[email-masked]>,
	"Bert Wijnen - IETF" <[email-masked]>, <[email-masked]>
Subject: Re: [Netconf] Issue X: replaying replay
Sender: [email-masked]

Hi

Inline 

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Monday, April 28, 2008 1:31 PM
To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); [email-masked]
Subject: Issue X: replaying replay

Hi,

 implementation." 

<sharon>
I'm fine with this change
</sharon>

--
In section 3.6, Sharon removed text that explained how to apply multiple
filter elements in a filter. The original text was not very clear, but
deleting the text might impact interoperability. We need a clearer
statement about how multiple filter elements are combined - are they
combined using AND logic? OR logic? The original text implied AND logic.
Is that the intent? Is that intent still communicated after removing
this paragraph?
<sharon>
Note there is only one filter, which is either Xpath of subtree. How to
combine Xpath together is defined in W3C documents and how to do subtree
is defined in the botocol specifications. We could add some
references to these documents if you feel it would help.
</sharon>

--
I sent a separate mail discussing the access control CLR issue I raised.

dbh

ase protocol specifications. We could add some
references to these documents if you feel it would help.
</sharon>

--
I sent a separate mail discussing the access control CLR issue I raised.

dbh

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 30 Apr 2008 14:39:08 -0400

Hi

I can change from "she must not" to "she likely will not". I think the
probably softens things too much. The intent is that you only get to
view content you have permission to view, regardless of the access
mechanisms. 

Sharon 

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Tuesday, April 29, 2008 10:25 AM
To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); [email-masked]
Subject: RE: Issue X: access to notification content

Hi,

If it is only a discussion, then I suggest rewording "she must not ..."
to "she probably should not ... depending on the access control model
and administrative policy." 

dbh

> It is in the "Security Considerations" section, so it is not a "hard 
> choice of protocol standard". We are explaining in the security 
> considerations section what kind of access concerns there might be. 
> Does that clarify?
>

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 30 Apr 2008 14:39:08 -0400

Hi

Sharon 

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Tuesday, April 29, 2008 10:25 AM
To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); [email-masked]
Subject: RE: Issue X: access to notification content

Hi,

dbh

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 30 Apr 2008 17:52:45 -0400

Hi,

I don't think your proposed change addresses the security review
concern. It doesn't say how access will be controlled.

I think my proposed text does, by saying it will be handled by the
access control model and adminstrative policy.

Is there a reason you don't find my proposed text acceptable?

dbh

> From: Sharon Chisholm [mailto:[email-masked]] 
> Sent: Wednesday, April 30, 2008 2:39 PM
> To: David B Harrington; Bert Wijnen - IETF; [email-masked]
> -----Original Message-----From [email-masked]  Wed Apr 30 14:53:02 2008
From: "David B Harrington" <[email-masked]>
To: "'Sharon Chisholm'" <[email-masked]>,
	"'Bert Wijnen - IETF'" <[email-masked]>, <[email-masked]>
Date: Wed, 30 Apr 2008 17:52:45 -0400
Subject: Re: [Netconf] Issue X: access to notification content
Sender: [email-masked]

Hi,

I don't think your proposed change addresses the security review
concern. It doesn't say how access will be controlled.

I think my proposed text does, by saying it will be handled by the
access control model and adminstrative policy.

Is there a reason you don't find my proposed text acceptable?

dbh

> From: Sharon Chisholm [mailto:[email-masked]] 
> Sent: Wednesday, April 30, 2008 2:39 PM
> To: David B Harrington; Bert Wijnen - IETF; [email-masked]
> Fro

m: David B Harrington [mailto:[email-masked]]