From netconf-bounces@ietf.org Wed Apr 2 07:36:14 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF68F28C576; Wed, 2 Apr 2008 07:36:14 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8904E3A6D3B for ; Wed, 2 Apr 2008 07:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.164 X-Spam-Level: X-Spam-Status: No, score=-4.164 tagged_above=-999 required=5 tests=[AWL=2.434, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pzmNQ9bLcab for ; Wed, 2 Apr 2008 07:36:12 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id A22F828C576 for ; Wed, 2 Apr 2008 07:36:11 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m32Ea9Xm010605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 16:36:09 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m32Ea5g5019622; Wed, 2 Apr 2008 16:36:05 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 16:36:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 16:36:02 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of the NETCONF WG Session in IETF 71 and Action Items Thread-Index: AciUzt/qnNaeOgddTcyfe29+X5lQuw== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 02 Apr 2008 14:36:05.0214 (UTC) FILETIME=[E1C6DFE0:01C894CE] Subject: [Netconf] Summary of the NETCONF WG Session in IETF 71 and Action Items X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0424726065==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0424726065== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C894CE.E16E144A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C894CE.E16E144A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, after having sent out the preliminary minutes we need to=20 confirm a few results of the NETCONF session. Below is a=20 summary. We'll send out separate mails for important topics for confirmation. =3D> Authors of WG items:=20 Please prepare a new version of your document. =3D> WG members:=20 Please review updated documents and trigger a=20 discussion promptly. ( *) indicates that a separate confirmation mail will be sent out) A) Ongoing or planned implementations for the chartered items: *) (Planned) Implementations of Partial Lock (3 hands): Martin B, Balazs?, Sharon *) (Planned) Implementations of NETCONF Monitoring (4 hands): Martin B, Andy, Sharon, Mark *) (Planned) Implementations of NETCONF over TLS: No one in the audience was planning to implement. After the meeting Mohamad Badra stated that he is=20 implementing. We need 2 implementations to be able to get it to draft=20 standard status. We think that even for a proposed standard,=20 it makes no sense if only one single person is planning to=20 implement. A standards track document should be implemented=20 by many (at least 2, but preferably many more).=20 Therefor the chairs have the opinion that it does not=20 make sense to standardize the document if there is no=20 other interested party to implement.=20 So, please respond to the parallel mail if there is anybody=20 implementing or planning to implement. TLS draft issues and AIs: There were a few issues discussed in the session. Since Badra=20 was not there we couldn't asnwer all and got some action=20 items. Chairs note: This topic is on hold till we have an answer on how many implementations are planned for NETCONF over TLS.=20 *) (Planned) Implementations of the Notification draft (4 hands): Martin B, Sharon (2?), Mark B) Interoperability event: In the NETCONF session we asked whether anybody is=20 interested in an interoperability event for chartered=20 documents or on the published RFCs or both. An=20 additional goal would be to prepare a test report=20 to shift NETCONF RFCs to the draft standard status.=20 There was nobody in the WG session interested in an=20 interoperability event. =3D> If anybody is interested in an interoperability=20 event for chartered documents or on the=20 published RFCs please bring it up on the list. C) Potential documents for non-chartered topics: *) Access Control: Andy Bierman and David Harrington in the session and=20 Kaushik Narayan after the session showed interest to=20 work on Access Control.=20 *) Netconf content: There was interest to prepare I-D's for NETCONF=20 Content for CONFIGURATION (and/or NETCONF related)=20 events and also NETCONF Content for SNMP or SYSLOG=20 notifications.=20 D) Other discussion which needs to be brought to the=20 NETCONF list: =3D> Wes Hardaker:=20 Please post your questions on: - what happens if you copy candidate to running=20 while a partial lock is held?=20 - need a matrix that covers the various operations=20 and their interaction Please also post any other questions that we may=20 have missed above. E) SOAP implementation presentation=20 =3D> Folks who volunteer to read and comment to=20 improve the quality please send your comments=20 to Dan Romascanu and copy the NETCONF maillist. Thank you for your support. Bert & Mehmet ------_=_NextPart_001_01C894CE.E16E144A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Summary of the NETCONF WG Session in IETF 71 and Action = Items

Dear NETCONF = WG,

after having sent = out the preliminary minutes we need to
confirm a few = results of the NETCONF session. Below is a
summary. We'll = send out separate mails for important topics
for = confirmation.

=3D> Authors of = WG items:
Please prepare a = new version of your document.

=3D> WG members: =
Please review = updated documents and trigger a
discussion = promptly.

( *) indicates that = a separate confirmation mail will be sent out)


A) Ongoing or = planned implementations for the chartered items:

*) (Planned) = Implementations of Partial Lock (3 hands):
Martin B, Balazs?, = Sharon

*) (Planned) = Implementations of NETCONF Monitoring (4 hands):
Martin B, Andy, = Sharon, Mark

*) (Planned) = Implementations of NETCONF over TLS:
No one in the = audience was planning to implement.
After the meeting = Mohamad Badra stated that he is
implementing.

<Note of the = chairs>
We need 2 = implementations to be able to get it to draft
standard status. = We think that even for a proposed standard,
it makes no sense = if only one single person is planning to
implement. A = standards track document should be implemented
by many (at least = 2, but preferably many more).

Therefor the chairs = have the opinion that it does not
make sense to = standardize the document if there is no
other interested = party to implement.
So, please respond = to the parallel mail if there is anybody
implementing or = planning to implement.
</Note>

TLS draft issues = and AIs:
There were a few = issues discussed in the session. Since Badra
was not there we = couldn't asnwer all and got some action
items.
Chairs note: This = topic is on hold till we have an answer on
how many = implementations are planned for NETCONF over TLS.


*) (Planned) = Implementations of the Notification draft (4 hands):
Martin B, Sharon = (2?), Mark


B) Interoperability = event:

In the NETCONF = session we asked whether anybody is
interested in an = interoperability event for chartered
documents or on = the published RFCs or both. An
additional goal = would be to prepare a test report
to shift NETCONF = RFCs to the draft standard status.

There was nobody in = the WG session interested in an
interoperability = event.

=3D> If anybody = is interested in an interoperability
    = event for chartered documents or on the
    = published RFCs please bring it up on the list.


C) Potential = documents for non-chartered topics:

*) Access = Control:
Andy Bierman and = David Harrington in the session and
Kaushik Narayan = after the session showed interest to
work on Access = Control.

*) Netconf = content:
There was interest = to prepare I-D's for NETCONF
Content for = CONFIGURATION (and/or NETCONF related)
events and also = NETCONF Content for SNMP or SYSLOG
notifications. =

D) Other discussion = which needs to be brought to the
NETCONF = list:

=3D> Wes = Hardaker:
Please post your = questions on:
- what happens if = you copy candidate to running
  while a = partial lock is held?
- need a matrix = that covers the various operations
  and their = interaction
Please also post = any other questions that we may
have missed = above.

E) SOAP = implementation presentation

=3D> Folks who = volunteer to read and comment to
    = improve the quality please send your comments
    = to Dan Romascanu and copy the NETCONF maillist.


Thank you for your = support.

Bert & = Mehmet

------_=_NextPart_001_01C894CE.E16E144A-- --===============0424726065== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0424726065==-- From netconf-bounces@ietf.org Wed Apr 2 07:36:14 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF68F28C576; Wed, 2 Apr 2008 07:36:14 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8904E3A6D3B for ; Wed, 2 Apr 2008 07:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.164 X-Spam-Level: X-Spam-Status: No, score=-4.164 tagged_above=-999 required=5 tests=[AWL=2.434, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pzmNQ9bLcab for ; Wed, 2 Apr 2008 07:36:12 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id A22F828C576 for ; Wed, 2 Apr 2008 07:36:11 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m32Ea9Xm010605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 16:36:09 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m32Ea5g5019622; Wed, 2 Apr 2008 16:36:05 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 16:36:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 16:36:02 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of the NETCONF WG Session in IETF 71 and Action Items Thread-Index: AciUzt/qnNaeOgddTcyfe29+X5lQuw== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 02 Apr 2008 14:36:05.0214 (UTC) FILETIME=[E1C6DFE0:01C894CE] Subject: [Netconf] Summary of the NETCONF WG Session in IETF 71 and Action Items X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0424726065==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0424726065== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C894CE.E16E144A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C894CE.E16E144A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, after having sent out the preliminary minutes we need to=20 confirm a few results of the NETCONF session. Below is a=20 summary. We'll send out separate mails for important topics for confirmation. =3D> Authors of WG items:=20 Please prepare a new version of your document. =3D> WG members:=20 Please review updated documents and trigger a=20 discussion promptly. ( *) indicates that a separate confirmation mail will be sent out) A) Ongoing or planned implementations for the chartered items: *) (Planned) Implementations of Partial Lock (3 hands): Martin B, Balazs?, Sharon *) (Planned) Implementations of NETCONF Monitoring (4 hands): Martin B, Andy, Sharon, Mark *) (Planned) Implementations of NETCONF over TLS: No one in the audience was planning to implement. After the meeting Mohamad Badra stated that he is=20 implementing. We need 2 implementations to be able to get it to draft=20 standard status. We think that even for a proposed standard,=20 it makes no sense if only one single person is planning to=20 implement. A standards track document should be implemented=20 by many (at least 2, but preferably many more).=20 Therefor the chairs have the opinion that it does not=20 make sense to standardize the document if there is no=20 other interested party to implement.=20 So, please respond to the parallel mail if there is anybody=20 implementing or planning to implement. TLS draft issues and AIs: There were a few issues discussed in the session. Since Badra=20 was not there we couldn't asnwer all and got some action=20 items. Chairs note: This topic is on hold till we have an answer on how many implementations are planned for NETCONF over TLS.=20 *) (Planned) Implementations of the Notification draft (4 hands): Martin B, Sharon (2?), Mark B) Interoperability event: In the NETCONF session we asked whether anybody is=20 interested in an interoperability event for chartered=20 documents or on the published RFCs or both. An=20 additional goal would be to prepare a test report=20 to shift NETCONF RFCs to the draft standard status.=20 There was nobody in the WG session interested in an=20 interoperability event. =3D> If anybody is interested in an interoperability=20 event for chartered documents or on the=20 published RFCs please bring it up on the list. C) Potential documents for non-chartered topics: *) Access Control: Andy Bierman and David Harrington in the session and=20 Kaushik Narayan after the session showed interest to=20 work on Access Control.=20 *) Netconf content: There was interest to prepare I-D's for NETCONF=20 Content for CONFIGURATION (and/or NETCONF related)=20 events and also NETCONF Content for SNMP or SYSLOG=20 notifications.=20 D) Other discussion which needs to be brought to the=20 NETCONF list: =3D> Wes Hardaker:=20 Please post your questions on: - what happens if you copy candidate to running=20 while a partial lock is held?=20 - need a matrix that covers the various operations=20 and their interaction Please also post any other questions that we may=20 have missed above. E) SOAP implementation presentation=20 =3D> Folks who volunteer to read and comment to=20 improve the quality please send your comments=20 to Dan Romascanu and copy the NETCONF maillist. Thank you for your support. Bert & Mehmet ------_=_NextPart_001_01C894CE.E16E144A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Summary of the NETCONF WG Session in IETF 71 and Action = Items

Dear NETCONF = WG,

after having sent = out the preliminary minutes we need to
confirm a few = results of the NETCONF session. Below is a
summary. We'll = send out separate mails for important topics
for = confirmation.

=3D> Authors of = WG items:
Please prepare a = new version of your document.

=3D> WG members: =
Please review = updated documents and trigger a
discussion = promptly.

( *) indicates that = a separate confirmation mail will be sent out)


A) Ongoing or = planned implementations for the chartered items:

*) (Planned) = Implementations of Partial Lock (3 hands):
Martin B, Balazs?, = Sharon

*) (Planned) = Implementations of NETCONF Monitoring (4 hands):
Martin B, Andy, = Sharon, Mark

*) (Planned) = Implementations of NETCONF over TLS:
No one in the = audience was planning to implement.
After the meeting = Mohamad Badra stated that he is
implementing.

<Note of the = chairs>
We need 2 = implementations to be able to get it to draft
standard status. = We think that even for a proposed standard,
it makes no sense = if only one single person is planning to
implement. A = standards track document should be implemented
by many (at least = 2, but preferably many more).

Therefor the chairs = have the opinion that it does not
make sense to = standardize the document if there is no
other interested = party to implement.
So, please respond = to the parallel mail if there is anybody
implementing or = planning to implement.
</Note>

TLS draft issues = and AIs:
There were a few = issues discussed in the session. Since Badra
was not there we = couldn't asnwer all and got some action
items.
Chairs note: This = topic is on hold till we have an answer on
how many = implementations are planned for NETCONF over TLS.


*) (Planned) = Implementations of the Notification draft (4 hands):
Martin B, Sharon = (2?), Mark


B) Interoperability = event:

In the NETCONF = session we asked whether anybody is
interested in an = interoperability event for chartered
documents or on = the published RFCs or both. An
additional goal = would be to prepare a test report
to shift NETCONF = RFCs to the draft standard status.

There was nobody in = the WG session interested in an
interoperability = event.

=3D> If anybody = is interested in an interoperability
    = event for chartered documents or on the
    = published RFCs please bring it up on the list.


C) Potential = documents for non-chartered topics:

*) Access = Control:
Andy Bierman and = David Harrington in the session and
Kaushik Narayan = after the session showed interest to
work on Access = Control.

*) Netconf = content:
There was interest = to prepare I-D's for NETCONF
Content for = CONFIGURATION (and/or NETCONF related)
events and also = NETCONF Content for SNMP or SYSLOG
notifications. =

D) Other discussion = which needs to be brought to the
NETCONF = list:

=3D> Wes = Hardaker:
Please post your = questions on:
- what happens if = you copy candidate to running
  while a = partial lock is held?
- need a matrix = that covers the various operations
  and their = interaction
Please also post = any other questions that we may
have missed = above.

E) SOAP = implementation presentation

=3D> Folks who = volunteer to read and comment to
    = improve the quality please send your comments
    = to Dan Romascanu and copy the NETCONF maillist.


Thank you for your = support.

Bert & = Mehmet

------_=_NextPart_001_01C894CE.E16E144A-- --===============0424726065== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0424726065==-- From netconf-bounces@ietf.org Wed Apr 2 07:39:03 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F6A73A6DB0; Wed, 2 Apr 2008 07:39:03 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D113A6EB5 for ; Wed, 2 Apr 2008 07:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.57 X-Spam-Level: X-Spam-Status: No, score=-4.57 tagged_above=-999 required=5 tests=[AWL=2.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4mYnH2hDImy for ; Wed, 2 Apr 2008 07:38:57 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id EBDAB3A6DB1 for ; Wed, 2 Apr 2008 07:38:56 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m32Ecs4T011359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 16:38:54 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m32Ecsmk021047; Wed, 2 Apr 2008 16:38:54 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 16:38:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 16:38:53 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Confirmation of planned Notification draft Implementations Thread-Index: AciUz0XT0TQlkkMBTfebzWEzSNAdMQ== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 02 Apr 2008 14:38:54.0546 (UTC) FILETIME=[46B4E320:01C894CF] Subject: [Netconf] Confirmation of planned Notification draft Implementations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1880089255==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1880089255== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C894CF.4677C7A2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C894CF.4677C7A2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, during the NETCONF WG session in IETF 71 the co-chairs asked whether anybody is going to implement the 'Notification'=20 draft. IWRC the result was: (Planned) Implementations of Notification draft (4 hands): Martin B, Sharon (2?), Mark Q1) Those who showed hands in the meeting please confirm=20 your implementation plans. Q2- Others please speak up on the maillist if you are going=20 to implement one of the chartered items. Note: If someone does not want to disclose his implementation plans to the list but wants to be counted please send a private=20 mail to the co-chairs. We will not disclose the names of people=20 who request to be counted as anonymous. PS: What we are talking about are "implementations with=20 independent code base". Thank you. Bert & Mehmet ------_=_NextPart_001_01C894CF.4677C7A2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Confirmation of planned Notification draft = Implementations

Dear = All,

during the NETCONF = WG session in IETF 71 the co-chairs
asked whether = anybody is going to implement the 'Notification'
draft.

IWRC the result = was:

(Planned) = Implementations of Notification draft (4 hands):
Martin B, Sharon = (2?), Mark

Q1) Those who = showed hands in the meeting please confirm
your = implementation plans.

Q2- Others please = speak up on the maillist if you are going
to implement one = of the chartered items.

Note: If someone = does not want to disclose his implementation
plans to the list = but wants to be counted please send a private
mail to the = co-chairs. We will not disclose the names of people
who request to be = counted as anonymous.

PS: What we are = talking about are "implementations with
independent code = base".

Thank = you.

Bert & = Mehmet

------_=_NextPart_001_01C894CF.4677C7A2-- --===============1880089255== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1880089255==-- From netconf-bounces@ietf.org Wed Apr 2 07:39:03 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F6A73A6DB0; Wed, 2 Apr 2008 07:39:03 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D113A6EB5 for ; Wed, 2 Apr 2008 07:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.57 X-Spam-Level: X-Spam-Status: No, score=-4.57 tagged_above=-999 required=5 tests=[AWL=2.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4mYnH2hDImy for ; Wed, 2 Apr 2008 07:38:57 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id EBDAB3A6DB1 for ; Wed, 2 Apr 2008 07:38:56 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m32Ecs4T011359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 16:38:54 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m32Ecsmk021047; Wed, 2 Apr 2008 16:38:54 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 16:38:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 16:38:53 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Confirmation of planned Notification draft Implementations Thread-Index: AciUz0XT0TQlkkMBTfebzWEzSNAdMQ== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 02 Apr 2008 14:38:54.0546 (UTC) FILETIME=[46B4E320:01C894CF] Subject: [Netconf] Confirmation of planned Notification draft Implementations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1880089255==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1880089255== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C894CF.4677C7A2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C894CF.4677C7A2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, during the NETCONF WG session in IETF 71 the co-chairs asked whether anybody is going to implement the 'Notification'=20 draft. IWRC the result was: (Planned) Implementations of Notification draft (4 hands): Martin B, Sharon (2?), Mark Q1) Those who showed hands in the meeting please confirm=20 your implementation plans. Q2- Others please speak up on the maillist if you are going=20 to implement one of the chartered items. Note: If someone does not want to disclose his implementation plans to the list but wants to be counted please send a private=20 mail to the co-chairs. We will not disclose the names of people=20 who request to be counted as anonymous. PS: What we are talking about are "implementations with=20 independent code base". Thank you. Bert & Mehmet ------_=_NextPart_001_01C894CF.4677C7A2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Confirmation of planned Notification draft = Implementations

Dear = All,

during the NETCONF = WG session in IETF 71 the co-chairs
asked whether = anybody is going to implement the 'Notification'
draft.

IWRC the result = was:

(Planned) = Implementations of Notification draft (4 hands):
Martin B, Sharon = (2?), Mark

Q1) Those who = showed hands in the meeting please confirm
your = implementation plans.

Q2- Others please = speak up on the maillist if you are going
to implement one = of the chartered items.

Note: If someone = does not want to disclose his implementation
plans to the list = but wants to be counted please send a private
mail to the = co-chairs. We will not disclose the names of people
who request to be = counted as anonymous.

PS: What we are = talking about are "implementations with
independent code = base".

Thank = you.

Bert & = Mehmet

------_=_NextPart_001_01C894CF.4677C7A2-- --===============1880089255== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1880089255==-- From netconf-bounces@ietf.org Wed Apr 2 07:39:43 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 706DB28C58D; Wed, 2 Apr 2008 07:39:43 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27B63A6AF6 for ; Wed, 2 Apr 2008 07:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.859 X-Spam-Level: X-Spam-Status: No, score=-2.859 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkyc8WtTud+K for ; Wed, 2 Apr 2008 07:39:41 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id D8D2B3A68F7 for ; Wed, 2 Apr 2008 07:39:40 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m32EdcL4023488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 16:39:38 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m32EdcPe022102; Wed, 2 Apr 2008 16:39:38 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 16:39:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 16:39:36 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Confirmation of planned NETCONF Monitoring Implementations Thread-Index: AciUz1/e4sW9dRdDRCqegG9ps2ZEZg== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 02 Apr 2008 14:39:38.0069 (UTC) FILETIME=[60A5F850:01C894CF] Subject: [Netconf] Confirmation of planned NETCONF Monitoring Implementations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1454163191==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1454163191== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C894CF.6062E24A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C894CF.6062E24A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, during the NETCONF WG session in IETF 71 the co-chairs=20 asked whether anybody is going to implement the 'NETCONF=20 Monitoring' draft. IWRC the result was: (Planned) Implementations of NETCONF Monitoring (4 hands): Martin B, Andy, Sharon, Mark Q1) Those who showed hands in the meeting please confirm=20 your implementation plans. Q2- Others please speak up on the maillist if you are going=20 to implement the 'NETCONF Monitoring' draft. Note: If someone does not want to disclose his implementation plans to the list but wants to be counted please send a private=20 mail to the co-chairs. We will not disclose the names of people=20 who request to be counted as anonymous. PS: What we are talking about are "implementations with=20 independent code base". Thank you. Bert & Mehmet ------_=_NextPart_001_01C894CF.6062E24A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Confirmation of planned NETCONF Monitoring = Implementations

Dear = All,

during the NETCONF = WG session in IETF 71 the co-chairs
asked whether = anybody is going to implement the 'NETCONF
Monitoring' = draft.

IWRC the result = was:

(Planned) = Implementations of NETCONF Monitoring (4 hands):
Martin B, Andy, = Sharon, Mark

Q1) Those who = showed hands in the meeting please confirm
your = implementation plans.

Q2- Others please = speak up on the maillist if you are going
to implement the = 'NETCONF Monitoring' draft.

Note: If someone = does not want to disclose his implementation
plans to the list = but wants to be counted please send a private
mail to the = co-chairs. We will not disclose the names of people
who request to be = counted as anonymous.

PS: What we are = talking about are "implementations with
independent code = base".

Thank = you.

Bert & = Mehmet

------_=_NextPart_001_01C894CF.6062E24A-- --===============1454163191== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1454163191==-- From netconf-bounces@ietf.org Wed Apr 2 07:39:43 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 706DB28C58D; Wed, 2 Apr 2008 07:39:43 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27B63A6AF6 for ; Wed, 2 Apr 2008 07:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.859 X-Spam-Level: X-Spam-Status: No, score=-2.859 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkyc8WtTud+K for ; Wed, 2 Apr 2008 07:39:41 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id D8D2B3A68F7 for ; Wed, 2 Apr 2008 07:39:40 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m32EdcL4023488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 16:39:38 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m32EdcPe022102; Wed, 2 Apr 2008 16:39:38 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 16:39:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 16:39:36 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Confirmation of planned NETCONF Monitoring Implementations Thread-Index: AciUz1/e4sW9dRdDRCqegG9ps2ZEZg== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 02 Apr 2008 14:39:38.0069 (UTC) FILETIME=[60A5F850:01C894CF] Subject: [Netconf] Confirmation of planned NETCONF Monitoring Implementations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1454163191==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1454163191== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C894CF.6062E24A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C894CF.6062E24A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, during the NETCONF WG session in IETF 71 the co-chairs=20 asked whether anybody is going to implement the 'NETCONF=20 Monitoring' draft. IWRC the result was: (Planned) Implementations of NETCONF Monitoring (4 hands): Martin B, Andy, Sharon, Mark Q1) Those who showed hands in the meeting please confirm=20 your implementation plans. Q2- Others please speak up on the maillist if you are going=20 to implement the 'NETCONF Monitoring' draft. Note: If someone does not want to disclose his implementation plans to the list but wants to be counted please send a private=20 mail to the co-chairs. We will not disclose the names of people=20 who request to be counted as anonymous. PS: What we are talking about are "implementations with=20 independent code base". Thank you. Bert & Mehmet ------_=_NextPart_001_01C894CF.6062E24A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Confirmation of planned NETCONF Monitoring = Implementations

Dear = All,

during the NETCONF = WG session in IETF 71 the co-chairs
asked whether = anybody is going to implement the 'NETCONF
Monitoring' = draft.

IWRC the result = was:

(Planned) = Implementations of NETCONF Monitoring (4 hands):
Martin B, Andy, = Sharon, Mark

Q1) Those who = showed hands in the meeting please confirm
your = implementation plans.

Q2- Others please = speak up on the maillist if you are going
to implement the = 'NETCONF Monitoring' draft.

Note: If someone = does not want to disclose his implementation
plans to the list = but wants to be counted please send a private
mail to the = co-chairs. We will not disclose the names of people
who request to be = counted as anonymous.

PS: What we are = talking about are "implementations with
independent code = base".

Thank = you.

Bert & = Mehmet

------_=_NextPart_001_01C894CF.6062E24A-- --===============1454163191== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1454163191==-- From netconf-bounces@ietf.org Wed Apr 2 07:39:50 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B96DE28C5A2; Wed, 2 Apr 2008 07:39:50 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E90C28C56E for ; Wed, 2 Apr 2008 07:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.827 X-Spam-Level: X-Spam-Status: No, score=-4.827 tagged_above=-999 required=5 tests=[AWL=1.771, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3H5YwWYXZIIc for ; Wed, 2 Apr 2008 07:39:48 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 3210828C57E for ; Wed, 2 Apr 2008 07:39:48 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m32EdlU8012117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 16:39:47 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m32Edjkg021442; Wed, 2 Apr 2008 16:39:47 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 16:39:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 16:39:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Confirmation of planned Partial Locking Implementations Thread-Index: AciUz2UrFDQXbuGsQJKGNauG1qGJ4Q== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 02 Apr 2008 14:39:46.0749 (UTC) FILETIME=[65D26ED0:01C894CF] Subject: [Netconf] Confirmation of planned Partial Locking Implementations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0152648507==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0152648507== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C894CF.65A850DA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C894CF.65A850DA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, during the NETCONF WG session in IETF 71 the co-chairs=20 asked whether anybody is going to implement the 'Partial=20 Locking' draft. IWRC the result was: (Planned) Implementations of Partial Lock (3 hands): Martin B, Balazs?, Sharon Q1) Those who showed hands in the meeting please confirm=20 your implementation plans. Q2- Others please speak up on the maillist if you are going=20 to implement the 'Partial Locking' draft. Note: If someone does not want to disclose his implementation plans to the list but wants to be counted please send a private=20 mail to the co-chairs. We will not disclose the names of people=20 who request to be counted as anonymous. PS: What we are talking about are "implementations with=20 independent code base". Thank you. Bert & Mehmet ------_=_NextPart_001_01C894CF.65A850DA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Confirmation of planned Partial Locking Implementations

Dear = All,

during the NETCONF = WG session in IETF 71 the co-chairs
asked whether = anybody is going to implement the 'Partial
Locking' = draft.

IWRC the result = was:

(Planned) = Implementations of Partial Lock (3 hands):
Martin B, Balazs?, = Sharon

Q1) Those who = showed hands in the meeting please confirm
your = implementation plans.

Q2- Others please = speak up on the maillist if you are going
to implement the = 'Partial Locking' draft.

Note: If someone = does not want to disclose his implementation
plans to the list = but wants to be counted please send a private
mail to the = co-chairs. We will not disclose the names of people
who request to be = counted as anonymous.

PS: What we are = talking about are "implementations with
independent code = base".

Thank = you.

Bert & = Mehmet

------_=_NextPart_001_01C894CF.65A850DA-- --===============0152648507== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0152648507==-- From netconf-bounces@ietf.org Wed Apr 2 07:39:50 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B96DE28C5A2; Wed, 2 Apr 2008 07:39:50 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E90C28C56E for ; Wed, 2 Apr 2008 07:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.827 X-Spam-Level: X-Spam-Status: No, score=-4.827 tagged_above=-999 required=5 tests=[AWL=1.771, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3H5YwWYXZIIc for ; Wed, 2 Apr 2008 07:39:48 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 3210828C57E for ; Wed, 2 Apr 2008 07:39:48 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m32EdlU8012117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 16:39:47 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m32Edjkg021442; Wed, 2 Apr 2008 16:39:47 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 16:39:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 16:39:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Confirmation of planned Partial Locking Implementations Thread-Index: AciUz2UrFDQXbuGsQJKGNauG1qGJ4Q== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 02 Apr 2008 14:39:46.0749 (UTC) FILETIME=[65D26ED0:01C894CF] Subject: [Netconf] Confirmation of planned Partial Locking Implementations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0152648507==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0152648507== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C894CF.65A850DA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C894CF.65A850DA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, during the NETCONF WG session in IETF 71 the co-chairs=20 asked whether anybody is going to implement the 'Partial=20 Locking' draft. IWRC the result was: (Planned) Implementations of Partial Lock (3 hands): Martin B, Balazs?, Sharon Q1) Those who showed hands in the meeting please confirm=20 your implementation plans. Q2- Others please speak up on the maillist if you are going=20 to implement the 'Partial Locking' draft. Note: If someone does not want to disclose his implementation plans to the list but wants to be counted please send a private=20 mail to the co-chairs. We will not disclose the names of people=20 who request to be counted as anonymous. PS: What we are talking about are "implementations with=20 independent code base". Thank you. Bert & Mehmet ------_=_NextPart_001_01C894CF.65A850DA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Confirmation of planned Partial Locking Implementations

Dear = All,

during the NETCONF = WG session in IETF 71 the co-chairs
asked whether = anybody is going to implement the 'Partial
Locking' = draft.

IWRC the result = was:

(Planned) = Implementations of Partial Lock (3 hands):
Martin B, Balazs?, = Sharon

Q1) Those who = showed hands in the meeting please confirm
your = implementation plans.

Q2- Others please = speak up on the maillist if you are going
to implement the = 'Partial Locking' draft.

Note: If someone = does not want to disclose his implementation
plans to the list = but wants to be counted please send a private
mail to the = co-chairs. We will not disclose the names of people
who request to be = counted as anonymous.

PS: What we are = talking about are "implementations with
independent code = base".

Thank = you.

Bert & = Mehmet

------_=_NextPart_001_01C894CF.65A850DA-- --===============0152648507== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0152648507==-- From netconf-bounces@ietf.org Wed Apr 2 07:41:14 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23ED328C57E; Wed, 2 Apr 2008 07:41:14 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CF1528C571 for ; Wed, 2 Apr 2008 07:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.024 X-Spam-Level: X-Spam-Status: No, score=-5.024 tagged_above=-999 required=5 tests=[AWL=1.574, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JerP3ioSp8pU for ; Wed, 2 Apr 2008 07:41:12 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 4E0A028C5A6 for ; Wed, 2 Apr 2008 07:40:41 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m32EecIW012393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 16:40:38 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m32EeZrU022708; Wed, 2 Apr 2008 16:40:38 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 16:40:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 16:40:36 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Confirmation of plans to prepare drafts for Netconf Content Thread-Index: AciUz4OZChtVkjPkTtCsDyjWHV2VbA== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 02 Apr 2008 14:40:37.0609 (UTC) FILETIME=[84230D90:01C894CF] Subject: [Netconf] Confirmation of plans to prepare drafts for Netconf Content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1667075386==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1667075386== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C894CF.83F3F912" This is a multi-part message in MIME format. ------_=_NextPart_001_01C894CF.83F3F912 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, in the NETCONF WG session in IETF 71 a few=20 attendees showed interest to prepare I-D's for=20 NETCONF Content for CONFIGURATION (and/or=20 NETCONF related) events and also NETCONF=20 Content for SNMP or SYSLOG notifications.=20 Please confirm your plans on preparing I-Ds for=20 Netconf content on the maillist. Thank you. Bert & Mehmet ------_=_NextPart_001_01C894CF.83F3F912 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Confirmation of plans to prepare drafts for Netconf = Content

Dear = All,

in the NETCONF WG = session in IETF 71 a few
attendees showed = interest to prepare I-D's for
NETCONF Content = for CONFIGURATION (and/or
NETCONF related) = events and also NETCONF
Content for SNMP = or SYSLOG notifications.

Please confirm your = plans on preparing I-Ds for
Netconf content on = the maillist.

Thank = you.

Bert & = Mehmet

------_=_NextPart_001_01C894CF.83F3F912-- --===============1667075386== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1667075386==-- From netconf-bounces@ietf.org Wed Apr 2 07:41:14 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23ED328C57E; Wed, 2 Apr 2008 07:41:14 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CF1528C571 for ; Wed, 2 Apr 2008 07:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.024 X-Spam-Level: X-Spam-Status: No, score=-5.024 tagged_above=-999 required=5 tests=[AWL=1.574, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JerP3ioSp8pU for ; Wed, 2 Apr 2008 07:41:12 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 4E0A028C5A6 for ; Wed, 2 Apr 2008 07:40:41 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m32EecIW012393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 16:40:38 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m32EeZrU022708; Wed, 2 Apr 2008 16:40:38 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 16:40:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 16:40:36 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Confirmation of plans to prepare drafts for Netconf Content Thread-Index: AciUz4OZChtVkjPkTtCsDyjWHV2VbA== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 02 Apr 2008 14:40:37.0609 (UTC) FILETIME=[84230D90:01C894CF] Subject: [Netconf] Confirmation of plans to prepare drafts for Netconf Content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1667075386==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1667075386== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C894CF.83F3F912" This is a multi-part message in MIME format. ------_=_NextPart_001_01C894CF.83F3F912 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, in the NETCONF WG session in IETF 71 a few=20 attendees showed interest to prepare I-D's for=20 NETCONF Content for CONFIGURATION (and/or=20 NETCONF related) events and also NETCONF=20 Content for SNMP or SYSLOG notifications.=20 Please confirm your plans on preparing I-Ds for=20 Netconf content on the maillist. Thank you. Bert & Mehmet ------_=_NextPart_001_01C894CF.83F3F912 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Confirmation of plans to prepare drafts for Netconf = Content

Dear = All,

in the NETCONF WG = session in IETF 71 a few
attendees showed = interest to prepare I-D's for
NETCONF Content = for CONFIGURATION (and/or
NETCONF related) = events and also NETCONF
Content for SNMP = or SYSLOG notifications.

Please confirm your = plans on preparing I-Ds for
Netconf content on = the maillist.

Thank = you.

Bert & = Mehmet

------_=_NextPart_001_01C894CF.83F3F912-- --===============1667075386== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1667075386==-- From netconf-bounces@ietf.org Wed Apr 2 07:41:15 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF9C28C5B4; Wed, 2 Apr 2008 07:41:15 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD47928C5C2 for ; Wed, 2 Apr 2008 07:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.181 X-Spam-Level: X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=-0.583, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wbzka-+0P1a3 for ; Wed, 2 Apr 2008 07:41:09 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id E33483A6AF6 for ; Wed, 2 Apr 2008 07:40:02 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m32Ee1Vx023672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 16:40:01 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m32Edqg5022227; Wed, 2 Apr 2008 16:40:01 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 16:39:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 16:39:58 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Confirmation of planned NETCONF over TLS Implementations Thread-Index: AciUz2zOiZrNeYkvRCyRiBduzWnAzA== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 02 Apr 2008 14:39:59.0655 (UTC) FILETIME=[6D83BB70:01C894CF] Subject: [Netconf] Confirmation of planned NETCONF over TLS Implementations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1965491690==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1965491690== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C894CF.6D4B52BA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C894CF.6D4B52BA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, during the NETCONF WG session in IETF 71 the co-chairs asked whether anybody is going to implement the 'NETCONF=20 over TLS' draft. IWRC the result was: (Planned) Implementations of NETCONF over TLS (0 hands): No one in the audience was planning to implement. After the meeting Badra stated that he is implementing. Q: Others please speak up on the maillist if you are going=20 to implement NETCONF over TLS draft. We need 2 implementations to be able to get it to draft=20 standard status. We think that even for a proposed standard,=20 it makes no sense if only one single person is planning to=20 implement. A standards track document should be implemented=20 by many (at least 2, but preferably many more).=20 Therefor the chairs have the opinion that it does not=20 make sense to standardize the document if there is no=20 other interested party to implement.=20 So, please speak up if there is anybody implementing or planning=20 to implement. Note: If someone does not want to disclose his implementation plans to the list but wants to be counted please send a private=20 mail to the co-chairs. We will not disclose the names of people=20 who request to be counted as anonymous. PS: What we are talking about are "implementations with=20 independent code base". Thank you. Bert & Mehmet ------_=_NextPart_001_01C894CF.6D4B52BA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Confirmation of planned NETCONF over TLS Implementations

Dear = All,

during the NETCONF = WG session in IETF 71 the co-chairs
asked whether = anybody is going to implement the 'NETCONF
over TLS' = draft.

IWRC the result = was:

(Planned) = Implementations of NETCONF over TLS (0 hands):
No one in the = audience was planning to implement.

After the meeting = Badra stated that he is implementing.

Q: Others please = speak up on the maillist if you are going
to implement = NETCONF over TLS draft.

<Note of the = chairs>
We need 2 = implementations to be able to get it to draft
standard status. = We think that even for a proposed standard,
it makes no sense = if only one single person is planning to
implement. A = standards track document should be implemented
by many (at least = 2, but preferably many more).

Therefor the chairs = have the opinion that it does not
make sense to = standardize the document if there is no
other interested = party to implement.
So, please speak = up if there is anybody implementing or planning
to = implement.

Note: If someone = does not want to disclose his implementation
plans to the list = but wants to be counted please send a private
mail to the = co-chairs. We will not disclose the names of people
who request to be = counted as anonymous.

PS: What we are = talking about are "implementations with
independent code = base".

Thank = you.

Bert & = Mehmet

------_=_NextPart_001_01C894CF.6D4B52BA-- --===============1965491690== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1965491690==-- From netconf-bounces@ietf.org Wed Apr 2 07:41:15 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF9C28C5B4; Wed, 2 Apr 2008 07:41:15 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD47928C5C2 for ; Wed, 2 Apr 2008 07:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.181 X-Spam-Level: X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=-0.583, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wbzka-+0P1a3 for ; Wed, 2 Apr 2008 07:41:09 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id E33483A6AF6 for ; Wed, 2 Apr 2008 07:40:02 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m32Ee1Vx023672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 16:40:01 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m32Edqg5022227; Wed, 2 Apr 2008 16:40:01 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 16:39:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 16:39:58 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Confirmation of planned NETCONF over TLS Implementations Thread-Index: AciUz2zOiZrNeYkvRCyRiBduzWnAzA== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 02 Apr 2008 14:39:59.0655 (UTC) FILETIME=[6D83BB70:01C894CF] Subject: [Netconf] Confirmation of planned NETCONF over TLS Implementations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1965491690==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1965491690== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C894CF.6D4B52BA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C894CF.6D4B52BA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, during the NETCONF WG session in IETF 71 the co-chairs asked whether anybody is going to implement the 'NETCONF=20 over TLS' draft. IWRC the result was: (Planned) Implementations of NETCONF over TLS (0 hands): No one in the audience was planning to implement. After the meeting Badra stated that he is implementing. Q: Others please speak up on the maillist if you are going=20 to implement NETCONF over TLS draft. We need 2 implementations to be able to get it to draft=20 standard status. We think that even for a proposed standard,=20 it makes no sense if only one single person is planning to=20 implement. A standards track document should be implemented=20 by many (at least 2, but preferably many more).=20 Therefor the chairs have the opinion that it does not=20 make sense to standardize the document if there is no=20 other interested party to implement.=20 So, please speak up if there is anybody implementing or planning=20 to implement. Note: If someone does not want to disclose his implementation plans to the list but wants to be counted please send a private=20 mail to the co-chairs. We will not disclose the names of people=20 who request to be counted as anonymous. PS: What we are talking about are "implementations with=20 independent code base". Thank you. Bert & Mehmet ------_=_NextPart_001_01C894CF.6D4B52BA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Confirmation of planned NETCONF over TLS Implementations

Dear = All,

during the NETCONF = WG session in IETF 71 the co-chairs
asked whether = anybody is going to implement the 'NETCONF
over TLS' = draft.

IWRC the result = was:

(Planned) = Implementations of NETCONF over TLS (0 hands):
No one in the = audience was planning to implement.

After the meeting = Badra stated that he is implementing.

Q: Others please = speak up on the maillist if you are going
to implement = NETCONF over TLS draft.

<Note of the = chairs>
We need 2 = implementations to be able to get it to draft
standard status. = We think that even for a proposed standard,
it makes no sense = if only one single person is planning to
implement. A = standards track document should be implemented
by many (at least = 2, but preferably many more).

Therefor the chairs = have the opinion that it does not
make sense to = standardize the document if there is no
other interested = party to implement.
So, please speak = up if there is anybody implementing or planning
to = implement.

Note: If someone = does not want to disclose his implementation
plans to the list = but wants to be counted please send a private
mail to the = co-chairs. We will not disclose the names of people
who request to be = counted as anonymous.

PS: What we are = talking about are "implementations with
independent code = base".

Thank = you.

Bert & = Mehmet

------_=_NextPart_001_01C894CF.6D4B52BA-- --===============1965491690== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1965491690==-- From netconf-bounces@ietf.org Wed Apr 2 07:41:16 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBF0628C568; Wed, 2 Apr 2008 07:41:16 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE58328C5C5 for ; Wed, 2 Apr 2008 07:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.128 X-Spam-Level: X-Spam-Status: No, score=-5.128 tagged_above=-999 required=5 tests=[AWL=1.470, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNX+NmhRKb0R for ; Wed, 2 Apr 2008 07:41:10 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id E002D3A6E14 for ; Wed, 2 Apr 2008 07:40:14 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m32EeEge012313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 16:40:14 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m32EeEK4021700; Wed, 2 Apr 2008 16:40:14 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 16:40:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 16:40:13 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Confirmation of plans to prepare a draft for Access Control Thread-Index: AciUz3V1vD8uq1rTRF24jF751O5rjQ== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 02 Apr 2008 14:40:14.0061 (UTC) FILETIME=[7619E9D0:01C894CF] Subject: [Netconf] Confirmation of plans to prepare a draft for Access Control X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0145622439==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0145622439== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C894CF.75D7FA4A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C894CF.75D7FA4A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, in the NETCONF WG session in IETF 71 the co-chairs=20 asked whether anybody is going to prepare an I-D for=20 Access Control. IWRC the result was: Andy Bierman and David Harrington in the session and=20 Kaushik Narayan after the session showed interest to=20 work on Access Control. =20 Please confirm your plans on preparing a draft for=20 Access Control alone or as a joint draft. Thank you. Bert & Mehmet ------_=_NextPart_001_01C894CF.75D7FA4A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Confirmation of plans to prepare a draft for Access = Control

Dear All,

in the NETCONF WG session in IETF 71 = the co-chairs
asked whether anybody is going to = prepare an I-D for
Access Control.

IWRC the result was:
Andy Bierman and David Harrington in = the session and
Kaushik Narayan after the session = showed interest to
work on Access Control.  =

Please confirm your plans on = preparing a draft for
Access Control alone or as a joint = draft.

Thank you.

Bert & Mehmet

------_=_NextPart_001_01C894CF.75D7FA4A-- --===============0145622439== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0145622439==-- From netconf-bounces@ietf.org Wed Apr 2 07:41:16 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBF0628C568; Wed, 2 Apr 2008 07:41:16 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE58328C5C5 for ; Wed, 2 Apr 2008 07:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.128 X-Spam-Level: X-Spam-Status: No, score=-5.128 tagged_above=-999 required=5 tests=[AWL=1.470, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNX+NmhRKb0R for ; Wed, 2 Apr 2008 07:41:10 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id E002D3A6E14 for ; Wed, 2 Apr 2008 07:40:14 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m32EeEge012313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 16:40:14 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m32EeEK4021700; Wed, 2 Apr 2008 16:40:14 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Apr 2008 16:40:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 16:40:13 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Confirmation of plans to prepare a draft for Access Control Thread-Index: AciUz3V1vD8uq1rTRF24jF751O5rjQ== From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 02 Apr 2008 14:40:14.0061 (UTC) FILETIME=[7619E9D0:01C894CF] Subject: [Netconf] Confirmation of plans to prepare a draft for Access Control X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0145622439==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0145622439== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C894CF.75D7FA4A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C894CF.75D7FA4A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, in the NETCONF WG session in IETF 71 the co-chairs=20 asked whether anybody is going to prepare an I-D for=20 Access Control. IWRC the result was: Andy Bierman and David Harrington in the session and=20 Kaushik Narayan after the session showed interest to=20 work on Access Control. =20 Please confirm your plans on preparing a draft for=20 Access Control alone or as a joint draft. Thank you. Bert & Mehmet ------_=_NextPart_001_01C894CF.75D7FA4A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Confirmation of plans to prepare a draft for Access = Control

Dear All,

in the NETCONF WG session in IETF 71 = the co-chairs
asked whether anybody is going to = prepare an I-D for
Access Control.

IWRC the result was:
Andy Bierman and David Harrington in = the session and
Kaushik Narayan after the session = showed interest to
work on Access Control.  =

Please confirm your plans on = preparing a draft for
Access Control alone or as a joint = draft.

Thank you.

Bert & Mehmet

------_=_NextPart_001_01C894CF.75D7FA4A-- --===============0145622439== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0145622439==-- From netconf-bounces@ietf.org Wed Apr 2 07:44:27 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D872328C55E; Wed, 2 Apr 2008 07:44:27 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A26B3A680E for ; Wed, 2 Apr 2008 07:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.476 X-Spam-Level: X-Spam-Status: No, score=-0.476 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 869tkyO04RMA for ; Wed, 2 Apr 2008 07:44:21 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 184D528C5AE for ; Wed, 2 Apr 2008 07:44:21 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id ED1FE1B81F7; Wed, 2 Apr 2008 16:44:20 +0200 (CEST) Date: Wed, 02 Apr 2008 16:47:05 +0200 (CEST) Message-Id: <20080402.164705.221919528.mbj@tail-f.com> To: mehmet.ersue@nsn.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71 and Action Items X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, "Ersue, Mehmet (NSN - DE/Muenich)" wrote: > B) Interoperability event: > > In the NETCONF session we asked whether anybody is > interested in an interoperability event for chartered > documents or on the published RFCs or both. An > additional goal would be to prepare a test report > to shift NETCONF RFCs to the draft standard status. > > There was nobody in the WG session interested in an > interoperability event. > > => If anybody is interested in an interoperability > event for chartered documents or on the > published RFCs please bring it up on the list. I don't know why I missed this one... My company is intersted in such an event. We have implementations for both the client and server side. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 2 07:44:27 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D872328C55E; Wed, 2 Apr 2008 07:44:27 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A26B3A680E for ; Wed, 2 Apr 2008 07:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.476 X-Spam-Level: X-Spam-Status: No, score=-0.476 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 869tkyO04RMA for ; Wed, 2 Apr 2008 07:44:21 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 184D528C5AE for ; Wed, 2 Apr 2008 07:44:21 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id ED1FE1B81F7; Wed, 2 Apr 2008 16:44:20 +0200 (CEST) Date: Wed, 02 Apr 2008 16:47:05 +0200 (CEST) Message-Id: <20080402.164705.221919528.mbj@tail-f.com> To: mehmet.ersue@nsn.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71 and Action Items X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, "Ersue, Mehmet (NSN - DE/Muenich)" wrote: > B) Interoperability event: > > In the NETCONF session we asked whether anybody is > interested in an interoperability event for chartered > documents or on the published RFCs or both. An > additional goal would be to prepare a test report > to shift NETCONF RFCs to the draft standard status. > > There was nobody in the WG session interested in an > interoperability event. > > => If anybody is interested in an interoperability > event for chartered documents or on the > published RFCs please bring it up on the list. I don't know why I missed this one... My company is intersted in such an event. We have implementations for both the client and server side. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 2 07:47:21 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 188FD3A6ABB; Wed, 2 Apr 2008 07:47:21 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0B43A6A57 for ; Wed, 2 Apr 2008 07:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.481 X-Spam-Level: X-Spam-Status: No, score=-0.481 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdgBtloJLbQD for ; Wed, 2 Apr 2008 07:47:14 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 2C97E28C5E2 for ; Wed, 2 Apr 2008 07:46:14 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id CEA2D1B81F7; Wed, 2 Apr 2008 16:46:14 +0200 (CEST) Date: Wed, 02 Apr 2008 16:48:59 +0200 (CEST) Message-Id: <20080402.164859.155285086.mbj@tail-f.com> To: mehmet.ersue@nsn.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of planned Notification draft Implementations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Ersue, Mehmet (NSN - DE/Muenich)" wrote: > > Dear All, > > during the NETCONF WG session in IETF 71 the co-chairs > asked whether anybody is going to implement the 'Notification' > draft. > > IWRC the result was: > > (Planned) Implementations of Notification draft (4 hands): > Martin B, Sharon (2?), Mark > > Q1) Those who showed hands in the meeting please confirm > your implementation plans. Confirm. We have implemented this draft on both the client and server side. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 2 07:47:21 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 188FD3A6ABB; Wed, 2 Apr 2008 07:47:21 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0B43A6A57 for ; Wed, 2 Apr 2008 07:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.481 X-Spam-Level: X-Spam-Status: No, score=-0.481 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdgBtloJLbQD for ; Wed, 2 Apr 2008 07:47:14 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 2C97E28C5E2 for ; Wed, 2 Apr 2008 07:46:14 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id CEA2D1B81F7; Wed, 2 Apr 2008 16:46:14 +0200 (CEST) Date: Wed, 02 Apr 2008 16:48:59 +0200 (CEST) Message-Id: <20080402.164859.155285086.mbj@tail-f.com> To: mehmet.ersue@nsn.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of planned Notification draft Implementations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Ersue, Mehmet (NSN - DE/Muenich)" wrote: > > Dear All, > > during the NETCONF WG session in IETF 71 the co-chairs > asked whether anybody is going to implement the 'Notification' > draft. > > IWRC the result was: > > (Planned) Implementations of Notification draft (4 hands): > Martin B, Sharon (2?), Mark > > Q1) Those who showed hands in the meeting please confirm > your implementation plans. Confirm. We have implemented this draft on both the client and server side. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 2 07:47:27 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B11328C5CE; Wed, 2 Apr 2008 07:47:27 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D7828C403 for ; Wed, 2 Apr 2008 07:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.483 X-Spam-Level: X-Spam-Status: No, score=-0.483 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8c8z7Ok29A0 for ; Wed, 2 Apr 2008 07:47:22 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 09E4A28C518 for ; Wed, 2 Apr 2008 07:47:01 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id A1BAF1B80C4; Wed, 2 Apr 2008 16:47:01 +0200 (CEST) Date: Wed, 02 Apr 2008 16:49:46 +0200 (CEST) Message-Id: <20080402.164946.84346225.mbj@tail-f.com> To: mehmet.ersue@nsn.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of planned NETCONF Monitoring Implementations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, "Ersue, Mehmet (NSN - DE/Muenich)" wrote: > > Dear All, > > during the NETCONF WG session in IETF 71 the co-chairs > asked whether anybody is going to implement the 'NETCONF > Monitoring' draft. > > IWRC the result was: > > (Planned) Implementations of NETCONF Monitoring (4 hands): > Martin B, Andy, Sharon, Mark > > Q1) Those who showed hands in the meeting please confirm > your implementation plans. Confirm. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 2 07:47:27 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B11328C5CE; Wed, 2 Apr 2008 07:47:27 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D7828C403 for ; Wed, 2 Apr 2008 07:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.483 X-Spam-Level: X-Spam-Status: No, score=-0.483 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8c8z7Ok29A0 for ; Wed, 2 Apr 2008 07:47:22 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 09E4A28C518 for ; Wed, 2 Apr 2008 07:47:01 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id A1BAF1B80C4; Wed, 2 Apr 2008 16:47:01 +0200 (CEST) Date: Wed, 02 Apr 2008 16:49:46 +0200 (CEST) Message-Id: <20080402.164946.84346225.mbj@tail-f.com> To: mehmet.ersue@nsn.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of planned NETCONF Monitoring Implementations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, "Ersue, Mehmet (NSN - DE/Muenich)" wrote: > > Dear All, > > during the NETCONF WG session in IETF 71 the co-chairs > asked whether anybody is going to implement the 'NETCONF > Monitoring' draft. > > IWRC the result was: > > (Planned) Implementations of NETCONF Monitoring (4 hands): > Martin B, Andy, Sharon, Mark > > Q1) Those who showed hands in the meeting please confirm > your implementation plans. Confirm. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 2 07:47:34 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58CB628C585; Wed, 2 Apr 2008 07:47:34 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79EAF28C272 for ; Wed, 2 Apr 2008 07:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.485 X-Spam-Level: X-Spam-Status: No, score=-0.485 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLqsVqYE49wL for ; Wed, 2 Apr 2008 07:47:32 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id F350328C403 for ; Wed, 2 Apr 2008 07:47:25 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 9CA971B80C4; Wed, 2 Apr 2008 16:47:26 +0200 (CEST) Date: Wed, 02 Apr 2008 16:50:11 +0200 (CEST) Message-Id: <20080402.165011.11623265.mbj@tail-f.com> To: mehmet.ersue@nsn.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of planned Partial Locking Implementations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, "Ersue, Mehmet (NSN - DE/Muenich)" wrote: > > Dear All, > > during the NETCONF WG session in IETF 71 the co-chairs > asked whether anybody is going to implement the 'Partial > Locking' draft. > > IWRC the result was: > > (Planned) Implementations of Partial Lock (3 hands): > Martin B, Balazs?, Sharon > > Q1) Those who showed hands in the meeting please confirm > your implementation plans. Confirm. We have implemented this draft on both the client and server side. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 2 07:47:34 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58CB628C585; Wed, 2 Apr 2008 07:47:34 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79EAF28C272 for ; Wed, 2 Apr 2008 07:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.485 X-Spam-Level: X-Spam-Status: No, score=-0.485 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLqsVqYE49wL for ; Wed, 2 Apr 2008 07:47:32 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id F350328C403 for ; Wed, 2 Apr 2008 07:47:25 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 9CA971B80C4; Wed, 2 Apr 2008 16:47:26 +0200 (CEST) Date: Wed, 02 Apr 2008 16:50:11 +0200 (CEST) Message-Id: <20080402.165011.11623265.mbj@tail-f.com> To: mehmet.ersue@nsn.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of planned Partial Locking Implementations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, "Ersue, Mehmet (NSN - DE/Muenich)" wrote: > > Dear All, > > during the NETCONF WG session in IETF 71 the co-chairs > asked whether anybody is going to implement the 'Partial > Locking' draft. > > IWRC the result was: > > (Planned) Implementations of Partial Lock (3 hands): > Martin B, Balazs?, Sharon > > Q1) Those who showed hands in the meeting please confirm > your implementation plans. Confirm. We have implemented this draft on both the client and server side. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 2 09:05:58 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FB833A6F4E; Wed, 2 Apr 2008 09:05:58 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FC1028C4CD for ; Wed, 2 Apr 2008 09:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.534 X-Spam-Level: X-Spam-Status: No, score=-1.534 tagged_above=-999 required=5 tests=[AWL=0.731, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vigBfouBTTWZ for ; Wed, 2 Apr 2008 09:05:56 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 45F883A6F4E for ; Wed, 2 Apr 2008 09:05:56 -0700 (PDT) Received: (qmail 43965 invoked from network); 2 Apr 2008 16:05:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.99.155 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 2 Apr 2008 16:05:55 -0000 X-YMail-OSG: 6elhNsUVM1lQGbc.tgUrroP_HSnZLIhYi.pYH8JmEnQMJ7AfTHvVZSYMCqnsPqoxNaAAoh08GB1oauTrs.boky6x X-Yahoo-Newman-Property: ymail-3 Message-ID: <47F3AEAB.6080108@andybierman.com> Date: Wed, 02 Apr 2008 09:04:59 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Muenich)" References: In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of planned NETCONF Monitoring Implementations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Ersue, Mehmet (NSN - DE/Muenich) wrote: > > Dear All, > > during the NETCONF WG session in IETF 71 the co-chairs > asked whether anybody is going to implement the 'NETCONF > Monitoring' draft. > > IWRC the result was: > > (Planned) Implementations of NETCONF Monitoring (4 hands): > Martin B, Andy, Sharon, Mark > plan to implement, but low priority. > Q1) Those who showed hands in the meeting please confirm > your implementation plans. > > Q2- Others please speak up on the maillist if you are going > to implement the 'NETCONF Monitoring' draft. > > Note: If someone does not want to disclose his implementation > plans to the list but wants to be counted please send a private > mail to the co-chairs. We will not disclose the names of people > who request to be counted as anonymous. > > PS: What we are talking about are "implementations with > independent code base". > > Thank you. > > Bert & Mehmet > Andy > > ------------------------------------------------------------------------ > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 2 09:05:58 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FB833A6F4E; Wed, 2 Apr 2008 09:05:58 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FC1028C4CD for ; Wed, 2 Apr 2008 09:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.534 X-Spam-Level: X-Spam-Status: No, score=-1.534 tagged_above=-999 required=5 tests=[AWL=0.731, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vigBfouBTTWZ for ; Wed, 2 Apr 2008 09:05:56 -0700 (PDT) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id 45F883A6F4E for ; Wed, 2 Apr 2008 09:05:56 -0700 (PDT) Received: (qmail 43965 invoked from network); 2 Apr 2008 16:05:57 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.99.155 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 2 Apr 2008 16:05:55 -0000 X-YMail-OSG: 6elhNsUVM1lQGbc.tgUrroP_HSnZLIhYi.pYH8JmEnQMJ7AfTHvVZSYMCqnsPqoxNaAAoh08GB1oauTrs.boky6x X-Yahoo-Newman-Property: ymail-3 Message-ID: <47F3AEAB.6080108@andybierman.com> Date: Wed, 02 Apr 2008 09:04:59 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Muenich)" References: In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of planned NETCONF Monitoring Implementations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Ersue, Mehmet (NSN - DE/Muenich) wrote: > > Dear All, > > during the NETCONF WG session in IETF 71 the co-chairs > asked whether anybody is going to implement the 'NETCONF > Monitoring' draft. > > IWRC the result was: > > (Planned) Implementations of NETCONF Monitoring (4 hands): > Martin B, Andy, Sharon, Mark > plan to implement, but low priority. > Q1) Those who showed hands in the meeting please confirm > your implementation plans. > > Q2- Others please speak up on the maillist if you are going > to implement the 'NETCONF Monitoring' draft. > > Note: If someone does not want to disclose his implementation > plans to the list but wants to be counted please send a private > mail to the co-chairs. We will not disclose the names of people > who request to be counted as anonymous. > > PS: What we are talking about are "implementations with > independent code base". > > Thank you. > > Bert & Mehmet > Andy > > ------------------------------------------------------------------------ > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 2 09:07:08 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15CEE28C58C; Wed, 2 Apr 2008 09:07:08 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63B3028C58C for ; Wed, 2 Apr 2008 09:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.656 X-Spam-Level: X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id offYX3HDXuax for ; Wed, 2 Apr 2008 09:07:02 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id A021228C579 for ; Wed, 2 Apr 2008 09:07:02 -0700 (PDT) Received: (qmail 66042 invoked from network); 2 Apr 2008 16:07:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.99.155 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 2 Apr 2008 16:07:02 -0000 X-YMail-OSG: HIypJ.AVM1mDiSlEWAqh.3Srt2S2XysRg_Ar.mf_LayV7BHi X-Yahoo-Newman-Property: ymail-3 Message-ID: <47F3AEEE.2040403@andybierman.com> Date: Wed, 02 Apr 2008 09:06:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Muenich)" References: In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of plans to prepare a draft for Access Control X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Ersue, Mehmet (NSN - DE/Muenich) wrote: > > Dear All, > > in the NETCONF WG session in IETF 71 the co-chairs > asked whether anybody is going to prepare an I-D for > Access Control. > > IWRC the result was: > Andy Bierman and David Harrington in the session and > Kaushik Narayan after the session showed interest to > work on Access Control. > > Please confirm your plans on preparing a draft for > Access Control alone or as a joint draft. > no plans at all to write a draft > Thank you. > > Bert & Mehmet > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 2 09:07:08 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15CEE28C58C; Wed, 2 Apr 2008 09:07:08 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63B3028C58C for ; Wed, 2 Apr 2008 09:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.656 X-Spam-Level: X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id offYX3HDXuax for ; Wed, 2 Apr 2008 09:07:02 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id A021228C579 for ; Wed, 2 Apr 2008 09:07:02 -0700 (PDT) Received: (qmail 66042 invoked from network); 2 Apr 2008 16:07:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.99.155 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 2 Apr 2008 16:07:02 -0000 X-YMail-OSG: HIypJ.AVM1mDiSlEWAqh.3Srt2S2XysRg_Ar.mf_LayV7BHi X-Yahoo-Newman-Property: ymail-3 Message-ID: <47F3AEEE.2040403@andybierman.com> Date: Wed, 02 Apr 2008 09:06:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Muenich)" References: In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of plans to prepare a draft for Access Control X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Ersue, Mehmet (NSN - DE/Muenich) wrote: > > Dear All, > > in the NETCONF WG session in IETF 71 the co-chairs > asked whether anybody is going to prepare an I-D for > Access Control. > > IWRC the result was: > Andy Bierman and David Harrington in the session and > Kaushik Narayan after the session showed interest to > work on Access Control. > > Please confirm your plans on preparing a draft for > Access Control alone or as a joint draft. > no plans at all to write a draft > Thank you. > > Bert & Mehmet > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 2 10:12:18 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9621C28C232; Wed, 2 Apr 2008 10:12:18 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 663A43A68A3 for ; Wed, 2 Apr 2008 10:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUo2xFIkF5aQ for ; Wed, 2 Apr 2008 10:12:16 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 3FE7E3A69FC for ; Wed, 2 Apr 2008 10:12:16 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m32HCDv10910; Wed, 2 Apr 2008 17:12:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 13:12:10 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B413D9B8F8@zcarhxm2.corp.nortel.com> In-Reply-To: <47F3AEEE.2040403@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Confirmation of plans to prepare a draft for Access Control Thread-Index: AciU27EaVhDdt+RLSHuWn+UJL7ancAACNU9g References: <47F3AEEE.2040403@andybierman.com> From: "Sharon Chisholm" To: "Andy Bierman" , "Ersue, Mehmet (NSN - DE/Muenich)" Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of plans to prepare a draft for Access Control X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi I though we agreed to defer this issue another meeting cycle? Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Wednesday, April 02, 2008 12:06 PM To: Ersue, Mehmet (NSN - DE/Muenich) Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of plans to prepare a draft for Access Control Ersue, Mehmet (NSN - DE/Muenich) wrote: > > Dear All, > > in the NETCONF WG session in IETF 71 the co-chairs asked whether > anybody is going to prepare an I-D for Access Control. > > IWRC the result was: > Andy Bierman and David Harrington in the session and Kaushik Narayan > after the session showed interest to work on Access Control. > > Please confirm your plans on preparing a draft for Access Control > alone or as a joint draft. > no plans at all to write a draft > Thank you. > > Bert & Mehmet > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 2 10:12:18 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9621C28C232; Wed, 2 Apr 2008 10:12:18 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 663A43A68A3 for ; Wed, 2 Apr 2008 10:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUo2xFIkF5aQ for ; Wed, 2 Apr 2008 10:12:16 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 3FE7E3A69FC for ; Wed, 2 Apr 2008 10:12:16 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m32HCDv10910; Wed, 2 Apr 2008 17:12:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 13:12:10 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B413D9B8F8@zcarhxm2.corp.nortel.com> In-Reply-To: <47F3AEEE.2040403@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Confirmation of plans to prepare a draft for Access Control Thread-Index: AciU27EaVhDdt+RLSHuWn+UJL7ancAACNU9g References: <47F3AEEE.2040403@andybierman.com> From: "Sharon Chisholm" To: "Andy Bierman" , "Ersue, Mehmet (NSN - DE/Muenich)" Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of plans to prepare a draft for Access Control X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi I though we agreed to defer this issue another meeting cycle? Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Wednesday, April 02, 2008 12:06 PM To: Ersue, Mehmet (NSN - DE/Muenich) Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of plans to prepare a draft for Access Control Ersue, Mehmet (NSN - DE/Muenich) wrote: > > Dear All, > > in the NETCONF WG session in IETF 71 the co-chairs asked whether > anybody is going to prepare an I-D for Access Control. > > IWRC the result was: > Andy Bierman and David Harrington in the session and Kaushik Narayan > after the session showed interest to work on Access Control. > > Please confirm your plans on preparing a draft for Access Control > alone or as a joint draft. > no plans at all to write a draft > Thank you. > > Bert & Mehmet > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 2 10:12:29 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE22F3A6EDD; Wed, 2 Apr 2008 10:12:29 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CD183A6CA9 for ; Wed, 2 Apr 2008 10:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVbhK3MbZdOp for ; Wed, 2 Apr 2008 10:12:28 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 133063A6C95 for ; Wed, 2 Apr 2008 10:12:27 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m32HCQv10976 for ; Wed, 2 Apr 2008 17:12:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 13:12:18 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B413D9B8FA@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Netconf Notification: Issues 8 & 18: DateTime Thread-Index: AciU3gs/yFQkNkosTfyQmVudbJ3+6wAAKJxwAAFv+FA= From: "Sharon Chisholm" To: Subject: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi This is one of the discuss topics on the notification draft. This will potentially result in two changes - Additional reference (to point to specifications that indicate how dateTime provides sufficient precision) - Adding a statement, if the working group agrees, that makes supporting time zone mandatory. Sharon -----Original Message----- From: Chisholm, Sharon (CAR:ZZ00) Sent: Wednesday, April 02, 2008 12:25 PM To: 'Chris Newman'; 'dward@cisco.com' Cc: 'Hector Trevino (htrevino)'; 'Bert Wijnen - IETF'; 'Ersue, Mehmet (NSN - DE/Muenich)'; 'Dan Romascanu' Subject: Netconf Notification: Issues 8 & 18: DateTime Please reply to this email either indicating that you consider this issue resolved or by providing additional feedback as to why the response is not sufficient. 18. Discuss: dateTime (David Ward) [2008-03-26] ** All of the time references are in "type dateTime" which is XMLschema speak is "YYYY-MM-DDThh:mm:ss" (although there is no reference). Given the output of config events from networking nodes can happen at an incredible rate, why is it felt that seconds are a satisfactory granularity? Most vendors are in fact already implementing event down to the ms. This is critical for fault messages. It is impossible to understand what is happening on a network node with the granularity of seconds. 8. dateTime (Chris Newman) The dateTime XML schema data type makes the timezone optional, in which case time stamps are ambiguous and non-interoperable. This document needs to explicitly require that timezones be present in order to interoperate. I observe that dateTime does permit arbitrary fractions of a second so I do not agree with Dave Ward's DISCUSS on the accuracy issue, however he's right that a normative reference to XML schema data types is necessary to clarify this and should be referenced when the "dateTime" data type is first mentioned. RFC 3339 discusses these issues in more detail. There is no restriction as to the number of decimal digits. We'll add a reference to XML XL documentation and to RFC 3339. FROM ISO 8601 If necessary for a particular application a decimal fraction of hour, minute or second may be included. If a decimal fraction is included, lower order time elements (if any) shall be omitted and the decimal fraction shall be divided from the integer part by the decimal sign specified in ISO 31-0, i.e. the comma [,] or full stop [.]. Of these, the comma is the preferred sign. If the magnitude of the number is less than unity, the decimal sign shall be preceded by two zeros in accordance with 3.6. The interchange parties, dependent upon the application, shall agree the number of digits in the decimal fraction. The format shall be [hhmmss,ss], [hhmm,mm] or [hh,hh] as appropriate (hour minute second, hour minute, and hour, respectively), with as many digits as necessary following the decimal sign. A decimal fraction shall have at least one digit. In the examples below it has been agreed to give the smallest time element a decimal fraction with one digit. As for the timezone issue, I know in the past we have discussed whether or not you could mandate use of timezones. At the time it was felt there were machines that would be unable to support this feature. Keep in mind that this solution needs to work on smaller, lower-end boxes as well as fancy ones. Adding text mandating use of timezones would need to be approved by the working group. Assuming the working group agrees, I have no problem adding this text. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 2 10:12:29 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE22F3A6EDD; Wed, 2 Apr 2008 10:12:29 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CD183A6CA9 for ; Wed, 2 Apr 2008 10:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVbhK3MbZdOp for ; Wed, 2 Apr 2008 10:12:28 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 133063A6C95 for ; Wed, 2 Apr 2008 10:12:27 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m32HCQv10976 for ; Wed, 2 Apr 2008 17:12:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 13:12:18 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B413D9B8FA@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Netconf Notification: Issues 8 & 18: DateTime Thread-Index: AciU3gs/yFQkNkosTfyQmVudbJ3+6wAAKJxwAAFv+FA= From: "Sharon Chisholm" To: Subject: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi This is one of the discuss topics on the notification draft. This will potentially result in two changes - Additional reference (to point to specifications that indicate how dateTime provides sufficient precision) - Adding a statement, if the working group agrees, that makes supporting time zone mandatory. Sharon -----Original Message----- From: Chisholm, Sharon (CAR:ZZ00) Sent: Wednesday, April 02, 2008 12:25 PM To: 'Chris Newman'; 'dward@cisco.com' Cc: 'Hector Trevino (htrevino)'; 'Bert Wijnen - IETF'; 'Ersue, Mehmet (NSN - DE/Muenich)'; 'Dan Romascanu' Subject: Netconf Notification: Issues 8 & 18: DateTime Please reply to this email either indicating that you consider this issue resolved or by providing additional feedback as to why the response is not sufficient. 18. Discuss: dateTime (David Ward) [2008-03-26] ** All of the time references are in "type dateTime" which is XMLschema speak is "YYYY-MM-DDThh:mm:ss" (although there is no reference). Given the output of config events from networking nodes can happen at an incredible rate, why is it felt that seconds are a satisfactory granularity? Most vendors are in fact already implementing event down to the ms. This is critical for fault messages. It is impossible to understand what is happening on a network node with the granularity of seconds. 8. dateTime (Chris Newman) The dateTime XML schema data type makes the timezone optional, in which case time stamps are ambiguous and non-interoperable. This document needs to explicitly require that timezones be present in order to interoperate. I observe that dateTime does permit arbitrary fractions of a second so I do not agree with Dave Ward's DISCUSS on the accuracy issue, however he's right that a normative reference to XML schema data types is necessary to clarify this and should be referenced when the "dateTime" data type is first mentioned. RFC 3339 discusses these issues in more detail. There is no restriction as to the number of decimal digits. We'll add a reference to XML XL documentation and to RFC 3339. FROM ISO 8601 If necessary for a particular application a decimal fraction of hour, minute or second may be included. If a decimal fraction is included, lower order time elements (if any) shall be omitted and the decimal fraction shall be divided from the integer part by the decimal sign specified in ISO 31-0, i.e. the comma [,] or full stop [.]. Of these, the comma is the preferred sign. If the magnitude of the number is less than unity, the decimal sign shall be preceded by two zeros in accordance with 3.6. The interchange parties, dependent upon the application, shall agree the number of digits in the decimal fraction. The format shall be [hhmmss,ss], [hhmm,mm] or [hh,hh] as appropriate (hour minute second, hour minute, and hour, respectively), with as many digits as necessary following the decimal sign. A decimal fraction shall have at least one digit. In the examples below it has been agreed to give the smallest time element a decimal fraction with one digit. As for the timezone issue, I know in the past we have discussed whether or not you could mandate use of timezones. At the time it was felt there were machines that would be unable to support this feature. Keep in mind that this solution needs to work on smaller, lower-end boxes as well as fancy ones. Adding text mandating use of timezones would need to be approved by the working group. Assuming the working group agrees, I have no problem adding this text. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 2 10:23:09 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31BD928C32D; Wed, 2 Apr 2008 10:23:09 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53FAB3A6EB6 for ; Wed, 2 Apr 2008 10:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhOCT-pXiRDM for ; Wed, 2 Apr 2008 10:22:55 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id C122828C59E for ; Wed, 2 Apr 2008 10:21:00 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m32HKwd13977; Wed, 2 Apr 2008 17:20:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 13:20:35 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B413D9B938@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Confirmation of plans to prepare drafts for Netconf Content Thread-Index: AciUz4OZChtVkjPkTtCsDyjWHV2VbAAFg75w References: From: "Sharon Chisholm" To: "Ersue, Mehmet (NSN - DE/Muenich)" , Subject: Re: [Netconf] Confirmation of plans to prepare drafts for Netconf Content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0266668586==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0266668586== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C894E5.DD59766D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C894E5.DD59766D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi =20 Actually, I believe there was a lot of interest in Notification content expressed in the meeting, which doesn't appear on your list. I need to confirm the commitment, but I do expect someone from my organization to work on that and/or the interface configuration content. =20 Sharon ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Wednesday, April 02, 2008 10:41 AM To: netconf@ietf.org Subject: [Netconf] Confirmation of plans to prepare drafts for Netconf Content Dear All,=20 in the NETCONF WG session in IETF 71 a few=20 attendees showed interest to prepare I-D's for=20 NETCONF Content for CONFIGURATION (and/or=20 NETCONF related) events and also NETCONF=20 Content for SNMP or SYSLOG notifications.=20 Please confirm your plans on preparing I-Ds for=20 Netconf content on the maillist.=20 Thank you.=20 Bert & Mehmet=20 ------_=_NextPart_001_01C894E5.DD59766D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Confirmation of plans to prepare drafts for Netconf = Content
hi
 
Actually, I believe there was a lot of interest = in=20 Notification content expressed in the meeting, which doesn't appear on = your=20 list. I need to confirm the commitment, but I do expect someone from my=20 organization to work on that and/or the interface configuration=20 content.
 
Sharon

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN = -=20 DE/Muenich)
Sent: Wednesday, April 02, 2008 10:41 = AM
To:=20 netconf@ietf.org
Subject: [Netconf] Confirmation of plans to = prepare=20 drafts for Netconf Content


Dear All, =

in the NETCONF WG = session in IETF 71=20 a few
attendees showed=20 interest to prepare I-D's for
NETCONF Content for CONFIGURATION (and/or =
NETCONF related) events and also = NETCONF=20
Content = for SNMP or=20 SYSLOG notifications.

Please confirm your = plans on=20 preparing I-Ds for
Netconf content on the maillist.

Thank = you.

Bert & = Mehmet=20

------_=_NextPart_001_01C894E5.DD59766D-- --===============0266668586== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0266668586==-- From netconf-bounces@ietf.org Wed Apr 2 10:23:09 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31BD928C32D; Wed, 2 Apr 2008 10:23:09 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53FAB3A6EB6 for ; Wed, 2 Apr 2008 10:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhOCT-pXiRDM for ; Wed, 2 Apr 2008 10:22:55 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id C122828C59E for ; Wed, 2 Apr 2008 10:21:00 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m32HKwd13977; Wed, 2 Apr 2008 17:20:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 13:20:35 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B413D9B938@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Confirmation of plans to prepare drafts for Netconf Content Thread-Index: AciUz4OZChtVkjPkTtCsDyjWHV2VbAAFg75w References: From: "Sharon Chisholm" To: "Ersue, Mehmet (NSN - DE/Muenich)" , Subject: Re: [Netconf] Confirmation of plans to prepare drafts for Netconf Content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0266668586==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0266668586== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C894E5.DD59766D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C894E5.DD59766D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi =20 Actually, I believe there was a lot of interest in Notification content expressed in the meeting, which doesn't appear on your list. I need to confirm the commitment, but I do expect someone from my organization to work on that and/or the interface configuration content. =20 Sharon ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Wednesday, April 02, 2008 10:41 AM To: netconf@ietf.org Subject: [Netconf] Confirmation of plans to prepare drafts for Netconf Content Dear All,=20 in the NETCONF WG session in IETF 71 a few=20 attendees showed interest to prepare I-D's for=20 NETCONF Content for CONFIGURATION (and/or=20 NETCONF related) events and also NETCONF=20 Content for SNMP or SYSLOG notifications.=20 Please confirm your plans on preparing I-Ds for=20 Netconf content on the maillist.=20 Thank you.=20 Bert & Mehmet=20 ------_=_NextPart_001_01C894E5.DD59766D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Confirmation of plans to prepare drafts for Netconf = Content
hi
 
Actually, I believe there was a lot of interest = in=20 Notification content expressed in the meeting, which doesn't appear on = your=20 list. I need to confirm the commitment, but I do expect someone from my=20 organization to work on that and/or the interface configuration=20 content.
 
Sharon

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN = -=20 DE/Muenich)
Sent: Wednesday, April 02, 2008 10:41 = AM
To:=20 netconf@ietf.org
Subject: [Netconf] Confirmation of plans to = prepare=20 drafts for Netconf Content


Dear All, =

in the NETCONF WG = session in IETF 71=20 a few
attendees showed=20 interest to prepare I-D's for
NETCONF Content for CONFIGURATION (and/or =
NETCONF related) events and also = NETCONF=20
Content = for SNMP or=20 SYSLOG notifications.

Please confirm your = plans on=20 preparing I-Ds for
Netconf content on the maillist.

Thank = you.

Bert & = Mehmet=20

------_=_NextPart_001_01C894E5.DD59766D-- --===============0266668586== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0266668586==-- From netconf-bounces@ietf.org Wed Apr 2 10:37:08 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CED43A6A8A; Wed, 2 Apr 2008 10:37:08 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33C723A6966 for ; Wed, 2 Apr 2008 10:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amLJ733cWQZH for ; Wed, 2 Apr 2008 10:37:03 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 84B4C3A680D for ; Wed, 2 Apr 2008 10:37:03 -0700 (PDT) Received: (qmail 89865 invoked from network); 2 Apr 2008 17:37:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.99.155 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 2 Apr 2008 17:37:03 -0000 X-YMail-OSG: xRyh2NgVM1m9cy0JxpmvZbNhjcWS9Dq2yM8w8Qb8nYVU2s3Gs7393x5MqyTCw9fAXCJSsr7HlaPNzav_M7ovdkQ2 X-Yahoo-Newman-Property: ymail-3 Message-ID: <47F3C3F9.6020204@andybierman.com> Date: Wed, 02 Apr 2008 10:35:53 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Sharon Chisholm References: <47F3AEEE.2040403@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B413D9B8F8@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B413D9B8F8@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of plans to prepare a draft for Access Control X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > > I though we agreed to defer this issue another meeting cycle? > So did I. IMO it would be more productive to proceed with NETMOD, and just not make any stupid mistakes that will impact the ability to add access control later. I wouldn't know what to write in a new access control draft, that would be much different than what has been written in the 4 or 5 proposals published so far. > Sharon Andy > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Andy Bierman > Sent: Wednesday, April 02, 2008 12:06 PM > To: Ersue, Mehmet (NSN - DE/Muenich) > Cc: netconf@ietf.org > Subject: Re: [Netconf] Confirmation of plans to prepare a draft for > Access Control > > Ersue, Mehmet (NSN - DE/Muenich) wrote: >> Dear All, >> >> in the NETCONF WG session in IETF 71 the co-chairs asked whether >> anybody is going to prepare an I-D for Access Control. >> >> IWRC the result was: >> Andy Bierman and David Harrington in the session and Kaushik Narayan >> after the session showed interest to work on Access Control. >> >> Please confirm your plans on preparing a draft for Access Control >> alone or as a joint draft. >> > > no plans at all to write a draft > >> Thank you. >> >> Bert & Mehmet >> > > Andy > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 2 10:37:08 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CED43A6A8A; Wed, 2 Apr 2008 10:37:08 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33C723A6966 for ; Wed, 2 Apr 2008 10:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amLJ733cWQZH for ; Wed, 2 Apr 2008 10:37:03 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 84B4C3A680D for ; Wed, 2 Apr 2008 10:37:03 -0700 (PDT) Received: (qmail 89865 invoked from network); 2 Apr 2008 17:37:04 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.99.155 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 2 Apr 2008 17:37:03 -0000 X-YMail-OSG: xRyh2NgVM1m9cy0JxpmvZbNhjcWS9Dq2yM8w8Qb8nYVU2s3Gs7393x5MqyTCw9fAXCJSsr7HlaPNzav_M7ovdkQ2 X-Yahoo-Newman-Property: ymail-3 Message-ID: <47F3C3F9.6020204@andybierman.com> Date: Wed, 02 Apr 2008 10:35:53 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Sharon Chisholm References: <47F3AEEE.2040403@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B413D9B8F8@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B413D9B8F8@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of plans to prepare a draft for Access Control X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > > I though we agreed to defer this issue another meeting cycle? > So did I. IMO it would be more productive to proceed with NETMOD, and just not make any stupid mistakes that will impact the ability to add access control later. I wouldn't know what to write in a new access control draft, that would be much different than what has been written in the 4 or 5 proposals published so far. > Sharon Andy > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Andy Bierman > Sent: Wednesday, April 02, 2008 12:06 PM > To: Ersue, Mehmet (NSN - DE/Muenich) > Cc: netconf@ietf.org > Subject: Re: [Netconf] Confirmation of plans to prepare a draft for > Access Control > > Ersue, Mehmet (NSN - DE/Muenich) wrote: >> Dear All, >> >> in the NETCONF WG session in IETF 71 the co-chairs asked whether >> anybody is going to prepare an I-D for Access Control. >> >> IWRC the result was: >> Andy Bierman and David Harrington in the session and Kaushik Narayan >> after the session showed interest to work on Access Control. >> >> Please confirm your plans on preparing a draft for Access Control >> alone or as a joint draft. >> > > no plans at all to write a draft > >> Thank you. >> >> Bert & Mehmet >> > > Andy > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 2 17:01:50 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C93CE28C4B0; Wed, 2 Apr 2008 17:01:50 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3114F28C400 for ; Wed, 2 Apr 2008 17:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sK5jhp8vfb-v for ; Wed, 2 Apr 2008 17:01:48 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id BA0EA28C3FC for ; Wed, 2 Apr 2008 17:01:47 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m330wZHY442590; Thu, 3 Apr 2008 01:58:35 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Thu, 3 Apr 2008 01:59:38 +0200 (CEST) Message-ID: <64721.88.164.98.77.1207180778.squirrel@www.isima.fr> In-Reply-To: <55123.88.164.98.77.1207161062.squirrel@www.isima.fr> References: <55123.88.164.98.77.1207161062.squirrel@www.isima.fr> Date: Thu, 3 Apr 2008 01:59:38 +0200 (CEST) From: badra@isima.fr To: mehmet.ersue@nsn.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Thu, 03 Apr 2008 01:58:35 +0100 (WEST) Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of planned NETCONF over TLS Implementations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear Mehmet, Bert and all, I confirm that I am working on the implementation. I hope that people are interested with a second implementation. Best regards, Badra P.S. If you have a TLS client/server implementation, then you can run NETCONF over TLS with a simple configuration to do a mutual authentication using certificates: 1-disable the ciphersuites that don't provide mutual authentition using certificates or PSK. 2- force the server to request a client certificate and stop the negotiation if no certificate is sent by the client. OpenSSL case: ------------- In OpenSSL case, this configuration is as follow: a) in ssl.h, located in openssl0-9-8g/ssl, line 320 Replace: #define SSL_DEFAULT_CIPHER_LIST "AES:ALL:NULL:!eNULL:+RC4:@STRENGTH" With: #define SSL_DEFAULT_CIPHER_LIST "AES:ALL:!ADH:!KRB5:!aKRB5:!kKRB5:!aNULL:!eNULL:+RC4:@STRENGTH" This will disable NULL, Anonymous DH and Kerberos key exchange algorithms. b) in s3_serv.c, located in openssl0-9-8g/ssl, line 364: set the server to the state SSL_VERIFY_PEER, which force the server to stop the TLS session if no certificate is sent by the client Replace the following: s->state=SSL3_ST_SW_CERT_REQ_A; s->init_num=0; break; case SSL3_ST_SW_CERT_REQ_A: case SSL3_ST_SW_CERT_REQ_B: if (/* don't request cert unless asked for it: */ !(s->verify_mode & SSL_VERIFY_PFrom netconf-bounces@ietf.org Wed Apr 2 17:01:50 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C93CE28C4B0; Wed, 2 Apr 2008 17:01:50 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3114F28C400 for ; Wed, 2 Apr 2008 17:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sK5jhp8vfb-v for ; Wed, 2 Apr 2008 17:01:48 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id BA0EA28C3FC for ; Wed, 2 Apr 2008 17:01:47 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m330wZHY442590; Thu, 3 Apr 2008 01:58:35 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Thu, 3 Apr 2008 01:59:38 +0200 (CEST) Message-ID: <64721.88.164.98.77.1207180778.squirrel@www.isima.fr> In-Reply-To: <55123.88.164.98.77.1207161062.squirrel@www.isima.fr> References: <55123.88.164.98.77.1207161062.squirrel@www.isima.fr> Date: Thu, 3 Apr 2008 01:59:38 +0200 (CEST) From: badra@isima.fr To: mehmet.ersue@nsn.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Thu, 03 Apr 2008 01:58:35 +0100 (WEST) Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of planned NETCONF over TLS Implementations X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear Mehmet, Bert and all, I confirm that I am working on the implementation. I hope that people are interested with a second implementation. Best regards, Badra P.S. If you have a TLS client/server implementation, then you can run NETCONF over TLS with a simple configuration to do a mutual authentication using certificates: 1-disable the ciphersuites that don't provide mutual authentition using certificates or PSK. 2- force the server to request a client certificate and stop the negotiation if no certificate is sent by the client. OpenSSL case: ------------- In OpenSSL case, this configuration is as follow: a) in ssl.h, located in openssl0-9-8g/ssl, line 320 Replace: #define SSL_DEFAULT_CIPHER_LIST "AES:ALL:NULL:!eNULL:+RC4:@STRENGTH" With: #define SSL_DEFAULT_CIPHER_LIST "AES:ALL:!ADH:!KRB5:!aKRB5:!kKRB5:!aNULL:!eNULL:+RC4:@STRENGTH" This will disable NULL, Anonymous DH and Kerberos key exchange algorithms. b) in s3_serv.c, located in openssl0-9-8g/ssl, line 364: set the server to the state SSL_VERIFY_PEER, which force the server to stop the TLS session if no certificate is sent by the client Replace the following: s->state=SSL3_ST_SW_CERT_REQ_A; s->init_num=0; break; case SSL3_ST_SW_CERT_REQ_A: case SSL3_ST_SW_CERT_REQ_B: if (/* don't request cert unless asked for it: */ !(s->verify_mode & SSL_VEEER) || /* if SSL_VERIFY_CLIENT_ONCE is set, * don't request cert during re-negotiation: */ ((s->session->peer != NULL) && (s->verify_mode & SSL_VERIFY_CLIENT_ONCE)) || /* never request cert in anonymous ciphersuites * (see section "Certificate request" in SSL 3 drafts * and in RFC 2246): */ ((s->s3->tmp.new_cipher->algorithms & SSL_aNULL) && /* ... except when the application insists on verification * (against the specs, but s3_clnt.c accepts this for SSL 3) */ !(s->verify_mode & SSL_VERIFY_FAIL_IF_NO_PEER_CERT)) || /* never request cert in Kerberos ciphersuites */ (s->s3->tmp.new_cipher->algorithms & SSL_aKRB5)) { /* no cert request */ skip=1; s->s3->tmp.cert_request=0; s->state=SSL3_ST_SW_SRVR_DONE_A; } With: /*set the server to SSL_VERIFY_PEER*/ s->verify_mode = SSL_VERIFY_PEER; s->state=SSL3_ST_SW_CERT_REQ_A; s->init_num=0; break; case SSL3_ST_SW_CERT_REQ_A: case SSL3_ST_SW_CERT_REQ_B: if (/* don't request cert unless asked for it: */ !(s->verify_mode & SSL_VERIFY_PEER) || /* if SSL_VERIFY_CLIENT_ONCE is set, * don't request cert during re-negotiation: */ ((s->session->peer != NULL) && (s->verify_mode & SSL_VERIFY_CLIENT_ONCE)))// || { /* no cert request */ skip=1; s->s3->tmp.cert_request=0; s->state=SSL3_ST_SW_SRVR_DONE_A; } >> Dear All, >> >> during the NETCONF WG session in IETF 71 the co-chairs >> asked whether anybody is going to implement the 'NETCONF >> over TLS' draft. >> >> IWRC the result was: >> >> (Planned) Implementations of NETCONF over TLS (0 hands): >> No one in the audience was planning to implement. >> >> After the meeting Badra stated that he is implementing. >> >> Q: Others please speak up on the maillist if you are going >> to implement NETCONF over TLS draft. >> >> >> We need 2 implementations to be able to get it to draft >> standard status. We think that even for a proposed standard, >> it makes no sense if only one single person is planning to >> implement. A standards track document should be implemented >> by many (at least 2, but preferably many more). >> >> Therefor the chairs have the opinion that it does not >> make sense to standardize the document if there is no >> other interested party to implement. >> So, please speak up if there is anybody implementing or planning >> to implement. >> >> Note: If someone does not want to disclose his implementation >> plans to the list but wants to be counted please send a private >> mail to the co-chairs. We will not disclose the names of people >> who request to be counted as anonymous. >> >> PS: What we are talking about are "implementations with >> independent code base". >> >> Thank you. >> >> Bert & Mehmet >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf RIFY_PEER) || /* if SSL_VERIFY_CLIENT_ONCE is set, * don't request cert during re-negotiation: */ ((s->session->peer != NULL) && (s->verify_mode & SSL_VERIFY_CLIENT_ONCE)) || /* never request cert in anonymous ciphersuites * (see section "Certificate request" in SSL 3 drafts * and in RFC 2246): */ ((s->s3->tmp.new_cipher->algorithms & SSL_aNULL) && /* ... except when the application insists on verification * (against the specs, but s3_clnt.c accepts this for SSL 3) */ !(s->verify_mode & SSL_VERIFY_FAIL_IF_NO_PEER_CERT)) || /* never request cert in Kerberos ciphersuites */ (s->s3->tmp.new_cipher->algorithms & SSL_aKRB5)) { /* no cert request */ skip=1; s->s3->tmp.cert_request=0; s->state=SSL3_ST_SW_SRVR_DONE_A; } With: /*set the server to SSL_VERIFY_PEER*/ s->verify_mode = SSL_VERIFY_PEER; s->state=SSL3_ST_SW_CERT_REQ_A; s->init_num=0; break; case SSL3_ST_SW_CERT_REQ_A: case SSL3_ST_SW_CERT_REQ_B: if (/* don't request cert unless asked for it: */ !(s->verify_mode & SSL_VERIFY_PEER) || /* if SSL_VERIFY_CLIENT_ONCE is set, * don't request cert during re-negotiation: */ ((s->session->peer != NULL) && (s->verify_mode & SSL_VERIFY_CLIENT_ONCE)))// || { /* no cert request */ skip=1; s->s3->tmp.cert_request=0; s->state=SSL3_ST_SW_SRVR_DONE_A; } >> Dear All, >> >> during the NETCONF WG session in IETF 71 the co-chairs >> asked whether anybody is going to implement the 'NETCONF >> over TLS' draft. >> >> IWRC the result was: >> >> (Planned) Implementations of NETCONF over TLS (0 hands): >> No one in the audience was planning to implement. >> >> After the meeting Badra stated that he is implementing. >> >> Q: Others please speak up on the maillist if you are going >> to implement NETCONF over TLS draft. >> >> >> We need 2 implementations to be able to get it to draft >> standard status. We think that even for a proposed standard, >> it makes no sense if only one single person is planning to >> implement. A standards track document should be implemented >> by many (at least 2, but preferably many more). >> >> Therefor the chairs have the opinion that it does not >> make sense to standardize the document if there is no >> other interested party to implement. >> So, please speak up if there is anybody implementing or planning >> to implement. >> >> Note: If someone does not want to disclose his implementation >> plans to the list but wants to be counted please send a private >> mail to the co-chairs. We will not disclose the names of people >> who request to be counted as anonymous. >> >> PS: What we are talking about are "implementations with >> independent code base". >> >> Thank you. >> >> Bert & Mehmet >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Apr 3 09:44:25 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5AF43A6B48; Thu, 3 Apr 2008 09:44:25 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1FBA28C2EF for ; Thu, 3 Apr 2008 09:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o00VHMseqxtD for ; Thu, 3 Apr 2008 09:44:21 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 90C123A6B40 for ; Thu, 3 Apr 2008 09:44:20 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m33GiLn02573 for ; Thu, 3 Apr 2008 16:44:21 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 12:44:05 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B413DE75AB@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on NETCONF Monitoring Draft Thread-Index: AciVqe32Eg/3e8mTTSChNeunTtJVag== From: "Sharon Chisholm" To: Subject: [Netconf] Comments on NETCONF Monitoring Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi In looking at http://www.ietf.org/internet-drafts/draft-ietf-netconf-monitoring-01.txt I think we should delete The named profile associated with this subscription. Note that the contents of the named profile may have changed since it was last applied. Since this concept is no longer part of the notification draft Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Apr 3 09:44:25 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5AF43A6B48; Thu, 3 Apr 2008 09:44:25 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1FBA28C2EF for ; Thu, 3 Apr 2008 09:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o00VHMseqxtD for ; Thu, 3 Apr 2008 09:44:21 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 90C123A6B40 for ; Thu, 3 Apr 2008 09:44:20 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m33GiLn02573 for ; Thu, 3 Apr 2008 16:44:21 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 12:44:05 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B413DE75AB@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on NETCONF Monitoring Draft Thread-Index: AciVqe32Eg/3e8mTTSChNeunTtJVag== From: "Sharon Chisholm" To: Subject: [Netconf] Comments on NETCONF Monitoring Draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi In looking at http://www.ietf.org/internet-drafts/draft-ietf-netconf-monitoring-01.txt I think we should delete The named profile associated with this subscription. Note that the contents of the named profile may have changed since it was last applied. Since this concept is no longer part of the notification draft Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 4 05:46:29 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065B33A6D61; Fri, 4 Apr 2008 05:46:29 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2F3A3A6D67 for ; Fri, 4 Apr 2008 05:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[AWL=-0.653, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uNsoWbeIFRW for ; Fri, 4 Apr 2008 05:46:27 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 919833A6D61 for ; Fri, 4 Apr 2008 05:46:26 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m34CkU6E023531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Apr 2008 14:46:30 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m34CkHWL012576; Fri, 4 Apr 2008 14:46:26 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 14:46:21 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Date: Fri, 4 Apr 2008 14:46:20 +0200 Message-ID: In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B413D9B938@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Confirmation of plans to prepare drafts for Notification Content WAS: RE: [Netconf] Confirmation of plans to prepare drafts for Netconf Content Thread-Index: AciUz4OZChtVkjPkTtCsDyjWHV2VbAAFg75wAFrACpA= References: <713043CE8B8E1348AF3C546DBE02C1B413D9B938@zcarhxm2.corp.nortel.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext Sharon Chisholm" , X-OriginalArrivalTime: 04 Apr 2008 12:46:21.0907 (UTC) FILETIME=[E2A57230:01C89651] Subject: [Netconf] Confirmation of plans to prepare drafts for Notification Content WAS: RE: Confirmation of plans to prepare drafts for Netconf Content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1658022585==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1658022585== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89651.E27480E1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89651.E27480E1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sharon, All, =20 this is true, we talked on Notification content and=20 there was interest to do it. =20 Please let us know if anybody is planning to prepare a draft. Cheers, MehmetFrom netconf-bounces@ietf.org Fri Apr 4 05:46:29 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065B33A6D61; Fri, 4 Apr 2008 05:46:29 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2F3A3A6D67 for ; Fri, 4 Apr 2008 05:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[AWL=-0.653, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uNsoWbeIFRW for ; Fri, 4 Apr 2008 05:46:27 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 919833A6D61 for ; Fri, 4 Apr 2008 05:46:26 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m34CkU6E023531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Apr 2008 14:46:30 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m34CkHWL012576; Fri, 4 Apr 2008 14:46:26 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 14:46:21 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Date: Fri, 4 Apr 2008 14:46:20 +0200 Message-ID: In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B413D9B938@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Confirmation of plans to prepare drafts for Notification Content WAS: RE: [Netconf] Confirmation of plans to prepare drafts for Netconf Content Thread-Index: AciUz4OZChtVkjPkTtCsDyjWHV2VbAAFg75wAFrACpA= References: <713043CE8B8E1348AF3C546DBE02C1B413D9B938@zcarhxm2.corp.nortel.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "ext Sharon Chisholm" , X-OriginalArrivalTime: 04 Apr 2008 12:46:21.0907 (UTC) FILETIME=[E2A57230:01C89651] Subject: [Netconf] Confirmation of plans to prepare drafts for Notification Content WAS: RE: Confirmation of plans to prepare drafts for Netconf Content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1658022585==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1658022585== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89651.E27480E1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89651.E27480E1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sharon, All, =20 this is true, we talked on Notification content and=20 there was interest to do it. =20 Please let us know if anybody is planning to prepare a draft. Cheers, Mehmet=20 ==20 =20 ________________________________ From: ext Sharon Chisholm [mailto:schishol@nortel.com]=20 Sent: Wednesday, April 02, 2008 7:21 PM To: Ersue, Mehmet (NSN - DE/Muenich); netconf@ietf.org Subject: RE: [Netconf] Confirmation of plans to prepare drafts for Netconf Content =09 =09 hi =20 Actually, I believe there was a lot of interest in Notification content expressed in the meeting, which doesn't appear on your list. I need to confirm the commitment, but I do expect someone from my organization to work on that and/or the interface configuration content. =20 Sharon ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Wednesday, April 02, 2008 10:41 AM To: netconf@ietf.org Subject: [Netconf] Confirmation of plans to prepare drafts for Netconf Content =09 =09 Dear All,=20 in the NETCONF WG session in IETF 71 a few=20 attendees showed interest to prepare I-D's for=20 NETCONF Content for CONFIGURATION (and/or=20 NETCONF related) events and also NETCONF=20 Content for SNMP or SYSLOG notifications.=20 Please confirm your plans on preparing I-Ds for=20 Netconf content on the maillist.=20 Thank you.=20 Bert & Mehmet=20 ------_=_NextPart_001_01C89651.E27480E1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Confirmation of plans to prepare drafts for Netconf = Content
Hi Sharon, All,
 
this is true, we talked on Notification = content and=20
there was interest to do = it.
 
Please let us know if anybody is planning to = prepare
a draft.

Cheers,
Mehmet

 

From: ext Sharon Chisholm=20 [mailto:schishol@nortel.com]
Sent: Wednesday, April 02, = 2008 7:21=20 PM
To: Ersue, Mehmet (NSN - DE/Muenich);=20 netconf@ietf.org
Subject: RE: [Netconf] Confirmation of = plans to=20 prepare drafts for Netconf Content

hi
 
Actually, I believe there was a lot of = interest in=20 Notification content20 ________________________________ From: ext Sharon Chisholm [mailto:schishol@nortel.com]=20 Sent: Wednesday, April 02, 2008 7:21 PM To: Ersue, Mehmet (NSN - DE/Muenich); netconf@ietf.org Subject: RE: [Netconf] Confirmation of plans to prepare drafts for Netconf Content =09 =09 hi =20 Actually, I believe there was a lot of interest in Notification content expressed in the meeting, which doesn't appear on your list. I need to confirm the commitment, but I do expect someone from my organization to work on that and/or the interface configuration content. =20 Sharon ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet (NSN - DE/Muenich) Sent: Wednesday, April 02, 2008 10:41 AM To: netconf@ietf.org Subject: [Netconf] Confirmation of plans to prepare drafts for Netconf Content =09 =09 Dear All,=20 in the NETCONF WG session in IETF 71 a few=20 attendees showed interest to prepare I-D's for=20 NETCONF Content for CONFIGURATION (and/or=20 NETCONF related) events and also NETCONF=20 Content for SNMP or SYSLOG notifications.=20 Please confirm your plans on preparing I-Ds for=20 Netconf content on the maillist.=20 Thank you.=20 Bert & Mehmet=20 ------_=_NextPart_001_01C89651.E27480E1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Confirmation of plans to prepare drafts for Netconf = Content
Hi Sharon, All,
 
this is true, we talked on Notification = content and=20
there was interest to do = it.
 
Please let us know if anybody is planning to = prepare
a draft.

Cheers,
Mehmet

 

From: ext Sharon Chisholm=20 [mailto:schishol@nortel.com]
Sent: Wednesday, April 02, = 2008 7:21=20 PM
To: Ersue, Mehmet (NSN - DE/Muenich);=20 netconf@ietf.org
Subject: RE: [Netconf] Confirmation of = plans to=20 prepare drafts for Netconf Content

hi
 
Actually, I believe there was a lot of = interest in=20 Notification content expre expressed in the meeting, which doesn't appear on = your=20 list. I need to confirm the commitment, but I do expect someone from = my=20 organization to work on that and/or the interface configuration=20 content.
 
Sharon

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet = (NSN -=20 DE/Muenich)
Sent: Wednesday, April 02, 2008 10:41 = AM
To:=20 netconf@ietf.org
Subject: [Netconf] Confirmation of plans to = prepare=20 drafts for Netconf Content


Dear = All,

in the NETCONF WG = session in IETF=20 71 a few
attendees=20 showed interest to prepare I-D's for
NETCONF Content for CONFIGURATION (and/or=20
NETCONF related)=20 events and also NETCONF
Content for SNMP or SYSLOG notifications.

Please confirm your = plans on=20 preparing I-Ds for
Netconf content on the maillist.

Thank = you.

Bert & = Mehmet=20

------_=_NextPart_001_01C89651.E27480E1-- --===============1658022585== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1658022585==-- ssed in the meeting, which doesn't appear on = your=20 list. I need to confirm the commitment, but I do expect someone from = my=20 organization to work on that and/or the interface configuration=20 content.
 
Sharon

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Ersue, Mehmet = (NSN -=20 DE/Muenich)
Sent: Wednesday, April 02, 2008 10:41 = AM
To:=20 netconf@ietf.org
Subject: [Netconf] Confirmation of plans to = prepare=20 drafts for Netconf Content


Dear = All,

in the NETCONF WG = session in IETF=20 71 a few
attendees=20 showed interest to prepare I-D's for
NETCONF Content for CONFIGURATION (and/or=20
NETCONF related)=20 events and also NETCONF
Content for SNMP or SYSLOG notifications.

Please confirm your = plans on=20 preparing I-Ds for
Netconf content on the maillist.

Thank = you.

Bert & = Mehmet=20

------_=_NextPart_001_01C89651.E27480E1-- --===============1658022585== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1658022585==-- From netconf-bounces@ietf.org Fri Apr 4 12:24:19 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7222628C4C2; Fri, 4 Apr 2008 12:24:19 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0877B28C46D for ; Fri, 4 Apr 2008 12:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKESVocRgsnO for ; Fri, 4 Apr 2008 12:24:17 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id CCA1528C39F for ; Fri, 4 Apr 2008 12:24:16 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m34JOKs15953 for ; Fri, 4 Apr 2008 19:24:20 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 15:23:48 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B413E7A825@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B413D9B8FA@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime Thread-Index: AciU3gs/yFQkNkosTfyQmVudbJ3+6wAAKJxwAAFv+FAAaTDFgA== References: <713043CE8B8E1348AF3C546DBE02C1B413D9B8FA@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi There are no objections to mandating use of time zone in eventTime? Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Chisholm, Sharon (CAR:ZZ00) Sent: Wednesday, April 02, 2008 1:12 PM To: netconf@ietf.org Subject: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime Hi This is one of the discuss topics on the notification draft. This will potentially result in two changes - Additional reference (to point to specifications that indicate how dateTime provides sufficient precision) - Adding a statement, if the working group agrees, that makes supporting time zone mandatory. Sharon -----Original Message----- From: Chisholm, Sharon (CAR:ZZ00) Sent: Wednesday, April 02, 2008 12:25 PM To: 'Chris Newman'; 'dward@cisco.com' Cc: 'Hector Trevino (htrevino)'; 'Bert Wijnen - IETF'; 'Ersue, Mehmet (NSN - DE/Muenich)'; 'Dan Romascanu' Subject: Netconf Notification: Issues 8 & 18: DateTime Please reply to this email either indicating that you consider this issue resolved or by providing additional feedback as to why the response is not sufficient. 18. Discuss: dateTime (David Ward) [2008-03-26] ** All of the time references are in "type dateTime" which is XMLschema speak is "YYYY-MM-DDThh:mm:ss" (although there is no reference). Given the output From netconf-bounces@ietf.org Fri Apr 4 12:24:19 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7222628C4C2; Fri, 4 Apr 2008 12:24:19 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0877B28C46D for ; Fri, 4 Apr 2008 12:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKESVocRgsnO for ; Fri, 4 Apr 2008 12:24:17 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id CCA1528C39F for ; Fri, 4 Apr 2008 12:24:16 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m34JOKs15953 for ; Fri, 4 Apr 2008 19:24:20 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 15:23:48 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B413E7A825@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B413D9B8FA@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime Thread-Index: AciU3gs/yFQkNkosTfyQmVudbJ3+6wAAKJxwAAFv+FAAaTDFgA== References: <713043CE8B8E1348AF3C546DBE02C1B413D9B8FA@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi There are no objections to mandating use of time zone in eventTime? Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Chisholm, Sharon (CAR:ZZ00) Sent: Wednesday, April 02, 2008 1:12 PM To: netconf@ietf.org Subject: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime Hi This is one of the discuss topics on the notification draft. This will potentially result in two changes - Additional reference (to point to specifications that indicate how dateTime provides sufficient precision) - Adding a statement, if the working group agrees, that makes supporting time zone mandatory. Sharon -----Original Message----- From: Chisholm, Sharon (CAR:ZZ00) Sent: Wednesday, April 02, 2008 12:25 PM To: 'Chris Newman'; 'dward@cisco.com' Cc: 'Hector Trevino (htrevino)'; 'Bert Wijnen - IETF'; 'Ersue, Mehmet (NSN - DE/Muenich)'; 'Dan Romascanu' Subject: Netconf Notification: Issues 8 & 18: DateTime Please reply to this email either indicating that you consider this issue resolved or by providing additional feedback as to why the response is not sufficient. 18. Discuss: dateTime (David Ward) [2008-03-26] ** All of the time references are in "type dateTime" which is XMLschema speak is "YYYY-MM-DDThh:mm:ss" (although there is no reference). Given the output of conof config events from networking nodes can happen at an incredible rate, why is it felt that seconds are a satisfactory granularity? Most vendors are in fact already implementing event down to the ms. This is critical for fault messages. It is impossible to understand what is happening on a network node with the granularity of seconds. 8. dateTime (Chris Newman) The dateTime XML schema data type makes the timezone optional, in which case time stamps are ambiguous and non-interoperable. This document needs to explicitly require that timezones be present in order to interoperate. I observe that dateTime does permit arbitrary fractions of a second so I do not agree with Dave Ward's DISCUSS on the accuracy issue, however he's right that a normative reference to XML schema data types is necessary to clarify this and should be referenced when the "dateTime" data type is first mentioned. RFC 3339 discusses these issues in more detail. There is no restriction as to the number of decimal digits. We'll add a reference to XML XL documentation and to RFC 3339. FROM ISO 8601 If necessary for a particular application a decimal fraction of hour, minute or second may be included. If a decimal fraction is included, lower order time elements (if any) shall be omitted and the decimal fraction shall be divided from the integer part by the decimal sign specified in ISO 31-0, i.e. the comma [,] or full stop [.]. Of these, the comma is the preferred sign. If the magnitude of the number is less than unity, the decimal sign shall be preceded by two zeros in accordance with 3.6. The interchange parties, dependent upon the application, shall agree the number of digits in the decimal fraction. The format shall be [hhmmss,ss], [hhmm,mm] or [hh,hh] as appropriate (hour minute second, hour minute, and hour, respectively), with as many digits as necessary following the decimal sign. A decimal fraction shall have at least one digit. In the examples below it has been agreed to give the smallest time element a decimal fraction with one digit. As for the timezone issue, I know in the past we have discussed whether or not you could mandate use of timezones. At the time it was felt there were machines that would be unable to support this feature. Keep in mind that this solution needs to work on smaller, lower-end boxes as well as fancy ones. Adding text mandating use of timezones would need to be approved by the working group. Assuming the working group agrees, I have no problem adding this text. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf fig events from networking nodes can happen at an incredible rate, why is it felt that seconds are a satisfactory granularity? Most vendors are in fact already implementing event down to the ms. This is critical for fault messages. It is impossible to understand what is happening on a network node with the granularity of seconds. 8. dateTime (Chris Newman) The dateTime XML schema data type makes the timezone optional, in which case time stamps are ambiguous and non-interoperable. This document needs to explicitly require that timezones be present in order to interoperate. I observe that dateTime does permit arbitrary fractions of a second so I do not agree with Dave Ward's DISCUSS on the accuracy issue, however he's right that a normative reference to XML schema data types is necessary to clarify this and should be referenced when the "dateTime" data type is first mentioned. RFC 3339 discusses these issues in more detail. There is no restriction as to the number of decimal digits. We'll add a reference to XML XL documentation and to RFC 3339. FROM ISO 8601 If necessary for a particular application a decimal fraction of hour, minute or second may be included. If a decimal fraction is included, lower order time elements (if any) shall be omitted and the decimal fraction shall be divided from the integer part by the decimal sign specified in ISO 31-0, i.e. the comma [,] or full stop [.]. Of these, the comma is the preferred sign. If the magnitude of the number is less than unity, the decimal sign shall be preceded by two zeros in accordance with 3.6. The interchange parties, dependent upon the application, shall agree the number of digits in the decimal fraction. The format shall be [hhmmss,ss], [hhmm,mm] or [hh,hh] as appropriate (hour minute second, hour minute, and hour, respectively), with as many digits as necessary following the decimal sign. A decimal fraction shall have at least one digit. In the examples below it has been agreed to give the smallest time element a decimal fraction with one digit. As for the timezone issue, I know in the past we have discussed whether or not you could mandate use of timezones. At the time it was felt there were machines that would be unable to support this feature. Keep in mind that this solution needs to work on smaller, lower-end boxes as well as fancy ones. Adding text mandating use of timezones would need to be approved by the working group. Assuming the working group agrees, I have no problem adding this text. Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 4 12:29:34 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEC3B28C3E0; Fri, 4 Apr 2008 12:29:34 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 341403A6E5E for ; Fri, 4 Apr 2008 12:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-rrQ8xYZmQ5 for ; Fri, 4 Apr 2008 12:29:31 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 8FBB83A6AAC for ; Fri, 4 Apr 2008 12:29:30 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Fri, 04 Apr 2008 12:27:38 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 12:27:51 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m34JRoD55733; Fri, 4 Apr 2008 12:27:50 -0700 (PDT) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m34JQcYk085662; Fri, 4 Apr 2008 19:26:38 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200804041926.m34JQcYk085662@idle.juniper.net> To: "Sharon Chisholm" In-reply-to: <713043CE8B8E1348AF3C546DBE02C1B413E7A825@zcarhxm2.corp.nortel.com> Date: Fri, 04 Apr 2008 15:26:38 -0400 From: Phil Shafer X-OriginalArrivalTime: 04 Apr 2008 19:27:51.0391 (UTC) FILETIME=[F918FEF0:01C89689] Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Sharon Chisholm" writes: >There are no objections to mandating use of time zone in eventTime? What does one use when the time zone is unknown (not configured)? Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 4 12:29:34 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEC3B28C3E0; Fri, 4 Apr 2008 12:29:34 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 341403A6E5E for ; Fri, 4 Apr 2008 12:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-rrQ8xYZmQ5 for ; Fri, 4 Apr 2008 12:29:31 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 8FBB83A6AAC for ; Fri, 4 Apr 2008 12:29:30 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Fri, 04 Apr 2008 12:27:38 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Apr 2008 12:27:51 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m34JRoD55733; Fri, 4 Apr 2008 12:27:50 -0700 (PDT) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m34JQcYk085662; Fri, 4 Apr 2008 19:26:38 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200804041926.m34JQcYk085662@idle.juniper.net> To: "Sharon Chisholm" In-reply-to: <713043CE8B8E1348AF3C546DBE02C1B413E7A825@zcarhxm2.corp.nortel.com> Date: Fri, 04 Apr 2008 15:26:38 -0400 From: Phil Shafer X-OriginalArrivalTime: 04 Apr 2008 19:27:51.0391 (UTC) FILETIME=[F918FEF0:01C89689] Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Sharon Chisholm" writes: >There are no objections to mandating use of time zone in eventTime? What does one use when the time zone is unknown (not configured)? Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 7 06:11:27 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E58FA3A6AC3; Mon, 7 Apr 2008 06:11:27 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E92628C12D for ; Mon, 7 Apr 2008 06:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hmoXpUarU0j for ; Mon, 7 Apr 2008 06:11:26 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 0E83F3A6816 for ; Mon, 7 Apr 2008 06:11:25 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m37DBZR08754; Mon, 7 Apr 2008 13:11:36 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 09:11:35 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B413E7AF64@zcarhxm2.corp.nortel.com> In-Reply-To: <200804041926.m34JQcYk085662@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime Thread-Index: AciWij+Zifs/2ef+RYugt7LmC8O7XgCJDsTg References: <713043CE8B8E1348AF3C546DBE02C1B413E7A825@zcarhxm2.corp.nortel.com> <200804041926.m34JQcYk085662@idle.juniper.net> From: "Sharon Chisholm" To: "Phil Shafer" Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Good question. I'm going to assume here that if we do this we do it for all three of our dateTime elements for consistency. I think there are two cases 1) Not specified by client in a or but supported on the NE, then the default time zone of the box is assumed 2) Not configured on the box. Then I don't think there is actually a workaround. This would be a non-compliant device. Note that if we don't do this we need to answer the issues raised in http://tools.ietf.org/html/rfc3339#section-4.4 Sharon -----Original Message----- From: Phil Shafer [mailto:phil@juniper.net] Sent: Friday, April 04, 2008 3:27 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime "Sharon Chisholm" writes: >There are no objections to mandating use of time zone in eventTime? What does one use when the time zone is unknown (not configured)? Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 7 06:11:27 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E58FA3A6AC3; Mon, 7 Apr 2008 06:11:27 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E92628C12D for ; Mon, 7 Apr 2008 06:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hmoXpUarU0j for ; Mon, 7 Apr 2008 06:11:26 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 0E83F3A6816 for ; Mon, 7 Apr 2008 06:11:25 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m37DBZR08754; Mon, 7 Apr 2008 13:11:36 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 09:11:35 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B413E7AF64@zcarhxm2.corp.nortel.com> In-Reply-To: <200804041926.m34JQcYk085662@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime Thread-Index: AciWij+Zifs/2ef+RYugt7LmC8O7XgCJDsTg References: <713043CE8B8E1348AF3C546DBE02C1B413E7A825@zcarhxm2.corp.nortel.com> <200804041926.m34JQcYk085662@idle.juniper.net> From: "Sharon Chisholm" To: "Phil Shafer" Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Good question. I'm going to assume here that if we do this we do it for all three of our dateTime elements for consistency. I think there are two cases 1) Not specified by client in a or but supported on the NE, then the default time zone of the box is assumed 2) Not configured on the box. Then I don't think there is actually a workaround. This would be a non-compliant device. Note that if we don't do this we need to answer the issues raised in http://tools.ietf.org/html/rfc3339#section-4.4 Sharon -----Original Message----- From: Phil Shafer [mailto:phil@juniper.net] Sent: Friday, April 04, 2008 3:27 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime "Sharon Chisholm" writes: >There are no objections to mandating use of time zone in eventTime? What does one use when the time zone is unknown (not configured)? Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 7 09:17:56 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2FD628C483; Mon, 7 Apr 2008 09:17:56 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6368028C485 for ; Mon, 7 Apr 2008 09:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqPU0gLbpvU5 for ; Mon, 7 Apr 2008 09:17:48 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 7FCBF28C466 for ; Mon, 7 Apr 2008 09:17:48 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m37GHwd01911 for ; Mon, 7 Apr 2008 16:17:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 12:17:57 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B413E7B566@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Netconf Notification: Issue 7: Protocol State machine II Thread-Index: AciU4HyjZfHDE/bsQ5eBaO7cZn2Z/AD6AGVw From: "Sharon Chisholm" To: Subject: [Netconf] FW: Netconf Notification: Issue 7: Protocol State machine II X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi I believe the best approach to this issue would be to create the 'Scalability Considerations' section as suggested. Sharon -----Original Message----- From: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM] Sent: Wednesday, April 02, 2008 12:42 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: Hector Trevino (htrevino); Bert Wijnen - IETF; Ersue, Mehmet (NSN - DE/Muenich); Dan Romascanu Subject: Re: Netconf Notification: Issue 7: Protocol State machine II --On April 1, 2008 19:22:53 -0400 Sharon Chisholm wrote: > Please reply to this email either indicating that you consider this > issue resolved or by providing additional feedback as to why the > response is not sufficient. > > 7. Protocol state machine II (Chris Newman) One additional state issue > -- given at least two Netconf bindings support multiple channels (BEEP > and SSH), the explicit state change will not be a problem for such > clients as long as the server permits the same client to open more > than one channel. However, after skimming both the SSH and BEEP > bindings, it is not clear to me if the Netconf server is required to > support multiple BEEP channels or multiple SSH sessions on the same > TCP connection. It's important to clarify this point to determine the > impact of the state change model on Netconf. > > Response: > > NETCONF has a clear separation between the protocol and the transport > mappings. If there is an impact, it would not be to this document, but > rather to the various transport mappings. That being said, I don't > understand how multiple channels relates to the new protocol state > introduced in this draft. The assumption is that each channel is a > NETCONF session so the behaviour should be the same as opening two > separate SSH sessions as getting channelized SSH. This issue is not resolved. The performance impact of setting of a secure session (via SSH or BEEP+TLS) is non-trivial. This new notification protocol has the effect of making most clients require multiple NETCONF sessions, something that may not have been the case previously. If the infrastructure specifications necessary to support this new performance impact need to be updated to accommodate it, we at least need to understand that before progressing this document and perhaps add a normative reference to the new versions. If the WG believes the implicit new need for multiple Netconf channels with multiple security layers even for just one client isn't going to be a problem for network devices, the document should discuss that in a "scalability considerations" section. - Chris _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 7 09:17:56 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2FD628C483; Mon, 7 Apr 2008 09:17:56 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6368028C485 for ; Mon, 7 Apr 2008 09:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqPU0gLbpvU5 for ; Mon, 7 Apr 2008 09:17:48 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 7FCBF28C466 for ; Mon, 7 Apr 2008 09:17:48 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m37GHwd01911 for ; Mon, 7 Apr 2008 16:17:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 12:17:57 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B413E7B566@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Netconf Notification: Issue 7: Protocol State machine II Thread-Index: AciU4HyjZfHDE/bsQ5eBaO7cZn2Z/AD6AGVw From: "Sharon Chisholm" To: Subject: [Netconf] FW: Netconf Notification: Issue 7: Protocol State machine II X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi I believe the best approach to this issue would be to create the 'Scalability Considerations' section as suggested. Sharon -----Original Message----- From: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM] Sent: Wednesday, April 02, 2008 12:42 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: Hector Trevino (htrevino); Bert Wijnen - IETF; Ersue, Mehmet (NSN - DE/Muenich); Dan Romascanu Subject: Re: Netconf Notification: Issue 7: Protocol State machine II --On April 1, 2008 19:22:53 -0400 Sharon Chisholm wrote: > Please reply to this email either indicating that you consider this > issue resolved or by providing additional feedback as to why the > response is not sufficient. > > 7. Protocol state machine II (Chris Newman) One additional state issue > -- given at least two Netconf bindings support multiple channels (BEEP > and SSH), the explicit state change will not be a problem for such > clients as long as the server permits the same client to open more > than one channel. However, after skimming both the SSH and BEEP > bindings, it is not clear to me if the Netconf server is required to > support multiple BEEP channels or multiple SSH sessions on the same > TCP connection. It's important to clarify this point to determine the > impact of the state change model on Netconf. > > Response: > > NETCONF has a clear separation between the protocol and the transport > mappings. If there is an impact, it would not be to this document, but > rather to the various transport mappings. That being said, I don't > understand how multiple channels relates to the new protocol state > introduced in this draft. The assumption is that each channel is a > NETCONF session so the behaviour should be the same as opening two > separate SSH sessions as getting channelized SSH. This issue is not resolved. The performance impact of setting of a secure session (via SSH or BEEP+TLS) is non-trivial. This new notification protocol has the effect of making most clients require multiple NETCONF sessions, something that may not have been the case previously. If the infrastructure specifications necessary to support this new performance impact need to be updated to accommodate it, we at least need to understand that before progressing this document and perhaps add a normative reference to the new versions. If the WG believes the implicit new need for multiple Netconf channels with multiple security layers even for just one client isn't going to be a problem for network devices, the document should discuss that in a "scalability considerations" section. - Chris _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 7 12:20:41 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A32573A6986; Mon, 7 Apr 2008 12:20:41 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9B623A6AAA for ; Mon, 7 Apr 2008 12:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.255 X-Spam-Level: X-Spam-Status: No, score=-6.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8BxPHNhtj4u for ; Mon, 7 Apr 2008 12:20:35 -0700 (PDT) Received: from chip3og58.obsmtp.com (chip3og58.obsmtp.com [64.18.14.181]) by core3.amsl.com (Postfix) with ESMTP id 3EA9A3A6AF4 for ; Mon, 7 Apr 2008 12:20:04 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob58.postini.com ([64.18.6.12]) with SMTP; Mon, 07 Apr 2008 12:20:15 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 12:20:10 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m37JK9D60230; Mon, 7 Apr 2008 12:20:09 -0700 (PDT) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m37JIoj0005727; Mon, 7 Apr 2008 19:18:54 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200804071918.m37JIoj0005727@idle.juniper.net> To: "Sharon Chisholm" In-reply-to: <713043CE8B8E1348AF3C546DBE02C1B413E7B566@zcarhxm2.corp.nortel.com> Date: Mon, 07 Apr 2008 15:18:50 -0400 From: Phil Shafer X-OriginalArrivalTime: 07 Apr 2008 19:20:10.0554 (UTC) FILETIME=[65A819A0:01C898E4] Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issue 7: Protocol State machine II X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I thought to point of intermixing notifications with normal netconf RPC was to avoid opening an additional connection. If we're requiring a new connection, can we do this in a way that avoids changing to the NETCONF RPC mechanism? Also I don't understand the comment: >> The assumption is that each channel is a >> NETCONF session so the behaviour should be the same as opening two >> separate SSH sessions as getting channelized SSH. Thanks, Phil "Sharon Chisholm" writes: >Hi > >I believe the best approach to this issue would be to create the >'Scalability Considerations' section as suggested. > >Sharon > >-----Original Message----- >From: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM] >Sent: Wednesday, April 02, 2008 12:42 PM >To: Chisholm, Sharon (CAR:ZZ00) >Cc: Hector Trevino (htrevino); Bert Wijnen - IETF; Ersue, Mehmet (NSN - >DE/Muenich); Dan Romascanu >Subject: Re: Netconf Notification: Issue 7: Protocol State machine II > >--On April 1, 2008 19:22:53 -0400 Sharon Chisholm >wrote: > >> Please reply to this email either indicating that you consider this >> issue resolved oFrom netconf-bounces@ietf.org Mon Apr 7 12:20:41 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A32573A6986; Mon, 7 Apr 2008 12:20:41 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9B623A6AAA for ; Mon, 7 Apr 2008 12:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.255 X-Spam-Level: X-Spam-Status: No, score=-6.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8BxPHNhtj4u for ; Mon, 7 Apr 2008 12:20:35 -0700 (PDT) Received: from chip3og58.obsmtp.com (chip3og58.obsmtp.com [64.18.14.181]) by core3.amsl.com (Postfix) with ESMTP id 3EA9A3A6AF4 for ; Mon, 7 Apr 2008 12:20:04 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob58.postini.com ([64.18.6.12]) with SMTP; Mon, 07 Apr 2008 12:20:15 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 12:20:10 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m37JK9D60230; Mon, 7 Apr 2008 12:20:09 -0700 (PDT) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m37JIoj0005727; Mon, 7 Apr 2008 19:18:54 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200804071918.m37JIoj0005727@idle.juniper.net> To: "Sharon Chisholm" In-reply-to: <713043CE8B8E1348AF3C546DBE02C1B413E7B566@zcarhxm2.corp.nortel.com> Date: Mon, 07 Apr 2008 15:18:50 -0400 From: Phil Shafer X-OriginalArrivalTime: 07 Apr 2008 19:20:10.0554 (UTC) FILETIME=[65A819A0:01C898E4] Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issue 7: Protocol State machine II X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I thought to point of intermixing notifications with normal netconf RPC was to avoid opening an additional connection. If we're requiring a new connection, can we do this in a way that avoids changing to the NETCONF RPC mechanism? Also I don't understand the comment: >> The assumption is that each channel is a >> NETCONF session so the behaviour should be the same as opening two >> separate SSH sessions as getting channelized SSH. Thanks, Phil "Sharon Chisholm" writes: >Hi > >I believe the best approach to this issue would be to create the >'Scalability Considerations' section as suggested. > >Sharon > >-----Original Message----- >From: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM] >Sent: Wednesday, April 02, 2008 12:42 PM >To: Chisholm, Sharon (CAR:ZZ00) >Cc: Hector Trevino (htrevino); Bert Wijnen - IETF; Ersue, Mehmet (NSN - >DE/Muenich); Dan Romascanu >Subject: Re: Netconf Notification: Issue 7: Protocol State machine II > >--On April 1, 2008 19:22:53 -0400 Sharon Chisholm >wrote: > >> Please reply to this email either indicating that you consider this >> issue resor by providing additional feedback as to why the >> response is not sufficient. >> >> 7. Protocol state machine II (Chris Newman) One additional state issue > >> -- given at least two Netconf bindings support multiple channels (BEEP > >> and SSH), the explicit state change will not be a problem for such >> clients as long as the server permits the same client to open more >> than one channel. However, after skimming both the SSH and BEEP >> bindings, it is not clear to me if the Netconf server is required to >> support multiple BEEP channels or multiple SSH sessions on the same >> TCP connection. It's important to clarify this point to determine the > >> impact of the state change model on Netconf. >> >> Response: >> > NETCONF has a clear separation between the protocol and the transport >> mappings. If there is an impact, it would not be to this document, but > >> rather to the various transport mappings. That being said, I don't >> understand how multiple channels relates to the new protocol state >> introduced in this draft. The assumption is that each channel is a >> NETCONF session so the behaviour should be the same as opening two >> separate SSH sessions as getting channelized SSH. > >This issue is not resolved. The performance impact of setting of a >secure session (via SSH or BEEP+TLS) is non-trivial. This new >notification protocol has the effect of making most clients require >multiple NETCONF sessions, something that may not have been the case >previously. If the infrastructure specifications necessary to support >this new performance impact need to be updated to accommodate it, we at >least need to understand that before progressing this document and >perhaps add a normative reference to the new versions. If the WG >believes the implicit new need for multiple Netconf channels with >multiple security layers even for just one client isn't going to be a >problem for network devices, the document should discuss that in a >"scalability considerations" section. > > - Chris > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf lved or by providing additional feedback as to why the >> response is not sufficient. >> >> 7. Protocol state machine II (Chris Newman) One additional state issue > >> -- given at least two Netconf bindings support multiple channels (BEEP > >> and SSH), the explicit state change will not be a problem for such >> clients as long as the server permits the same client to open more >> than one channel. However, after skimming both the SSH and BEEP >> bindings, it is not clear to me if the Netconf server is required to >> support multiple BEEP channels or multiple SSH sessions on the same >> TCP connection. It's important to clarify this point to determine the > >> impact of the state change model on Netconf. >> >> Response: >> > NETCONF has a clear separation between the protocol and the transport >> mappings. If there is an impact, it would not be to this document, but > >> rather to the various transport mappings. That being said, I don't >> understand how multiple channels relates to the new protocol state >> introduced in this draft. The assumption is that each channel is a >> NETCONF session so the behaviour should be the same as opening two >> separate SSH sessions as getting channelized SSH. > >This issue is not resolved. The performance impact of setting of a >secure session (via SSH or BEEP+TLS) is non-trivial. This new >notification protocol has the effect of making most clients require >multiple NETCONF sessions, something that may not have been the case >previously. If the infrastructure specifications necessary to support >this new performance impact need to be updated to accommodate it, we at >least need to understand that before progressing this document and >perhaps add a normative reference to the new versions. If the WG >believes the implicit new need for multiple Netconf channels with >multiple security layers even for just one client isn't going to be a >problem for network devices, the document should discuss that in a >"scalability considerations" section. > > - Chris > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 7 12:48:09 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4223928C34B; Mon, 7 Apr 2008 12:48:09 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9440E28C2E3 for ; Mon, 7 Apr 2008 12:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwUor6MHt7Gw for ; Mon, 7 Apr 2008 12:48:07 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id A346828C312 for ; Mon, 7 Apr 2008 12:48:07 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 65F8E1B80C4; Mon, 7 Apr 2008 21:48:20 +0200 (CEST) Date: Mon, 07 Apr 2008 21:46:19 +0200 (CEST) Message-Id: <20080407.214619.104761311.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200804071918.m37JIoj0005727@idle.juniper.net> References: <713043CE8B8E1348AF3C546DBE02C1B413E7B566@zcarhxm2.corp.nortel.com> <200804071918.m37JIoj0005727@idle.juniper.net> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issue 7: Protocol State machine II X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Phil Shafer wrote: > I thought to point of intermixing notifications with normal > netconf RPC was to avoid opening an additional connection. This intermixing is done as an optional capability :interleave. If this capability is supported, no additional NETCONF session is necessary. For the multiple NETCONF session issue, I believe that although RFC 4742 isn't explicit, the consensus is that multiple SSH channels will work (and AFAIK most (all?) implementations support this), i.e. each SSH channel creates a new NETCONF session over the same TCP connection. So in even if the server does not support the :interleave capability, the client does not have to create a new SSH connection for notifications to work. > If we're requiring a new connection, can we do this in a > way that avoids changing to the NETCONF RPC mechanism? I don't understand this comment. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 7 12:48:09 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4223928C34B; Mon, 7 Apr 2008 12:48:09 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9440E28C2E3 for ; Mon, 7 Apr 2008 12:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwUor6MHt7Gw for ; Mon, 7 Apr 2008 12:48:07 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id A346828C312 for ; Mon, 7 Apr 2008 12:48:07 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 65F8E1B80C4; Mon, 7 Apr 2008 21:48:20 +0200 (CEST) Date: Mon, 07 Apr 2008 21:46:19 +0200 (CEST) Message-Id: <20080407.214619.104761311.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <200804071918.m37JIoj0005727@idle.juniper.net> References: <713043CE8B8E1348AF3C546DBE02C1B413E7B566@zcarhxm2.corp.nortel.com> <200804071918.m37JIoj0005727@idle.juniper.net> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issue 7: Protocol State machine II X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Phil Shafer wrote: > I thought to point of intermixing notifications with normal > netconf RPC was to avoid opening an additional connection. This intermixing is done as an optional capability :interleave. If this capability is supported, no additional NETCONF session is necessary. For the multiple NETCONF session issue, I believe that although RFC 4742 isn't explicit, the consensus is that multiple SSH channels will work (and AFAIK most (all?) implementations support this), i.e. each SSH channel creates a new NETCONF session over the same TCP connection. So in even if the server does not support the :interleave capability, the client does not have to create a new SSH connection for notifications to work. > If we're requiring a new connection, can we do this in a > way that avoids changing to the NETCONF RPC mechanism? I don't understand this comment. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 7 12:58:18 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8E93A6D64; Mon, 7 Apr 2008 12:58:18 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D4E13A6CBA for ; Mon, 7 Apr 2008 12:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY8DCur3Wfif for ; Mon, 7 Apr 2008 12:58:16 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 427613A68A2 for ; Mon, 7 Apr 2008 12:58:16 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m37Jvl723989; Mon, 7 Apr 2008 19:57:47 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 15:58:23 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B413EE6DBF@zcarhxm2.corp.nortel.com> In-Reply-To: <200804071918.m37JIoj0005727@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: Netconf Notification: Issue 7: Protocol State machine II Thread-Index: AciY5G3/KWqf6wlhSOiOCJTnFCvxmQABDQBw References: <713043CE8B8E1348AF3C546DBE02C1B413E7B566@zcarhxm2.corp.nortel.com> <200804071918.m37JIoj0005727@idle.juniper.net> From: "Sharon Chisholm" To: "Phil Shafer" Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issue 7: Protocol State machine II X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Interleave does helps, but we still can't have multiple subscriptions on the same session without defining a new capability. My point on the channel thing was that the protocol layer is agnostic. It's all just a NETCONF session. Sharon -----Original Message----- From: Phil Shafer [mailto:phil@juniper.net] Sent: Monday, April 07, 2008 3:19 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issue 7: Protocol State machine II I thought to point of intermixing notifications with normal netconf RPC was to avoid opening an additional connection. If we're requiring a new connection, can we do this in a way that avoids changing to the NETCONF RPC mechanism? Also I don't understand the comment: >> The assumption is that each channel is a NETCONF session so the >> behaviour should be the same as opening two separate SSH sessions as >> getting channelized SSH. Thanks, Phil "Sharon Chisholm" writes: >Hi > >I believe the best approach to this issue would be to create the >'Scalability Considerations' section as suggested. > >Sharon > >-----Original Message----- >From: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM] >Sent: Wednesday, April 02, 2008 12:42 PM >To: Chisholm, Sharon (CAR:ZZ00) >Cc: Hector Trevino (htrevino); Bert Wijnen - IETF; Ersue, Mehmet (NSN - >DE/Muenich); Dan Romascanu >Subject: Re: Netconf Notification: Issue 7: Protocol State machine II > >--On April 1, 2008 19:22:53 -0400 Sharon Chisholm >wrote: > >> Please reply to this email either indicating that you consider this >> issue resolved or by providing additional feedback as to why the >> response is not sufficient. >> >> 7. Protocol state machine II (Chris Newman) One additional state >> issue > >> -- given at least two Netconf bindings support multiple channels >> (BEEP > >> and SSH), the explicit state change will not be a problem for such >> clients as long as the server permits the same client to open more >> than one channel. However, after skimming both the SSH and BEEP >> bindings, it is not clear to me if the Netconf server is required to >> support multiple BEEP channels or multiple SSH sessions on the same >> TCP connection. It's important to clarify this point to determine >> the > >> impact of the state change model on Netconf. >> >> Response: >> > NETCONF has a clear separation between the protocol and the transport >> mappings. If there is an impact, it would not be to this document, >> but > >> rather to the various transport mappings. That being said, I don't >> understand how multiple channels relates to the new protocol state >> introduced in this draft. The assumption is that each channel is a >> NETCONF session so the behaviour should be the same as opening two >> separate SSH sessions as getting channelized SSH. > >This issue is not resolved. The performance impact of setting of a >secure session (via SSH or BEEP+TLS) is non-trivial. This new >notification protocol has the effect of making most clients require >multiple NETCONF sessions, something that may not have been the case >previously. If the infrastructure specifications necessary to support >this new performance impact need to be updated to accommodate it, we at >least need to understand that before progressing this document and >perhaps add a normative reference to the new versions. If the WG >believes the implicit new need for multiple Netconf channels with >multiple security layers even for just one client isn't going to be a >problem for network devices, the document should discuss that in a >"scalability considerations" section. > > - Chris > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 7 12:58:18 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8E93A6D64; Mon, 7 Apr 2008 12:58:18 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D4E13A6CBA for ; Mon, 7 Apr 2008 12:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY8DCur3Wfif for ; Mon, 7 Apr 2008 12:58:16 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 427613A68A2 for ; Mon, 7 Apr 2008 12:58:16 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m37Jvl723989; Mon, 7 Apr 2008 19:57:47 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Apr 2008 15:58:23 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B413EE6DBF@zcarhxm2.corp.nortel.com> In-Reply-To: <200804071918.m37JIoj0005727@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: Netconf Notification: Issue 7: Protocol State machine II Thread-Index: AciY5G3/KWqf6wlhSOiOCJTnFCvxmQABDQBw References: <713043CE8B8E1348AF3C546DBE02C1B413E7B566@zcarhxm2.corp.nortel.com> <200804071918.m37JIoj0005727@idle.juniper.net> From: "Sharon Chisholm" To: "Phil Shafer" Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issue 7: Protocol State machine II X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Interleave does helps, but we still can't have multiple subscriptions on the same session without defining a new capability. My point on the channel thing was that the protocol layer is agnostic. It's all just a NETCONF session. Sharon -----Original Message----- From: Phil Shafer [mailto:phil@juniper.net] Sent: Monday, April 07, 2008 3:19 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issue 7: Protocol State machine II I thought to point of intermixing notifications with normal netconf RPC was to avoid opening an additional connection. If we're requiring a new connection, can we do this in a way that avoids changing to the NETCONF RPC mechanism? Also I don't understand the comment: >> The assumption is that each channel is a NETCONF session so the >> behaviour should be the same as opening two separate SSH sessions as >> getting channelized SSH. Thanks, Phil "Sharon Chisholm" writes: >Hi > >I believe the best approach to this issue would be to create the >'Scalability Considerations' section as suggested. > >Sharon > >-----Original Message----- >From: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM] >Sent: Wednesday, April 02, 2008 12:42 PM >To: Chisholm, Sharon (CAR:ZZ00) >Cc: Hector Trevino (htrevino); Bert Wijnen - IETF; Ersue, Mehmet (NSN - >DE/Muenich); Dan Romascanu >Subject: Re: Netconf Notification: Issue 7: Protocol State machine II > >--On April 1, 2008 19:22:53 -0400 Sharon Chisholm >wrote: > >> Please reply to this email either indicating that you consider this >> issue resolved or by providing additional feedback as to why the >> response is not sufficient. >> >> 7. Protocol state machine II (Chris Newman) One additional state >> issue > >> -- given at least two Netconf bindings support multiple channels >> (BEEP > >> and SSH), the explicit state change will not be a problem for such >> clients as long as the server permits the same client to open more >> than one channel. However, after skimming both the SSH and BEEP >> bindings, it is not clear to me if the Netconf server is required to >> support multiple BEEP channels or multiple SSH sessions on the same >> TCP connection. It's important to clarify this point to determine >> the > >> impact of the state change model on Netconf. >> >> Response: >> > NETCONF has a clear separation between the protocol and the transport >> mappings. If there is an impact, it would not be to this document, >> but > >> rather to the various transport mappings. That being said, I don't >> understand how multiple channels relates to the new protocol state >> introduced in this draft. The assumption is that each channel is a >> NETCONF session so the behaviour should be the same as opening two >> separate SSH sessions as getting channelized SSH. > >This issue is not resolved. The performance impact of setting of a >secure session (via SSH or BEEP+TLS) is non-trivial. This new >notification protocol has the effect of making most clients require >multiple NETCONF sessions, something that may not have been the case >previously. If the infrastructure specifications necessary to support >this new performance impact need to be updated to accommodate it, we at >least need to understand that before progressing this document and >perhaps add a normative reference to the new versions. If the WG >believes the implicit new need for multiple Netconf channels with >multiple security layers even for just one client isn't going to be a >problem for network devices, the document should discuss that in a >"scalability considerations" section. > > - Chris > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 7 13:43:39 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84A628C140; Mon, 7 Apr 2008 13:43:39 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBB743A6AC2 for ; Mon, 7 Apr 2008 13:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEZFmQ22QWyE for ; Mon, 7 Apr 2008 13:43:37 -0700 (PDT) Received: from chip3og60.obsmtp.com (chip3og60.obsmtp.com [64.18.14.185]) by core3.amsl.com (Postfix) with ESMTP id 761A53A69DE for ; Mon, 7 Apr 2008 13:43:35 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob60.postini.com ([64.18.6.12]) with SMTP; Mon, 07 Apr 2008 13:41:51 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Apr 2008 13:41:07 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m37Kf6D85231; Mon, 7 Apr 2008 13:41:06 -0700 (PDT) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m37KdkEi006299; Mon, 7 Apr 2008 20:39:46 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200804072039.m37KdkEi006299@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080407.214619.104761311.mbj@tail-f.com> Date: Mon, 07 Apr 2008 16:39:46 -0400 From: Phil Shafer X-OriginalArrivalTime: 07 Apr 2008 20:41:07.0123 (UTC) FILETIME=[B465B830:01C898EF] Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issue 7: Protocol State machine II X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund writes: >This intermixing is done as an optional capability :interleave. If >this capability is supported, no additional NETCONF session is >necessary. I thought the draft supported a two-mode thing, where you could request some notifications, get them, and then return to normal mode. Wait, I guess this is only for stop-time and non-live notifications. >> If we're requiring a new connection, can we do this in a >> way that avoids changing to the NETCONF RPC mechanism? >I don't understand this comment. I dislike the way the notification draft changes the 4741 rpc mechanism. If we are requiring a new connection, we should be able to avoid such changes. (I also dislike the modality it introduces, and I dislike the interleaving of commands and notifications, since it means I can't get notifications during rpc execution, which is where/when I need them). Hmmm.... maybe there's a better way, that can kill two birds with one stone. When we started the XMLCONF design team (way back when), there were two deficiencies in JUNOScript that Rob and I wanted to address. The first was the lack of multi-channel support, whiFrom netconf-bounces@ietf.org Mon Apr 7 13:43:39 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84A628C140; Mon, 7 Apr 2008 13:43:39 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBB743A6AC2 for ; Mon, 7 Apr 2008 13:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEZFmQ22QWyE for ; Mon, 7 Apr 2008 13:43:37 -0700 (PDT) Received: from chip3og60.obsmtp.com (chip3og60.obsmtp.com [64.18.14.185]) by core3.amsl.com (Postfix) with ESMTP id 761A53A69DE for ; Mon, 7 Apr 2008 13:43:35 -0700 (PDT) Received: from source ([66.129.224.36]) by chip3ob60.postini.com ([64.18.6.12]) with SMTP; Mon, 07 Apr 2008 13:41:51 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Apr 2008 13:41:07 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m37Kf6D85231; Mon, 7 Apr 2008 13:41:06 -0700 (PDT) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m37KdkEi006299; Mon, 7 Apr 2008 20:39:46 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200804072039.m37KdkEi006299@idle.juniper.net> To: Martin Bjorklund In-reply-to: <20080407.214619.104761311.mbj@tail-f.com> Date: Mon, 07 Apr 2008 16:39:46 -0400 From: Phil Shafer X-OriginalArrivalTime: 07 Apr 2008 20:41:07.0123 (UTC) FILETIME=[B465B830:01C898EF] Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issue 7: Protocol State machine II X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund writes: >This intermixing is done as an optional capability :interleave. If >this capability is supported, no additional NETCONF session is >necessary. I thought the draft supported a two-mode thing, where you could request some notifications, get them, and then return to normal mode. Wait, I guess this is only for stop-time and non-live notifications. >> If we're requiring a new connection, can we do this in a >> way that avoids changing to the NETCONF RPC mechanism? >I don't understand this comment. I dislike the way the notification draft changes the 4741 rpc mechanism. If we are requiring a new connection, we should be able to avoid such changes. (I also dislike the modality it introduces, and I dislike the interleaving of commands and notifications, since it means I can't get notifications during rpc execution, which is where/when I need them). Hmmm.... maybe there's a better way, that can kill two birds with one stone. When we started the XMLCONF design team (way back when), there were two deficiencies in JUNOScript that Rob and I wanted to address. The first was the lack of multi-channel support, which is semi-solved using SSH channels (though I don't know how to address these channels to say "hey, there's an incoming software image in channel XYZ"). The other way the need for a framing protocol, to allow us to avoid a namespace-aware search for . We were hoping that BEEP would be the answer for both of these issues, but BEEP never lived up to our needs and is pretty much dead WRT NETCONF, as far as I can tell. We ended up with the "]]>]]>" hack, which is better in that it's not scoped by a namespace, but still feels like a hack. I've been thinking about making a simple TLV framing protocol as a capability on top of NETCONF/SSH that allows one to know when the rpc/rpc-reply is complete. Only two tags (in the TLV sense) would be required, one for "here's something but there's more" and one for "here's the last of it". Two for each direction allows software to discriminate between incoming rpcs and outgoing replies (which shouldn't be required in a perfect world, but....). If we add a new TLV for notifications, you can intermix them during an rpc-reply without impacting the rpc/rpc-reply content. Putting this demux in a trivial framing protocol between the ssh channel and the netconf content is simpler and allows easy and flexible interleaving. Making this TLV mechanism optional means debugging sessions would simply not turn it on, allowing typing/cut-n-pasting/etc without worrying about having to count bytes. It's just a thought. If anyone's interested in working with me to write the TLV mechanism up as an I-D, please contact me off list. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ch is semi-solved using SSH channels (though I don't know how to address these channels to say "hey, there's an incoming software image in channel XYZ"). The other way the need for a framing protocol, to allow us to avoid a namespace-aware search for . We were hoping that BEEP would be the answer for both of these issues, but BEEP never lived up to our needs and is pretty much dead WRT NETCONF, as far as I can tell. We ended up with the "]]>]]>" hack, which is better in that it's not scoped by a namespace, but still feels like a hack. I've been thinking about making a simple TLV framing protocol as a capability on top of NETCONF/SSH that allows one to know when the rpc/rpc-reply is complete. Only two tags (in the TLV sense) would be required, one for "here's something but there's more" and one for "here's the last of it". Two for each direction allows software to discriminate between incoming rpcs and outgoing replies (which shouldn't be required in a perfect world, but....). If we add a new TLV for notifications, you can intermix them during an rpc-reply without impacting the rpc/rpc-reply content. Putting this demux in a trivial framing protocol between the ssh channel and the netconf content is simpler and allows easy and flexible interleaving. Making this TLV mechanism optional means debugging sessions would simply not turn it on, allowing typing/cut-n-pasting/etc without worrying about having to count bytes. It's just a thought. If anyone's interested in working with me to write the TLV mechanism up as an I-D, please contact me off list. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 7 16:36:11 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 106F83A6AB0; Mon, 7 Apr 2008 16:36:11 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179383A6AB0 for ; Mon, 7 Apr 2008 16:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P73tkWdNFS0M for ; Mon, 7 Apr 2008 16:36:09 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 222283A67DF for ; Mon, 7 Apr 2008 16:36:09 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 57550399BD8; Mon, 7 Apr 2008 16:33:53 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=MK273HR51yBXsUssSXLPtxelWZ0=; b=rkMWcxWsERN91d98ycO8yO/H2OQJ7Dnqdppk1kieUtHNnPXyud8Zyc0FiAecAWzubcxlN2Ygh5rdNXFgnvH4K01jaNtybeSoGJbl5aU0ougaP0mZCptndV6iWM/r2LJJqvOFVXzxfHj3ruaeB84PKjZpzJZKrGHFEsdlxeUF8i4= Received: by wes.hardakers.net (Postfix, from userid 274) id 3A178399C50; Mon, 7 Apr 2008 16:33:53 -0700 (PDT) From: Wes Hardaker To: "Ersue\, Mehmet \(NSN - DE\/Muenich\)" Organization: Sparta References: Date: Mon, 07 Apr 2008 16:33:53 -0700 In-Reply-To: (Mehmet Ersue's message of "Wed, 2 Apr 2008 16:36:02 +0200") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71 and Action Items X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org >>>>> "ME" == Mehmet Ersue writes: ME> => Wes Hardaker: ME> Please post your questions on: ME> - what happens if you copy candidate to running ME> while a partial lock is held? Here's a quick summary about partial vs global commands. Locking is one type of command that has both a global (in the core netconf model) and partial (in the newly proposed partial locking draft). Global commands are those that operate on entire configuration datastores at once. EG, , , , ... It affects the whole configuration datastore or it doesn't. If, when authorization comes along, a netconf user don't have write access to the whole configuration store it's currently undefined as to what happens, though some obvious things are probably apparent (a copy-config by a user with restricted access shouldn't be allowed to change parts of a config being copied TO that they're not authorized to change). ParFrom netconf-bounces@ietf.org Mon Apr 7 16:36:11 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 106F83A6AB0; Mon, 7 Apr 2008 16:36:11 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179383A6AB0 for ; Mon, 7 Apr 2008 16:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P73tkWdNFS0M for ; Mon, 7 Apr 2008 16:36:09 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 222283A67DF for ; Mon, 7 Apr 2008 16:36:09 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 57550399BD8; Mon, 7 Apr 2008 16:33:53 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=MK273HR51yBXsUssSXLPtxelWZ0=; b=rkMWcxWsERN91d98ycO8yO/H2OQJ7Dnqdppk1kieUtHNnPXyud8Zyc0FiAecAWzubcxlN2Ygh5rdNXFgnvH4K01jaNtybeSoGJbl5aU0ougaP0mZCptndV6iWM/r2LJJqvOFVXzxfHj3ruaeB84PKjZpzJZKrGHFEsdlxeUF8i4= Received: by wes.hardakers.net (Postfix, from userid 274) id 3A178399C50; Mon, 7 Apr 2008 16:33:53 -0700 (PDT) From: Wes Hardaker To: "Ersue\, Mehmet \(NSN - DE\/Muenich\)" Organization: Sparta References: Date: Mon, 07 Apr 2008 16:33:53 -0700 In-Reply-To: (Mehmet Ersue's message of "Wed, 2 Apr 2008 16:36:02 +0200") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71 and Action Items X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org >>>>> "ME" == Mehmet Ersue writes: ME> => Wes Hardaker: ME> Please post your questions on: ME> - what happens if you copy candidate to running ME> while a partial lock is held? Here's a quick summary about partial vs global commands. Locking is one type of command that has both a global (in the core netconf model) and partial (in the newly proposed partial locking draft). Global commands are those that operate on entire configuration datastores at once. EG, , , , ... It affects the whole configuration datastore or it doesn't. If, when authorization comes along, a netconf user don't have write access to the whole configuration store it's currently undefined as to what happens, though some obvious things are probably apparent (a copy-config by a user with restricted access shouldn't be allowed to change parts of a config being copied TO that they're not authorized to change). Partial ctial commands are those that operate on pieces of a configuration datastore. Examples include and (I don't remember the exact command name for that, unfortunately... That may not be it). In these types commands the user will or will not have the ability to execute the command based on what part of a datastore it's acting upon. IE, a user will be prohibited from partically-locking a part of a datastore it doesn't have the authorization to lock. The trouble comes in when trying to mix these modes. Consider the case where two different operators have different access rights to a particular configuration datastore (if you want an example where this is going to be required for new work, see draft-hardaker-dnsops-name-server-management-reqs-02.txt which documents management requirements for DNS management). If you have two different users (say U1 and U2) that are responsible for separate pieces of the configuration datastore you can run into conflicts between them. If, for example, U1 has the ability to edit only the routing information and U2 only has the ability to edit DNS service configuration then if they're both trying to configure their parts of the system at the same time then everything works just fine as long as they don't use any global commands. EG, if they both partially lock their portions of "running", edit it, and then unlock they'll never see problems. However, if they both partially lock the candidate config, edit it such that there are outstanding changes to both the routing configuration and the DNS service configuration then it's possible neither U1 nor U2 will have access rights to perform the copy-config to actually copy the changes made from the candidate to the running configuration. U1 won't be able to since changes exist in the DNS configuration portion and he doesn't have write access to that portion of the running config, and vice-versa for U2 with respect to the routing configuration. A partial-lock is another form of a partial config and that was my only point in the meeting. It doesn't add new problems, it just compounds the study case. EG, if U2 partially locks the DNS service configuration portion of running then it prevents U1 from performing a copy from candidate to running which blocks U1 from the edit path they wished to take. The only choice is for U1 to do edits only on running (or wait for the partial-lock to be lifted which may be never if mal-intent is involved). ME> - need a matrix that covers the various operations and their ME> interaction That was just a comment that a "nice to have" piece of documentation would be a chart that displayed which commands had what affect on which pieces of the whole system. As new pieces/operations/commands keep getting added to the system it gets more and more complex to study from any perspective, and most importantly, a security perspective. But to be clear I'm not misunderstood: I think partial-locking is a good thing, not a bad thing. I actually think the system would be easier if it disallowed global commands altogether. But that's another story for another day and will only likely caused me to get flamed off the mailing list ;-/ -- Wes Hardaker Sparta, Inc. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ommands are those that operate on pieces of a configuration datastore. Examples include and (I don't remember the exact command name for that, unfortunately... That may not be it). In these types commands the user will or will not have the ability to execute the command based on what part of a datastore it's acting upon. IE, a user will be prohibited from partically-locking a part of a datastore it doesn't have the authorization to lock. The trouble comes in when trying to mix these modes. Consider the case where two different operators have different access rights to a particular configuration datastore (if you want an example where this is going to be required for new work, see draft-hardaker-dnsops-name-server-management-reqs-02.txt which documents management requirements for DNS management). If you have two different users (say U1 and U2) that are responsible for separate pieces of the configuration datastore you can run into conflicts between them. If, for example, U1 has the ability to edit only the routing information and U2 only has the ability to edit DNS service configuration then if they're both trying to configure their parts of the system at the same time then everything works just fine as long as they don't use any global commands. EG, if they both partially lock their portions of "running", edit it, and then unlock they'll never see problems. However, if they both partially lock the candidate config, edit it such that there are outstanding changes to both the routing configuration and the DNS service configuration then it's possible neither U1 nor U2 will have access rights to perform the copy-config to actually copy the changes made from the candidate to the running configuration. U1 won't be able to since changes exist in the DNS configuration portion and he doesn't have write access to that portion of the running config, and vice-versa for U2 with respect to the routing configuration. A partial-lock is another form of a partial config and that was my only point in the meeting. It doesn't add new problems, it just compounds the study case. EG, if U2 partially locks the DNS service configuration portion of running then it prevents U1 from performing a copy from candidate to running which blocks U1 from the edit path they wished to take. The only choice is for U1 to do edits only on running (or wait for the partial-lock to be lifted which may be never if mal-intent is involved). ME> - need a matrix that covers the various operations and their ME> interaction That was just a comment that a "nice to have" piece of documentation would be a chart that displayed which commands had what affect on which pieces of the whole system. As new pieces/operations/commands keep getting added to the system it gets more and more complex to study from any perspective, and most importantly, a security perspective. But to be clear I'm not misunderstood: I think partial-locking is a good thing, not a bad thing. I actually think the system would be easier if it disallowed global commands altogether. But that's another story for another day and will only likely caused me to get flamed off the mailing list ;-/ -- Wes Hardaker Sparta, Inc. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 9 12:03:02 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1B3828C1E6; Wed, 9 Apr 2008 12:03:01 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D82C03A6E6C for ; Wed, 9 Apr 2008 12:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNxV7j5uASw1 for ; Wed, 9 Apr 2008 12:02:59 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id EF5833A6F10 for ; Wed, 9 Apr 2008 12:02:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=GSTum7SCRm3jIvoqr+DOEDC/s9CLcFAIl0EDvDE3PJWzeofYUHblFzCI4VvGggHC; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.78.232] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JjfZg-0006Qe-B6 for netconf@ietf.org; Wed, 09 Apr 2008 15:03:12 -0400 Message-ID: <001b01c89a6c$0c8a6100$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: Date: Wed, 9 Apr 2008 12:03:42 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117a5632b975b5b779b0dc56c779bd37e60350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.78.232 Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71 andAction Items X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi - > From: "Wes Hardaker" > To: "Ersue, Mehmet (NSN - DE/Muenich)" > Cc: > Sent: Monday, April 07, 2008 5:33 PM > Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71 andAction Items ... > But to be clear I'm not misunderstood: I think partial-locking is a good > thing, not a bad thing. Agree. > I actually think the system would be easier if > it disallowed global commands altogether. .... Although one can think of global locks as simply being pathologically large partial locks. But I agree that the system design is probably much simpler if one starts from the outset assuming the need for partial locks. Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 9 12:03:02 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1B3828C1E6; Wed, 9 Apr 2008 12:03:01 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D82C03A6E6C for ; Wed, 9 Apr 2008 12:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNxV7j5uASw1 for ; Wed, 9 Apr 2008 12:02:59 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id EF5833A6F10 for ; Wed, 9 Apr 2008 12:02:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=GSTum7SCRm3jIvoqr+DOEDC/s9CLcFAIl0EDvDE3PJWzeofYUHblFzCI4VvGggHC; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.78.232] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JjfZg-0006Qe-B6 for netconf@ietf.org; Wed, 09 Apr 2008 15:03:12 -0400 Message-ID: <001b01c89a6c$0c8a6100$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: Date: Wed, 9 Apr 2008 12:03:42 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117a5632b975b5b779b0dc56c779bd37e60350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.78.232 Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71 andAction Items X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi - > From: "Wes Hardaker" > To: "Ersue, Mehmet (NSN - DE/Muenich)" > Cc: > Sent: Monday, April 07, 2008 5:33 PM > Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71 andAction Items ... > But to be clear I'm not misunderstood: I think partial-locking is a good > thing, not a bad thing. Agree. > I actually think the system would be easier if > it disallowed global commands altogether. .... Although one can think of global locks as simply being pathologically large partial locks. But I agree that the system design is probably much simpler if one starts from the outset assuming the need for partial locks. Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Apr 10 06:36:06 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14ABF3A6F1A; Thu, 10 Apr 2008 06:36:06 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C4AF3A6F1A for ; Thu, 10 Apr 2008 06:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmNckuaIal9s for ; Thu, 10 Apr 2008 06:35:55 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 98A1F3A6F21 for ; Thu, 10 Apr 2008 06:35:10 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id DAAFF2C3D08; Thu, 10 Apr 2008 06:34:58 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=AwiysaPdeGPmAn7cSeTNNQz6Tp0=; b=C2iB1ZFAIw5kZ0V4+hPUJ2szNNfibxZzWCBZJJuwJonEx6zLU5ysygQl3ryKjEwifKmnozot/9Ue1FUS3+F47a953YxPVCM9TqOX9SfyFwQIivGBB95m6Tef1Wxmz7HBDNk+dmrHaMBbb8JZt8s5KFEWTiYinRsYBUgwYRvb4IY= Received: by wes.hardakers.net (Postfix, from userid 274) id C04412C3D07; Thu, 10 Apr 2008 06:34:58 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" Organization: Sparta References: <001b01c89a6c$0c8a6100$6801a8c0@oemcomputer> Date: Thu, 10 Apr 2008 06:34:58 -0700 In-Reply-To: <001b01c89a6c$0c8a6100$6801a8c0@oemcomputer> (Randy Presuhn's message of "Wed, 9 Apr 2008 12:03:42 -0600") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71 andAction Items X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org >>>>> "RP" == Randy Presuhn writes: >> I actually think the system would be easier if >> it disallowed global commands altogether. RP> .... RP> Although one can think of global locks as simply being RP> pathologically large partial locks. But I agree that the RP> system design is probably much simpler if one starts RP> from the outset assuming the need for partial locks. I meant all global commands though. The problem with global commands (like copy-config, not just lock) is that they have to be able to pseudo-operate on sections of the config that aren't supposed to be edited by a given user. Fortunately, if a copy-config contains the exact same config as what's installed you can pseudo-allow it to complete. But if it doesn't (say somethings changed somewhere else since you grabbed your reference copy to edit) then it: 1) the copy-config From netconf-bounces@ietf.org Thu Apr 10 06:36:06 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14ABF3A6F1A; Thu, 10 Apr 2008 06:36:06 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C4AF3A6F1A for ; Thu, 10 Apr 2008 06:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmNckuaIal9s for ; Thu, 10 Apr 2008 06:35:55 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 98A1F3A6F21 for ; Thu, 10 Apr 2008 06:35:10 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id DAAFF2C3D08; Thu, 10 Apr 2008 06:34:58 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=AwiysaPdeGPmAn7cSeTNNQz6Tp0=; b=C2iB1ZFAIw5kZ0V4+hPUJ2szNNfibxZzWCBZJJuwJonEx6zLU5ysygQl3ryKjEwifKmnozot/9Ue1FUS3+F47a953YxPVCM9TqOX9SfyFwQIivGBB95m6Tef1Wxmz7HBDNk+dmrHaMBbb8JZt8s5KFEWTiYinRsYBUgwYRvb4IY= Received: by wes.hardakers.net (Postfix, from userid 274) id C04412C3D07; Thu, 10 Apr 2008 06:34:58 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" Organization: Sparta References: <001b01c89a6c$0c8a6100$6801a8c0@oemcomputer> Date: Thu, 10 Apr 2008 06:34:58 -0700 In-Reply-To: <001b01c89a6c$0c8a6100$6801a8c0@oemcomputer> (Randy Presuhn's message of "Wed, 9 Apr 2008 12:03:42 -0600") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71 andAction Items X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org >>>>> "RP" == Randy Presuhn writes: >> I actually think the system would be easier if >> it disallowed global commands altogether. RP> .... RP> Although one can think of global locks as simply being RP> pathologically large partial locks. But I agree that the RP> system design is probably much simpler if one starts RP> from the outset assuming the need for partial locks. I meant all global commands though. The problem with global commands (like copy-config, not just lock) is that they have to be able to pseudo-operate on sections of the config that aren't supposed to be edited by a given user. Fortunately, if a copy-config contains the exact same config as what's installed you can pseudo-allow it to complete. But if it doesn't (say somethings changed somewhere else since you grabbed your reference copy to edit) then it: 1) the copy-cwill fail because you don't have authorization. 2) if you do have authorization, you'll just have wiped out someone else's changes that occurred since you grabbed your reference copy Only using edit-config and partial operations is a much safer way to go. -- Wes Hardaker Sparta, Inc. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf onfig will fail because you don't have authorization. 2) if you do have authorization, you'll just have wiped out someone else's changes that occurred since you grabbed your reference copy Only using edit-config and partial operations is a much safer way to go. -- Wes Hardaker Sparta, Inc. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Apr 10 08:56:35 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D34F3A6B8B; Thu, 10 Apr 2008 08:56:35 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D737E3A6B2A for ; Thu, 10 Apr 2008 08:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96yFlyu1CoOD for ; Thu, 10 Apr 2008 08:56:29 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 2D18428C1AC for ; Thu, 10 Apr 2008 08:56:29 -0700 (PDT) X-Trace: 3449265/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.135.203 X-SBRS: None X-RemoteIP: 62.188.135.203 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAPjU/Uc+vIfL/2dsb2JhbACLPqAsBA X-IP-Direction: IN Received: from 1cust203.tnt6.lnd4.gbr.da.uu.net (HELO allison) ([62.188.135.203]) by smtp.pipex.tiscali.co.uk with SMTP; 10 Apr 2008 16:56:46 +0100 Message-ID: <03b001c89b1a$975f0160$0601a8c0@allison> From: "tom.petch" To: "Bert Wijnen - IETF" , "Sharon Chisholm" , "Hector Trevino \(htrevino\)" References: Date: Thu, 10 Apr 2008 14:58:58 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: Netconf Subject: Re: [Netconf] FW: DISCUSS and COMMENT: draft-ietf-netconf-notification X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Bottom posting Tom Petch ----- Original Message ----- From: "Bert Wijnen - IETF" To: "Sharon Chisholm" ; "Hector Trevino (htrevino)" Cc: "Netconf" Sent: Friday, March 28, 2008 1:18 AM Subject: [Netconf] FW: DISCUSS and COMMENT: draft-ietf-netconf-notification > OK, so I propose this is one thing to be fixed by the authors > (together with the otehr things that need fixing). > > Bert Wijnen > > -----Oorspronkelijk bericht----- > Van: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Verzonden: donderdag 27 maart 2008 20:55 > Aan: Sharon Chisholm; Pasi Eronen; iesg@ietf.org > CC: htrevino@cisco.com; draft-ietf-netconf-notification@tools.ietf.org; > netconf-chairs@tools.ietf.org; bertietf@bwijnen.net > Onderwerp: RE: DISCUSS and COMMENT: draft-ietf-netconf-notification > > > From the argumentation that Pasi made in the telechat, it looks like the > practice of referring schemas with URLs is not used in RFCs, as it leads > to potentially high traffic on servers. Specifically Pasi wrote the > following: > > ------------------ > > To give more background: a very long time ago, W3C decided to use http > URIs for HTML DTD/schema names; today, they're seeing "up to 130 million > requests per day, with periods of sustained bandwidth usage of 350Mbps": > > http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic > > In the case of netconf-notification, there's doesn't seem to be any > advantage in using http URIs (compared to the "urn:ietf:params:xml:..." > URNs that all current RFCs > use): no valid NETCONF implementation will ever need to download the > schema from IANA. Therefore, I don't think we should take a risk by > trying something totally new here. > > > > -----Original Message----- > > From: iesg-bounces@iesg.org [mailto:iesg-bounces@iesg.org] On > > Behalf Of Sharon Chisholm > > Sent: Thursday, March 27, 2008 9:45 PM > > To: Pasi Eronen; iesg@ietf.org > > Cc: htrevino@cisco.com; > > draft-ietf-netconf-notification@tools.ietf.org; > > netconf-chairs@tools.ietf.org; bertietf@bwijnen.net > > Subject: RE: DISCUSS and COMMENT: draft-ietf-netconf-notification > > > > Hi > > > > I assume you are referring to the following: > > > > > > > schemaLocation= > > > > "http://www.iana.org/assignments/xml-registry/schema/netconf.xsd"/> > > > > > > Is there a specific issue with this? The link works. > > This has seriously challenged my understanding of XSD:-( If this is the fragment that Pasi(?) is referring to, then the namespace name is a urn:, not a http:. schemaLocation is not the namespace name but a hint as to its location, which should be dereferencable so that ftp: or tftp: or ?telnet: would do but the use of urn: seems odd (although that is what EPP, ipfix and IRIS use while ForCES uses http:). Or is he referring to xmlns="http://example.com/event/1.0" just higher up in the I-D? It's an example! Neither make sense to me. And at least the Apps ADs should know that there has been a substantial discussion about http: namespace names leading to draft-duerst-iana-namespace-00.txt which seemed well received and, in the course of discussing which, the question of traffic generated came up, to which Tim Bray responded "Yeah, it's true and it's potentially a problem. In the case of the W3C it's not XML namespace URIs, it's XML DTD system identifiers in the > For expressing the restrictions on stopTime/startTime in the > > XSD, can you propose specific syntax? > > > > Sharon > > > > -----Original Message----- > > From: Pasi Eronen [mailto:pasi.eronen@nokia.com] > > Sent: Thursday, March 27, 2008 9:48 AM > > To: iesg@ietf.org > > Cc: netconf-chairs@tools.ietf.org; > > draft-ietf-netconf-notification@tools.ietf.org; Chisholm, > > Sharon (CAR:ZZ00); htrevino@cisco.com; bertietf@bwijnen.net > > Subject: DISCUSS and COMMENT: draft-ietf-netconf-notification > > > > Discuss: > > The schema "import" statements have HTTP URLs pointing to > > www.iana.org. > > I don't think any IETF XML schema has done this before? > > > > Comment: > > The restrictions "[replayLogCreationTime] MUST be present if > > replay is supported" could be expressed in XML schema, > > instead of just documentation. Ditto for "[stopTime] must be > > used with startTime". > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Apr 10 08:56:35 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D34F3A6B8B; Thu, 10 Apr 2008 08:56:35 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D737E3A6B2A for ; Thu, 10 Apr 2008 08:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96yFlyu1CoOD for ; Thu, 10 Apr 2008 08:56:29 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 2D18428C1AC for ; Thu, 10 Apr 2008 08:56:29 -0700 (PDT) X-Trace: 3449265/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.135.203 X-SBRS: None X-RemoteIP: 62.188.135.203 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAPjU/Uc+vIfL/2dsb2JhbACLPqAsBA X-IP-Direction: IN Received: from 1cust203.tnt6.lnd4.gbr.da.uu.net (HELO allison) ([62.188.135.203]) by smtp.pipex.tiscali.co.uk with SMTP; 10 Apr 2008 16:56:46 +0100 Message-ID: <03b001c89b1a$975f0160$0601a8c0@allison> From: "tom.petch" To: "Bert Wijnen - IETF" , "Sharon Chisholm" , "Hector Trevino \(htrevino\)" References: Date: Thu, 10 Apr 2008 14:58:58 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: Netconf Subject: Re: [Netconf] FW: DISCUSS and COMMENT: draft-ietf-netconf-notification X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Bottom posting Tom Petch ----- Original Message ----- From: "Bert Wijnen - IETF" To: "Sharon Chisholm" ; "Hector Trevino (htrevino)" Cc: "Netconf" Sent: Friday, March 28, 2008 1:18 AM Subject: [Netconf] FW: DISCUSS and COMMENT: draft-ietf-netconf-notification > OK, so I propose this is one thing to be fixed by the authors > (together with the otehr things that need fixing). > > Bert Wijnen > > -----Oorspronkelijk bericht----- > Van: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Verzonden: donderdag 27 maart 2008 20:55 > Aan: Sharon Chisholm; Pasi Eronen; iesg@ietf.org > CC: htrevino@cisco.com; draft-ietf-netconf-notification@tools.ietf.org; > netconf-chairs@tools.ietf.org; bertietf@bwijnen.net > Onderwerp: RE: DISCUSS and COMMENT: draft-ietf-netconf-notification > > > From the argumentation that Pasi made in the telechat, it looks like the > practice of referring schemas with URLs is not used in RFCs, as it leads > to potentially high traffic on servers. Specifically Pasi wrote the > following: > > ------------------ > > To give more background: a very long time ago, W3C decided to use http > URIs for HTML DTD/schema names; today, they're seeing "up to 130 million > requests per day, with periods of sustained bandwidth usage of 350Mbps": > > http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic > > In the case of netconf-notification, there's doesn't seem to be any > advantage in using http URIs (compared to the "urn:ietf:params:xml:..." > URNs that all current RFCs > use): no valid NETCONF implementation will ever need to download the > schema from IANA. Therefore, I don't think we should take a risk by > trying something totally new here. > > > > -----Original Message----- > > From: iesg-bounces@iesg.org [mailto:iesg-bounces@iesg.org] On > > Behalf Of Sharon Chisholm > > Sent: Thursday, March 27, 2008 9:45 PM > > To: Pasi Eronen; iesg@ietf.org > > Cc: htrevino@cisco.com; > > draft-ietf-netconf-notification@tools.ietf.org; > > netconf-chairs@tools.ietf.org; bertietf@bwijnen.net > > Subject: RE: DISCUSS and COMMENT: draft-ietf-netconf-notification > > > > Hi > > > > I assume you are referring to the following: > > > > > > > schemaLocation= > > > > "http://www.iana.org/assignments/xml-registry/schema/netconf.xsd"/> > > > > > > Is there a specific issue with this? The link works. > > This has seriously challenged my understanding of XSD:-( If this is the fragment that Pasi(?) is referring to, then the namespace name is a urn:, not a http:. schemaLocation is not the namespace name but a hint as to its location, which should be dereferencable so that ftp: or tftp: or ?telnet: would do but the use of urn: seems odd (although that is what EPP, ipfix and IRIS use while ForCES uses http:). Or is he referring to xmlns="http://example.com/event/1.0" just higher up in the I-D? It's an example! Neither make sense to me. And at least the Apps ADs should know that there has been a substantial discussion about http: namespace names leading to draft-duerst-iana-namespace-00.txt which seemed well received and, in the course of discussing which, the question of traffic generated came up, to which Tim Bray responded "Yeah, it's true and it's potentially a problem. In the case of the W3C it's not XML namespace URIs, it's XML DTD system identifiers in the > For expressing the restrictions on stopTime/startTime in the > > XSD, can you propose specific syntax? > > > > Sharon > > > > -----Original Message----- > > From: Pasi Eronen [mailto:pasi.eronen@nokia.com] > > Sent: Thursday, March 27, 2008 9:48 AM > > To: iesg@ietf.org > > Cc: netconf-chairs@tools.ietf.org; > > draft-ietf-netconf-notification@tools.ietf.org; Chisholm, > > Sharon (CAR:ZZ00); htrevino@cisco.com; bertietf@bwijnen.net > > Subject: DISCUSS and COMMENT: draft-ietf-netconf-notification > > > > Discuss: > > The schema "import" statements have HTTP URLs pointing to > > www.iana.org. > > I don't think any IETF XML schema has done this before? > > > > Comment: > > The restrictions "[replayLogCreationTime] MUST be present if > > replay is supported" could be expressed in XML schema, > > instead of just documentation. Ditto for "[stopTime] must be > > used with startTime". > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Apr 10 11:04:23 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3FD3A6D5B; Thu, 10 Apr 2008 11:04:23 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C98E3A6D5B for ; Thu, 10 Apr 2008 11:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fldbZjlsaMq for ; Thu, 10 Apr 2008 11:04:19 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id D820A3A6D2E for ; Thu, 10 Apr 2008 11:04:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=J921WY2FAp/rdKI+N4/yGyr/f7JaApjV493RsguGwiwykzPsAXEETjyVoAW4Xhi0; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.6.189] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Jk18Z-0007qr-MU for netconf@ietf.org; Thu, 10 Apr 2008 14:04:40 -0400 Message-ID: <001a01c89b2d$0a6e6620$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <001b01c89a6c$0c8a6100$6801a8c0@oemcomputer> Date: Thu, 10 Apr 2008 11:05:11 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117e548addbf4e2ce1ae9525971cd4e9daa350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.6.189 Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71 andAction Items X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi - > From: "Wes Hardaker" > To: "Randy Presuhn" > Cc: > Sent: Thursday, April 10, 2008 7:34 AM > Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71 andAction Items ... > I meant all global commands though. The problem with global commands > (like copy-config, not just lock) is that they have to be able to > pseudo-operate on sections of the config that aren't supposed to be > edited by a given user. Fortunately, if a copy-config contains the > exact same config as what's installed you can pseudo-allow it to > complete. But if it doesn't (say somethings changed somewhere else > since you grabbed your reference copy to edit) then it: > > 1) the copy-config will fail because you don't have authorization. > 2) if you do have authorization, you'll just have wiped out someone > else's changes that occurred siFrom netconf-bounces@ietf.org Thu Apr 10 11:04:23 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3FD3A6D5B; Thu, 10 Apr 2008 11:04:23 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C98E3A6D5B for ; Thu, 10 Apr 2008 11:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fldbZjlsaMq for ; Thu, 10 Apr 2008 11:04:19 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id D820A3A6D2E for ; Thu, 10 Apr 2008 11:04:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=J921WY2FAp/rdKI+N4/yGyr/f7JaApjV493RsguGwiwykzPsAXEETjyVoAW4Xhi0; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.6.189] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Jk18Z-0007qr-MU for netconf@ietf.org; Thu, 10 Apr 2008 14:04:40 -0400 Message-ID: <001a01c89b2d$0a6e6620$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <001b01c89a6c$0c8a6100$6801a8c0@oemcomputer> Date: Thu, 10 Apr 2008 11:05:11 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117e548addbf4e2ce1ae9525971cd4e9daa350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.6.189 Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71 andAction Items X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi - > From: "Wes Hardaker" > To: "Randy Presuhn" > Cc: > Sent: Thursday, April 10, 2008 7:34 AM > Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71 andAction Items ... > I meant all global commands though. The problem with global commands > (like copy-config, not just lock) is that they have to be able to > pseudo-operate on sections of the config that aren't supposed to be > edited by a given user. Fortunately, if a copy-config contains the > exact same config as what's installed you can pseudo-allow it to > complete. But if it doesn't (say somethings changed somewhere else > since you grabbed your reference copy to edit) then it: > > 1) the copy-config will fail because you don't have authorization. > 2) if you do have authorization, you'll just have wiped out someone > else's changes that occurnce you grabbed your reference copy > > Only using edit-config and partial operations is a much safer way to go. ... We're in agreement. But I think there's a bit more to the problem. If you think about the problem space as *network* configuration management (and not merely device configuration management), it becomes clear that the "global" commands just get a piece of the network's configuration. But we're on the path to re-inventing ISO 11587:1996, and I don't think we want that particular camel in this tent. :-) Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf red since you grabbed your reference copy > > Only using edit-config and partial operations is a much safer way to go. ... We're in agreement. But I think there's a bit more to the problem. If you think about the problem space as *network* configuration management (and not merely device configuration management), it becomes clear that the "global" commands just get a piece of the network's configuration. But we're on the path to re-inventing ISO 11587:1996, and I don't think we want that particular camel in this tent. :-) Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Apr 10 19:50:30 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D769C3A6D0D; Thu, 10 Apr 2008 19:50:30 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4763F3A6E06 for ; Thu, 10 Apr 2008 19:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.317 X-Spam-Level: X-Spam-Status: No, score=-6.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lc1aNog81cnn for ; Thu, 10 Apr 2008 19:50:28 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 4FDF43A6BF9 for ; Thu, 10 Apr 2008 19:50:06 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Thu, 10 Apr 2008 19:50:27 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 19:50:21 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m3B2oJD99529; Thu, 10 Apr 2008 19:50:19 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m3B2mlVw069712; Fri, 11 Apr 2008 02:48:47 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200804110248.m3B2mlVw069712@idle.juniper.net> To: "tom.petch" In-reply-to: <03b001c89b1a$975f0160$0601a8c0@allison> Date: Thu, 10 Apr 2008 22:48:46 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 Apr 2008 02:50:21.0519 (UTC) FILETIME=[C8AF85F0:01C89B7E] Cc: Netconf Subject: Re: [Netconf] FW: DISCUSS and COMMENT: draft-ietf-netconf-notification X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org >> From the argumentation that Pasi made in the telechat, it looks like the >> practice of referring schemas with URLs is not used in RFCs, as it leads >> to potentially high traffic on servers. Specifically Pasi wrote the >> following: >> >> ------------------ >> >> To give more background: a very long time ago, W3C decided to use http >> URIs for HTML DTD/schema names; today, they're seeing "up to 130 million >> requests per day, with periods of sustained bandwidth usage of 350Mbps": >> >> http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic >> >> In the case of netconf-notification, there's doesn't seem to be any >> advantage in using http URIs (compared to the "urn:ietf:params:xml:..." >> URNs that all current RFCs >> use): no valid NETCONF implementation will ever need to download the >> schema from IANA. Therefore, I don't think we should take a risk by >> trying something totally new here. Pasi is mixing two different issues. The w3 issues was DTDs, which are concrete things and should be retrievable. Moronic application fetching the xhtml dtd east w3c bandwidth. Namespace URI are not concrete things, are not retrievable and won't eat bandwidth. There is no risk here. Not that there's any strong reaons for this to diverge from the URN style we used in the original NETCONF spec. Mixing the two seems strange. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Apr 10 19:50:30 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D769C3A6D0D; Thu, 10 Apr 2008 19:50:30 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4763F3A6E06 for ; Thu, 10 Apr 2008 19:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.317 X-Spam-Level: X-Spam-Status: No, score=-6.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lc1aNog81cnn for ; Thu, 10 Apr 2008 19:50:28 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 4FDF43A6BF9 for ; Thu, 10 Apr 2008 19:50:06 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Thu, 10 Apr 2008 19:50:27 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 19:50:21 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m3B2oJD99529; Thu, 10 Apr 2008 19:50:19 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m3B2mlVw069712; Fri, 11 Apr 2008 02:48:47 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200804110248.m3B2mlVw069712@idle.juniper.net> To: "tom.petch" In-reply-to: <03b001c89b1a$975f0160$0601a8c0@allison> Date: Thu, 10 Apr 2008 22:48:46 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 Apr 2008 02:50:21.0519 (UTC) FILETIME=[C8AF85F0:01C89B7E] Cc: Netconf Subject: Re: [Netconf] FW: DISCUSS and COMMENT: draft-ietf-netconf-notification X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org >> From the argumentation that Pasi made in the telechat, it looks like the >> practice of referring schemas with URLs is not used in RFCs, as it leads >> to potentially high traffic on servers. Specifically Pasi wrote the >> following: >> >> ------------------ >> >> To give more background: a very long time ago, W3C decided to use http >> URIs for HTML DTD/schema names; today, they're seeing "up to 130 million >> requests per day, with periods of sustained bandwidth usage of 350Mbps": >> >> http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic >> >> In the case of netconf-notification, there's doesn't seem to be any >> advantage in using http URIs (compared to the "urn:ietf:params:xml:..." >> URNs that all current RFCs >> use): no valid NETCONF implementation will ever need to download the >> schema from IANA. Therefore, I don't think we should take a risk by >> trying something totally new here. Pasi is mixing two different issues. The w3 issues was DTDs, which are concrete things and should be retrievable. Moronic application fetching the xhtml dtd east w3c bandwidth. Namespace URI are not concrete things, are not retrievable and won't eat bandwidth. There is no risk here. Not that there's any strong reaons for this to diverge from the URN style we used in the original NETCONF spec. Mixing the two seems strange. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 11 01:48:09 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2F8D28C109; Fri, 11 Apr 2008 01:48:09 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15F3E3A6E3F for ; Fri, 11 Apr 2008 01:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[AWL=0.728, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKpQ9I-2cxwm for ; Fri, 11 Apr 2008 01:48:07 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id E4BB33A6C1D for ; Fri, 11 Apr 2008 01:48:06 -0700 (PDT) X-Trace: 3999921/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.139.116 X-SBRS: None X-RemoteIP: 62.188.139.116 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgFACvD/kc+vIt0/2dsb2JhbABDinugZAQ X-IP-Direction: IN Received: from 1cust116.tnt10.lnd4.gbr.da.uu.net (HELO allison) ([62.188.139.116]) by smtp.pipex.tiscali.co.uk with SMTP; 11 Apr 2008 09:48:26 +0100 Message-ID: <000401c89ba7$eae3cae0$0601a8c0@allison> From: "tom.petch" To: "Sharon Chisholm" , "Phil Shafer" References: <713043CE8B8E1348AF3C546DBE02C1B413E7A825@zcarhxm2.corp.nortel.com><200804041926.m34JQcYk085662@idle.juniper.net> <713043CE8B8E1348AF3C546DBE02C1B413E7AF64@zcarhxm2.corp.nortel.com> Date: Thu, 10 Apr 2008 17:40:39 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This can of worms has been opened by W3C in http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ s3.2.7 and especially 3.2.7.4. They cover the cases of time zones present and not present, and if the end results are not magically helpful, then I think that the same applies to any other proposal. But I do think that we should use their work as a basis and have good reason for departing from it. It is more likely to be what others expect and what XML tools provide. Tom Petch ----- Original Message ----- From: "Sharon Chisholm" To: "Phil Shafer" Cc: Sent: Monday, April 07, 2008 3:11 PM Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime > Hi > > Good question. I'm going to assume here that if we do this we do it for > all three of our dateTime elements for consistency. I think there are > two cases > 1) Not specified by client in a or but > supported on the NE, then the default time zone of the box is assumed > 2) Not configured on the box. Then I don't think there is actually a > workaround. This would be a non-compliant device. > > Note that if we don't do this we need to answer the issues raised in > http://tools.ietf.org/html/rfc3339#section-4.4 > > Sharon > > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net] > Sent: Friday, April 04, 2008 3:27 PM > To: Chisholm, Sharon (CAR:ZZ00) > Cc: netconf@ietf.org > Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime > > "Sharon Chisholm" writes: > >There are no objections to mandating use of time zone in eventTime? > > What does one use when the time zone is unknown (not configured)? > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 11 01:48:09 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2F8D28C109; Fri, 11 Apr 2008 01:48:09 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15F3E3A6E3F for ; Fri, 11 Apr 2008 01:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[AWL=0.728, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKpQ9I-2cxwm for ; Fri, 11 Apr 2008 01:48:07 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id E4BB33A6C1D for ; Fri, 11 Apr 2008 01:48:06 -0700 (PDT) X-Trace: 3999921/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.139.116 X-SBRS: None X-RemoteIP: 62.188.139.116 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgFACvD/kc+vIt0/2dsb2JhbABDinugZAQ X-IP-Direction: IN Received: from 1cust116.tnt10.lnd4.gbr.da.uu.net (HELO allison) ([62.188.139.116]) by smtp.pipex.tiscali.co.uk with SMTP; 11 Apr 2008 09:48:26 +0100 Message-ID: <000401c89ba7$eae3cae0$0601a8c0@allison> From: "tom.petch" To: "Sharon Chisholm" , "Phil Shafer" References: <713043CE8B8E1348AF3C546DBE02C1B413E7A825@zcarhxm2.corp.nortel.com><200804041926.m34JQcYk085662@idle.juniper.net> <713043CE8B8E1348AF3C546DBE02C1B413E7AF64@zcarhxm2.corp.nortel.com> Date: Thu, 10 Apr 2008 17:40:39 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This can of worms has been opened by W3C in http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ s3.2.7 and especially 3.2.7.4. They cover the cases of time zones present and not present, and if the end results are not magically helpful, then I think that the same applies to any other proposal. But I do think that we should use their work as a basis and have good reason for departing from it. It is more likely to be what others expect and what XML tools provide. Tom Petch ----- Original Message ----- From: "Sharon Chisholm" To: "Phil Shafer" Cc: Sent: Monday, April 07, 2008 3:11 PM Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime > Hi > > Good question. I'm going to assume here that if we do this we do it for > all three of our dateTime elements for consistency. I think there are > two cases > 1) Not specified by client in a or but > supported on the NE, then the default time zone of the box is assumed > 2) Not configured on the box. Then I don't think there is actually a > workaround. This would be a non-compliant device. > > Note that if we don't do this we need to answer the issues raised in > http://tools.ietf.org/html/rfc3339#section-4.4 > > Sharon > > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net] > Sent: Friday, April 04, 2008 3:27 PM > To: Chisholm, Sharon (CAR:ZZ00) > Cc: netconf@ietf.org > Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime > > "Sharon Chisholm" writes: > >There are no objections to mandating use of time zone in eventTime? > > What does one use when the time zone is unknown (not configured)? > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 11 06:16:35 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDC0A3A6AB6; Fri, 11 Apr 2008 06:16:35 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B22943A6AA1 for ; Fri, 11 Apr 2008 06:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyQAkA0MAOnY for ; Fri, 11 Apr 2008 06:16:33 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id B32E23A6AB6 for ; Fri, 11 Apr 2008 06:16:33 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id E513639A26C; Fri, 11 Apr 2008 06:16:12 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=pSVWuLVJhIE1u7xa5Mi7Lwg5XMo=; b=M0Vkqp3rXfyhMzJcGS6+W22NcnPu53IotiWsVDfPhzwFBaNqJYX9HLSG5nHA+StRPC+lp8SnxGPLkKbw8HT9VPXw/0nGxPiNWF02ws71GTjU1opQvDgoDTFI82eTlV3nAqedumNlxqRcHbw8rBB5f3qHiedbXq9SHj0fiKNL+EA= Received: by wes.hardakers.net (Postfix, from userid 274) id 9CD5C2C3222; Fri, 11 Apr 2008 06:16:12 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" Organization: Sparta References: <001b01c89a6c$0c8a6100$6801a8c0@oemcomputer> <001a01c89b2d$0a6e6620$6801a8c0@oemcomputer> Date: Fri, 11 Apr 2008 06:16:12 -0700 In-Reply-To: <001a01c89b2d$0a6e6620$6801a8c0@oemcomputer> (Randy Presuhn's message of "Thu, 10 Apr 2008 11:05:11 -0600") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71 andAction Items X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org >>>>> "RP" == Randy Presuhn writes: RP> But we're on the path to re-inventing ISO 11587:1996, and I don't RP> think we want that particular camel in this tent. :-) Then we'll be sure to call it a elephant instead so it's not a problem this time. -- Wes Hardaker Sparta, Inc. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 11 06:16:35 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDC0A3A6AB6; Fri, 11 Apr 2008 06:16:35 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B22943A6AA1 for ; Fri, 11 Apr 2008 06:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyQAkA0MAOnY for ; Fri, 11 Apr 2008 06:16:33 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id B32E23A6AB6 for ; Fri, 11 Apr 2008 06:16:33 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id E513639A26C; Fri, 11 Apr 2008 06:16:12 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=pSVWuLVJhIE1u7xa5Mi7Lwg5XMo=; b=M0Vkqp3rXfyhMzJcGS6+W22NcnPu53IotiWsVDfPhzwFBaNqJYX9HLSG5nHA+StRPC+lp8SnxGPLkKbw8HT9VPXw/0nGxPiNWF02ws71GTjU1opQvDgoDTFI82eTlV3nAqedumNlxqRcHbw8rBB5f3qHiedbXq9SHj0fiKNL+EA= Received: by wes.hardakers.net (Postfix, from userid 274) id 9CD5C2C3222; Fri, 11 Apr 2008 06:16:12 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" Organization: Sparta References: <001b01c89a6c$0c8a6100$6801a8c0@oemcomputer> <001a01c89b2d$0a6e6620$6801a8c0@oemcomputer> Date: Fri, 11 Apr 2008 06:16:12 -0700 In-Reply-To: <001a01c89b2d$0a6e6620$6801a8c0@oemcomputer> (Randy Presuhn's message of "Thu, 10 Apr 2008 11:05:11 -0600") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71 andAction Items X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org >>>>> "RP" == Randy Presuhn writes: RP> But we're on the path to re-inventing ISO 11587:1996, and I don't RP> think we want that particular camel in this tent. :-) Then we'll be sure to call it a elephant instead so it's not a problem this time. -- Wes Hardaker Sparta, Inc. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Apr 12 06:17:30 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE8A28C21E; Sat, 12 Apr 2008 06:17:30 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77FE83A6D81 for ; Sat, 12 Apr 2008 06:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.157 X-Spam-Level: X-Spam-Status: No, score=-5.157 tagged_above=-999 required=5 tests=[AWL=1.441, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SN0pj00kTB1k for ; Sat, 12 Apr 2008 06:17:28 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 123263A69C7 for ; Sat, 12 Apr 2008 06:17:24 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m3CDHiCY007169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Apr 2008 15:17:45 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m3CDHiU5024476; Sat, 12 Apr 2008 15:17:44 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 12 Apr 2008 15:17:44 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Date: Sat, 12 Apr 2008 15:17:41 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Official minutes of the Netconf session at IETF 71 Thread-Index: AciQH4xZE3IGYmtEStu5MRTiDeeJswMf2cuw References: From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 12 Apr 2008 13:17:44.0389 (UTC) FILETIME=[97FF6750:01C89C9F] Subject: [Netconf] Official minutes of the Netconf session at IETF 71 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0981322568==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0981322568== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89C9F.97D1488F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89C9F.97D1488F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 we submitted the official minutes of the IETF 71 NETCONF=20 session to the meeting materials site. =20 https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf =20 Thank you to Dave H. for his comments. Cheers, Mehmet=20 =20 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Muenich) Sent: Thursday, March 27, 2008 4:31 PM To: netconf@ietf.org SubjeFrom netconf-bounces@ietf.org Sat Apr 12 06:17:30 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE8A28C21E; Sat, 12 Apr 2008 06:17:30 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77FE83A6D81 for ; Sat, 12 Apr 2008 06:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.157 X-Spam-Level: X-Spam-Status: No, score=-5.157 tagged_above=-999 required=5 tests=[AWL=1.441, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SN0pj00kTB1k for ; Sat, 12 Apr 2008 06:17:28 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 123263A69C7 for ; Sat, 12 Apr 2008 06:17:24 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m3CDHiCY007169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Apr 2008 15:17:45 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m3CDHiU5024476; Sat, 12 Apr 2008 15:17:44 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 12 Apr 2008 15:17:44 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Date: Sat, 12 Apr 2008 15:17:41 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Official minutes of the Netconf session at IETF 71 Thread-Index: AciQH4xZE3IGYmtEStu5MRTiDeeJswMf2cuw References: From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 12 Apr 2008 13:17:44.0389 (UTC) FILETIME=[97FF6750:01C89C9F] Subject: [Netconf] Official minutes of the Netconf session at IETF 71 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0981322568==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0981322568== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89C9F.97D1488F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89C9F.97D1488F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 we submitted the official minutes of the IETF 71 NETCONF=20 session to the meeting materials site. =20 https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf =20 Thank you to Dave H. for his comments. Cheers, Mehmet=20 =20 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Muenich) Sent: Thursday, March 27, 2008 4:31 PM To: netconf@ietf.org ct: [Netconf] Netconf session at IETF 71 - Preliminary minutes =09 =09 Hi All,=20 attached are the draft minutes we have merged so far=20 from the notes of the minute takers (many thanks again=20 to David P. and Juergen for taking notes!! :).=20 <>=20 Please send us your change requests or corrections=20 by 10th of April. I'll put it also the meeting materials=20 site as the preliminary version.=20 Thank you.=20 Bert & Mehmet=20 ------_=_NextPart_001_01C89C9F.97D1488F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Netconf session at IETF 71 - Preliminary = minutes
Hi All,
 
we submitted the official minutes of the IETF = 71 NETCONF=20
session to the meeting=20 materials site.
 
https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf
 
Thank you to Dave H. for his=20 comments.

Cheers,
Mehmet

 

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, = Mehmet (NSN -=20 DE/Muenich)
Sent: Thursday, March 27, 2008 4:31 = PM
To:=20 netconf@ietf.org
Subject: [Netconf] Netconf session at IETF = 71 -=20 Preliminary minutes


Hi All,

attached are the draft minutes we = have merged so=20 far
from the notes of the = minute takers=20 (many thanks again
to David = P. and=20 Juergen for taking notes!! :).

<<Netconf_IETF=20 71_Draft_minutes.txt>>

Please send us your change requests = or=20 corrections
by 10th of April. = I'll put it=20 also the meeting materials
site as the=20 preliminary version.

Thank you.

Bert = &=20 Mehmet =

------_=_NextPart_001_01C89C9F.97D1488F-- --===============0981322568== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0981322568==-- Subject: [Netconf] Netconf session at IETF 71 - Preliminary minutes =09 =09 Hi All,=20 attached are the draft minutes we have merged so far=20 from the notes of the minute takers (many thanks again=20 to David P. and Juergen for taking notes!! :).=20 <>=20 Please send us your change requests or corrections=20 by 10th of April. I'll put it also the meeting materials=20 site as the preliminary version.=20 Thank you.=20 Bert & Mehmet=20 ------_=_NextPart_001_01C89C9F.97D1488F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Netconf session at IETF 71 - Preliminary = minutes
Hi All,
 
we submitted the official minutes of the IETF = 71 NETCONF=20
session to the meeting=20 materials site.
 
https://datatracker.ietf.org/meeting/71/materials.html#wg-netconf
 
Thank you to Dave H. for his=20 comments.

Cheers,
Mehmet

 

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, = Mehmet (NSN -=20 DE/Muenich)
Sent: Thursday, March 27, 2008 4:31 = PM
To:=20 netconf@ietf.org
Subject: [Netconf] Netconf session at IETF = 71 -=20 Preliminary minutes


Hi All,

attached are the draft minutes we = have merged so=20 far
from the notes of the = minute takers=20 (many thanks again
to David = P. and=20 Juergen for taking notes!! :).

<<Netconf_IETF=20 71_Draft_minutes.txt>>

Please send us your change requests = or=20 corrections
by 10th of April. = I'll put it=20 also the meeting materials
site as the=20 preliminary version.

Thank you.

Bert = &=20 Mehmet =

------_=_NextPart_001_01C89C9F.97D1488F-- --===============0981322568== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0981322568==-- From netconf-bounces@ietf.org Mon Apr 14 02:56:00 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C02228C0FA; Mon, 14 Apr 2008 02:56:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA9CA3A6A3D for ; Mon, 14 Apr 2008 02:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.253 X-Spam-Level: X-Spam-Status: No, score=-3.253 tagged_above=-999 required=5 tests=[AWL=-0.655, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORDNf64SmSOw for ; Mon, 14 Apr 2008 02:55:58 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 66F8B3A68DF for ; Mon, 14 Apr 2008 02:55:57 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m3E9uO39012663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 11:56:24 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m3E9uKfJ032531; Mon, 14 Apr 2008 11:56:22 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Apr 2008 11:56:20 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Date: Mon, 14 Apr 2008 11:56:19 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Confirmation of Implementation and Drafting plans WAS: RE: [Netconf] Summary of the NETCONF WG Session in IETF 71 and ActionItems Thread-Index: AciUzt/qnNaeOgddTcyfe29+X5lQuwJPnACA References: From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 14 Apr 2008 09:56:20.0376 (UTC) FILETIME=[CA30D980:01C89E15] Subject: [Netconf] Confirmation of Implementation and Drafting plans WAS: RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1881022706==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1881022706== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89E15.C9F83805" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89E15.C9F83805 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 we sent out a summary of the IETF 71 NETCONF=20 session and six requests to confirm the discussion=20 in the WG session (results of a WG session need=20 to be confirmed on the maillist). =20 Unfortunately there was not much feedback on=20 these mails. Below is a summary: =20 - Martin B. is interested in an interoperability eveFrom netconf-bounces@ietf.org Mon Apr 14 02:56:00 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C02228C0FA; Mon, 14 Apr 2008 02:56:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA9CA3A6A3D for ; Mon, 14 Apr 2008 02:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.253 X-Spam-Level: X-Spam-Status: No, score=-3.253 tagged_above=-999 required=5 tests=[AWL=-0.655, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORDNf64SmSOw for ; Mon, 14 Apr 2008 02:55:58 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 66F8B3A68DF for ; Mon, 14 Apr 2008 02:55:57 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m3E9uO39012663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 11:56:24 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m3E9uKfJ032531; Mon, 14 Apr 2008 11:56:22 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Apr 2008 11:56:20 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Date: Mon, 14 Apr 2008 11:56:19 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Confirmation of Implementation and Drafting plans WAS: RE: [Netconf] Summary of the NETCONF WG Session in IETF 71 and ActionItems Thread-Index: AciUzt/qnNaeOgddTcyfe29+X5lQuwJPnACA References: From: "Ersue, Mehmet (NSN - DE/Muenich)" To: X-OriginalArrivalTime: 14 Apr 2008 09:56:20.0376 (UTC) FILETIME=[CA30D980:01C89E15] Subject: [Netconf] Confirmation of Implementation and Drafting plans WAS: RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1881022706==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1881022706== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89E15.C9F83805" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89E15.C9F83805 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 we sent out a summary of the IETF 71 NETCONF=20 session and six requests to confirm the discussion=20 in the WG session (results of a WG session need=20 to be confirmed on the maillist). =20 Unfortunately there was not much feedback on=20 these mails. Below is a summary: =20 - Martin B. is interested in an interoperabilint for chartered documents =20 Confirmed Notification draft Implementations: - Martin B. =20 Confirmed NETCONF Monitoring Implementations: - Martin B.=20 - Andy B. confirmed his plan to implement with low priority =20 Confirmed Partial Locking Implementations: - Martin B.=20 =20 Confirmed NETCONF over TLS Implementations: - Mohamad Badra I - Mohamad Badra II (planned as implementation with a different code base) =20 Draft for Netconf Content: - ??? =20 Draft for Notification Content: - Sharon (will check with her organization) =20 Draft for Access Control: - will be deferred a meeting cycle =20 =20 =3D=3D> How about others ?=20 =20 Is anybody else going to implement current=20 charter items or to draft the listed topics ? =20 PLEASE CONFIRM your implementation and drafting=20 plans on the maillist. Thank you! =20 PS: As you know we need _at least_ two implementations=20 for a standard track document.=20 =20 Cheers, Mehmet=20 =20 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Muenich) Sent: Wednesday, April 02, 2008 4:36 PM To: netconf@ietf.org Subject: [Netconf] Summary of the NETCONF WG Session in IETF 71 and ActionItems =09 =09 =09 =09 Dear NETCONF WG,=20 after having sent out the preliminary minutes we need to=20 confirm a few results of the NETCONF session. Below is a=20 summary. We'll send out separate mails for important topics=20 for confirmation.=20 =3D> Authors of WG items:=20 Please prepare a new version of your document.=20 =3D> WG members:=20 Please review updated documents and trigger a=20 discussion promptly.=20 ( *) indicates that a separate confirmation mail will be sent out)=20 A) Ongoing or planned implementations for the chartered items:=20 *) (Planned) Implementations of Partial Lock (3 hands):=20 Martin B, Balazs?, Sharon=20 *) (Planned) Implementations of NETCONF Monitoring (4 hands):=20 Martin B, Andy, Sharon, Mark=20 *) (Planned) Implementations of NETCONF over TLS:=20 No one in the audience was planning to implement.=20 After the meeting Mohamad Badra stated that he is=20 implementing.=20 =20 We need 2 implementations to be able to get it to draft=20 standard status. We think that even for a proposed standard,=20 it makes no sense if only one single person is planning to=20 implement. A standards track document should be implemented=20 by many (at least 2, but preferably many more).=20 Therefor the chairs have the opinion that it does not=20 make sense to standardize the document if there is no=20 other interested party to implement.=20 So, please respond to the parallel mail if there is anybody=20 implementing or planning to implement.=20 =20 TLS draft issues and AIs:=20 There were a few issues discussed in the session. Since Badra=20 was not there we couldn't asnwer all and got some action=20 items.=20 Chairs note: This topic is on hold till we have an answer on=20 how many implementations are planned for NETCONF over TLS.=20 *) (Planned) Implementations of the Notification draft (4 hands):=20 Martin B, Sharon (2?), Mark=20 B) Interoperability event:=20 In the NETCONF session we asked whether anybody is=20 interested in an interoperability event for chartered=20 documents or on the published RFCs or both. An=20 additional goal would be to prepare a test report=20 to shift NETCONF RFCs to the draft standard status.=20 There was nobody in the WG session interested in an=20 interoperability event.=20 =3D> If anybody is interested in an interoperability=20 event for chartered documents or on the=20 published RFCs please bring it up on the list.=20 C) Potential documents for non-chartered topics:=20 *) Access Control:=20 Andy Bierman and David Harrington in the session and=20 Kaushik Narayan after the session showed interest to=20 work on Access Control.=20 *) Netconf content:=20 There was interest to prepare I-D's for NETCONF=20 Content for CONFIGURATION (and/or NETCONF related)=20 ety event for chartered documents =20 Confirmed Notification draft Implementations: - Martin B. =20 Confirmed NETCONF Monitoring Implementations: - Martin B.=20 - Andy B. confirmed his plan to implement with low priority =20 Confirmed Partial Locking Implementations: - Martin B.=20 =20 Confirmed NETCONF over TLS Implementations: - Mohamad Badra I - Mohamad Badra II (planned as implementation with a different code base) =20 Draft for Netconf Content: - ??? =20 Draft for Notification Content: - Sharon (will check with her organization) =20 Draft for Access Control: - will be deferred a meeting cycle =20 =20 =3D=3D> How about others ?=20 =20 Is anybody else going to implement current=20 charter items or to draft the listed topics ? =20 PLEASE CONFIRM your implementation and drafting=20 plans on the maillist. Thank you! =20 PS: As you know we need _at least_ two implementations=20 for a standard track document.=20 =20 Cheers, Mehmet=20 =20 ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Muenich) Sent: Wednesday, April 02, 2008 4:36 PM To: netconf@ietf.org Subject: [Netconf] Summary of the NETCONF WG Session in IETF 71 and ActionItems =09 =09 =09 =09 Dear NETCONF WG,=20 after having sent out the preliminary minutes we need to=20 confirm a few results of the NETCONF session. Below is a=20 summary. We'll send out separate mails for important topics=20 for confirmation.=20 =3D> Authors of WG items:=20 Please prepare a new version of your document.=20 =3D> WG members:=20 Please review updated documents and trigger a=20 discussion promptly.=20 ( *) indicates that a separate confirmation mail will be sent out)=20 A) Ongoing or planned implementations for the chartered items:=20 *) (Planned) Implementations of Partial Lock (3 hands):=20 Martin B, Balazs?, Sharon=20 *) (Planned) Implementations of NETCONF Monitoring (4 hands):=20 Martin B, Andy, Sharon, Mark=20 *) (Planned) Implementations of NETCONF over TLS:=20 No one in the audience was planning to implement.=20 After the meeting Mohamad Badra stated that he is=20 implementing.=20 =20 We need 2 implementations to be able to get it to draft=20 standard status. We think that even for a proposed standard,=20 it makes no sense if only one single person is planning to=20 implement. A standards track document should be implemented=20 by many (at least 2, but preferably many more).=20 Therefor the chairs have the opinion that it does not=20 make sense to standardize the document if there is no=20 other interested party to implement.=20 So, please respond to the parallel mail if there is anybody=20 implementing or planning to implement.=20 =20 TLS draft issues and AIs:=20 There were a few issues discussed in the session. Since Badra=20 was not there we couldn't asnwer all and got some action=20 items.=20 Chairs note: This topic is on hold till we have an answer on=20 how many implementations are planned for NETCONF over TLS.=20 *) (Planned) Implementations of the Notification draft (4 hands):=20 Martin B, Sharon (2?), Mark=20 B) Interoperability event:=20 In the NETCONF session we asked whether anybody is=20 interested in an interoperability event for chartered=20 documents or on the published RFCs or both. An=20 additional goal would be to prepare a test report=20 to shift NETCONF RFCs to the draft standard status.=20 There was nobody in the WG session interested in an=20 interoperability event.=20 =3D> If anybody is interested in an interoperability=20 event for chartered documents or on the=20 published RFCs please bring it up on the list.=20 C) Potential documents for non-chartered topics:=20 *) Access Control:=20 Andy Bierman and David Harrington in the session and=20 Kaushik Narayan after the session showed interest to=20 work on Access Control.=20 *) Netconf content:=20 There was interest to prepare I-D's for NETCONF=20 Content for CONFIGURATION (and/or NETCONF related)vents and also NETCONF Content for SNMP or SYSLOG=20 notifications.=20 D) Other discussion which needs to be brought to the=20 NETCONF list:=20 =3D> Wes Hardaker:=20 Please post your questions on:=20 - what happens if you copy candidate to running=20 while a partial lock is held?=20 - need a matrix that covers the various operations=20 and their interaction=20 Please also post any other questions that we may=20 have missed above.=20 E) SOAP implementation presentation=20 =3D> Folks who volunteer to read and comment to=20 improve the quality please send your comments=20 to Dan Romascanu and copy the NETCONF maillist.=20 Thank you for your support.=20 Bert & Mehmet=20 ------_=_NextPart_001_01C89E15.C9F83805 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Summary of the NETCONF WG Session in IETF 71 and = Action Items
Hi All,
 
we sent out a summary of the IETF 71 NETCONF=20
session and six requests to confirm = the discussion
in the WG=20 session (results of a WG session need=20
to be confirmed on=20 the maillist).
 
Unfortunately there was not much feedback on=20
these mails.=20 Below is a summary:
 
- Martin B. is interested in an=20 interoperability event for Wes Hardaker:=20 Please post your questions on:=20 - what happens if you copy candidate to running=20 while a partial lock is held?=20 - need a matrix that covers the various operations=20 and their interaction=20 Please also post any other questions that we may=20 have missed above.=20 E) SOAP implementation presentation=20 =3D> Folks who volunteer to read and comment to=20 improve the quality please send your comments=20 to Dan Romascanu and copy the NETCONF maillist.=20 Thank you for your support.=20 Bert & Mehmet=20 ------_=_NextPart_001_01C89E15.C9F83805 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Summary of the NETCONF WG Session in IETF 71 and = Action Items
Hi All,
 
we sent out a summary of the IETF 71 NETCONF=20
session and six requests to confirm = the discussion
in the WG=20 session (results of a WG session need=20
to be confirmed on=20 the maillist).
 
Unfortunately there was not much feedback on=20
these mails.=20 Below is a summary:
 
- Martin B. is interested in an=20 interoperability event fONT>chartered documents
 
Confirmed Notification draft = Implementations:
- Martin B.
 
Confirmed NETCONF Monitoring=20 Implementations:
- Martin B.=20
- Andy B. confirmed=20 his plan to implement with low = priority
 
Confirmed Partial Locking=20 Implementations:
- Martin B.=20
 
Confirmed NETCONF over=20 TLS Implementations:
- Mohamad = Badra=20 I
- Mohamad = Badra II (planned=20 as implementation with a different code = base)
 
Draft for = Netconf=20 Content:
-=20 ???
 
chartered documents
 
Confirmed Notification draft = Implementations:
- Martin B.
 
Confirmed NETCONF Monitoring=20 Implementations:
- Martin B.=20
- Andy B. confirmed=20 his plan to implement with low = priority
 
Confirmed Partial Locking=20 Implementations:
- Martin B.=20
 
Confirmed NETCONF over=20 TLS Implementations:
- Mohamad = Badra=20 I
- Mohamad = Badra II (planned=20 as implementation with a different code = base)
 
Draft for = Netconf=20 Content:
-=20 ???
 
Draft for = Notification=20 Content:
- Sharon (will = check with=20 her organization)
 
Draft for = Access=20 Control:
- will be=20 deferred a=20 meeting cycle
 
 
=3D=3D> How=20 about others ?
 
Is anybody else=20 going to implement current
charter=20 items or to=20 draft the listed topics ?
 
PLEASE CONFIRM your implementation and = drafting=20
plans on the maillist.=20 Thank = you!
 
PS: As you know we need _at=20 least_ two impl>
Draft for = Notification=20 Content:
- Sharon (will = check with=20 her organization)
 
Draft for = Access=20 Control:
- will be=20 deferred a=20 meeting cycle
 
 
=3D=3D> How=20 about others ?
 
Is anybody else=20 going to implement current
charter=20 items or to=20 draft the listed topics ?
 
PLEASE CONFIRM your implementation and = drafting=20
plans on the maillist.=20 Thank = you!
 
PS: As you know we need _at=20 least_ twementations
for a standard track document.=20
 
Cheers,
Mehmet =
 

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, = Mehmet (NSN -=20 DE/Muenich)
Sent: Wednesday, April 02, 2008 4:36 = PM
To:=20 netconf@ietf.org
Subject: [Netconf] Summary of the NETCONF = WG=20 Session in IETF 71 and ActionItems


Dear NETCONF = WG,

after having sent out = the=20 preliminary minutes we need to
confirm a few results of the NETCONF session. = Below is a=20
summary. We'll send=20 out separate mails for important topics
for confirmation.

=3D> Authors of WG = items:=20
Please = prepare a new=20 version of your document.

=3D> WG members:=20
Please = review=20 updated documents and trigger a
discussion promptly.

( *) indicates that a = separate=20 confirmation mail will be sent out)


A) Ongoing or planned = implementations for the chartered items:

*) (Planned) = Implementations of=20 Partial Lock (3 hands):
Martin B, Balazs?, Sharon

*) (Planned) = Implementations of=20 NETCONF Monitoring (4 hands):
Martin B, Andy, Sharon, Mark =

*) (Planned) = Implementations of=20 NETCONF over TLS:
No=20 one in the audience was planning to implement.
After the meeting Mohamad = Badra stated that=20 he is
implementing.

<Note of the=20 chairs>

for a standard track document.=20
 
Cheers,
Mehmet =
 

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, = Mehmet (NSN -=20 DE/Muenich)
Sent: Wednesday, April 02, 2008 4:36 = PM
To:=20 netconf@ietf.org
Subject: [Netconf] Summary of the NETCONF = WG=20 Session in IETF 71 and ActionItems


Dear NETCONF = WG,

after having sent out = the=20 preliminary minutes we need to
confirm a few results of the NETCONF session. = Below is a=20
summary. We'll send=20 out separate mails for important topics
for confirmation.

=3D> Authors of WG = items:=20
Please = prepare a new=20 version of your document.

=3D> WG members:=20
Please = review=20 updated documents and trigger a
discussion promptly.

( *) indicates that a = separate=20 confirmation mail will be sent out)


A) Ongoing or planned = implementations for the chartered items:

*) (Planned) = Implementations of=20 Partial Lock (3 hands):
Martin B, Balazs?, Sharon

*) (Planned) = Implementations of=20 NETCONF Monitoring (4 hands):
Martin B, Andy, Sharon, Mark =

*) (Planned) = Implementations of=20 NETCONF over TLS:
No=20 one in the audience was planning to implement.
After the meeting Mohamad = Badra stated that=20 he is
implementing.

<Note of the=20 chairs>
We need 2=20 implementations to be able to get it to draft
standard status. We think that = even for a=20 proposed standard,
it makes no sense if only one single person is planning to=20
implement. A=20 standards track document should be implemented
by many (at least 2, but = preferably many=20 more).

Therefor the chairs = have the=20 opinion that it does not
make sense to standardize the document if there is no=20
other = interested=20 party to implement.
So, please respond to the parallel mail if there is anybody=20
implementing or=20 planning to implement.
</Note>

TLS draft issues and=20 AIs:
There were a=20 few issues discussed in the session. Since Badra =
was not there we couldn't = asnwer all and got=20 some action
items.
Chairs=20 note: This topic is on hold till we have an answer on =
how many implementations are = planned for=20 NETCONF over TLS.


*) (Planned) = Implementations of the=20 Notification draft (4 hands):
Martin B, Sharon (2?), Mark =


B) Interoperability=20 event:

In the NETCONF = session we asked=20 whether anybody is
interested in an interoperability event for chartered=20
documents or on the=20 published RFCs or both. An
additional goal would be to prepare a test report=20
to = shift NETCONF=20 RFCs to the draft standard status.

There was nobody in = the WG session=20 interested in an
interoperability event.

=3D> If anybody is = interested in=20 an interoperability
    event for chartered documents or on the=20
   =20 published RFCs please bring it up on the list.


C) Potential = documents for=20 non-chartered topics:

*) Access = Control:=20
Andy Bierman and = David Harrington=20 in the session and
Kaushik Narayan after the session showed interest to=20
work = on Access=20 Control.

*) Netconf = content:=20
There was interest = to prepare=20 I-D's for NETCONF
Content for CONFIGURATION (and/or NETCONF related)=20
events = and also=20 NETCONF Content for SNMP or SYSLOG
notifications.

D) Other discussion = which needs to=20 be brought to the
NETCONF list:

=3D> Wes Hardaker: =
Please = post your=20 questions on:
- what=20 happens if you copy candidate to running
  while a partial lock is held?=20
- need = a matrix that=20 covers the various operations
  and their interaction =
Please also post any other = questions that we=20 may
have missed=20 above.

E) SOAP = implementation presentation=20

=3D> Folks who = volunteer to read=20 and comment to
    improve the quality please send your = comments=20
   =20 to Dan Romascanu and copy the NETCONF maillist.


Thank you for your=20 support.

Bert & = Mehmet=20

------_=_NextPart_001_01C89E15.C9F83805-- --===============1881022706== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1881022706==-- rdana = size=3D2>We need 2=20 implementations to be able to get it to draft
standard status. We think that = even for a=20 proposed standard,
it makes no sense if only one single person is planning to=20
implement. A=20 standards track document should be implemented
by many (at least 2, but = preferably many=20 more).

Therefor the chairs = have the=20 opinion that it does not
make sense to standardize the document if there is no=20
other = interested=20 party to implement.
So, please respond to the parallel mail if there is anybody=20
implementing or=20 planning to implement.
</Note>

TLS draft issues and=20 AIs:
There were a=20 few issues discussed in the session. Since Badra =
was not there we couldn't = asnwer all and got=20 some action
items.
Chairs=20 note: This topic is on hold till we have an answer on =
how many implementations are = planned for=20 NETCONF over TLS.


*) (Planned) = Implementations of the=20 Notification draft (4 hands):
Martin B, Sharon (2?), Mark =


B) Interoperability=20 event:

In the NETCONF = session we asked=20 whether anybody is
interested in an interoperability event for chartered=20
documents or on the=20 published RFCs or both. An
additional goal would be to prepare a test report=20
to = shift NETCONF=20 RFCs to the draft standard status.

There was nobody in = the WG session=20 interested in an
interoperability event.

=3D> If anybody is = interested in=20 an interoperability
    event for chartered documents or on the=20
   =20 published RFCs please bring it up on the list.


C) Potential = documents for=20 non-chartered topics:

*) Access = Control:=20
Andy Bierman and = David Harrington=20 in the session and
Kaushik Narayan after the session showed interest to=20
work = on Access=20 Control.

*) Netconf = content:=20
There was interest = to prepare=20 I-D's for NETCONF
Content for CONFIGURATION (and/or NETCONF related)=20
events = and also=20 NETCONF Content for SNMP or SYSLOG
notifications.

D) Other discussion = which needs to=20 be brought to the
NETCONF list:

=3D> Wes Hardaker: =
Please = post your=20 questions on:
- what=20 happens if you copy candidate to running
  while a partial lock is held?=20
- need = a matrix that=20 covers the various operations
  and their interaction =
Please also post any other = questions that we=20 may
have missed=20 above.

E) SOAP = implementation presentation=20

=3D> Folks who = volunteer to read=20 and comment to
    improve the quality please send your = comments=20
   =20 to Dan Romascanu and copy the NETCONF maillist.


Thank you for your=20 support.

Bert & = Mehmet=20

------_=_NextPart_001_01C89E15.C9F83805-- --===============1881022706== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1881022706==-- From netconf-bounces@ietf.org Mon Apr 14 05:28:52 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4101C3A6D14; Mon, 14 Apr 2008 05:28:52 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 207483A6C90 for ; Mon, 14 Apr 2008 05:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE2OLz5N1LXf for ; Mon, 14 Apr 2008 05:28:50 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 35E4A3A6A7F for ; Mon, 14 Apr 2008 05:28:50 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA10.westchester.pa.mail.comcast.net with comcast id DNx91Z0020vyq2s5A08F00; Mon, 14 Apr 2008 12:28:14 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA05.westchester.pa.mail.comcast.net with comcast id DQVD1Z00C4HwxpC3R00000; Mon, 14 Apr 2008 12:29:20 +0000 X-Authority-Analysis: v=1.0 c=1 a=7TeIqVRvmFEA:10 a=QEOogkkYNQEA:10 a=vorug7TgBJ41K9uV0twA:9 a=-qJH_0UpfoUSbTBrSRQA:7 a=ePljyhf5PZoV6XKsEYsy6AFzHFcA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Ersue, Mehmet \(NSN - DE/Muenich\)'" , References: Date: Mon, 14 Apr 2008 08:29:13 -0400 Message-ID: <00f001c89e2b$26430d50$6502a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: thread-index: AciUzt/qnNaeOgddTcyfe29+X5lQuwJPnACAAAckpkA= Subject: Re: [Netconf] Confirmation of Implementation and Drafting plans WAS:RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > PS: As you know we need _at least_ two implementations > for a standard track document. Can you identify the RFC that describes the standards process that has this requirement? I thought we were developing standards according to the IETF standards process as documented in RFC2026: " A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation." David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 14 05:28:52 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4101C3A6D14; Mon, 14 Apr 2008 05:28:52 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 207483A6C90 for ; Mon, 14 Apr 2008 05:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE2OLz5N1LXf for ; Mon, 14 Apr 2008 05:28:50 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 35E4A3A6A7F for ; Mon, 14 Apr 2008 05:28:50 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA10.westchester.pa.mail.comcast.net with comcast id DNx91Z0020vyq2s5A08F00; Mon, 14 Apr 2008 12:28:14 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA05.westchester.pa.mail.comcast.net with comcast id DQVD1Z00C4HwxpC3R00000; Mon, 14 Apr 2008 12:29:20 +0000 X-Authority-Analysis: v=1.0 c=1 a=7TeIqVRvmFEA:10 a=QEOogkkYNQEA:10 a=vorug7TgBJ41K9uV0twA:9 a=-qJH_0UpfoUSbTBrSRQA:7 a=ePljyhf5PZoV6XKsEYsy6AFzHFcA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Ersue, Mehmet \(NSN - DE/Muenich\)'" , References: Date: Mon, 14 Apr 2008 08:29:13 -0400 Message-ID: <00f001c89e2b$26430d50$6502a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: thread-index: AciUzt/qnNaeOgddTcyfe29+X5lQuwJPnACAAAckpkA= Subject: Re: [Netconf] Confirmation of Implementation and Drafting plans WAS:RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > PS: As you know we need _at least_ two implementations > for a standard track document. Can you identify the RFC that describes the standards process that has this requirement? I thought we were developing standards according to the IETF standards process as documented in RFC2026: " A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation." David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 14 05:52:29 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26A8B3A6A4C; Mon, 14 Apr 2008 05:52:29 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27FCE3A67CE for ; Mon, 14 Apr 2008 05:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[AWL=1.492, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RZtAxDTlQhd for ; Mon, 14 Apr 2008 05:52:26 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 060543A6A7F for ; Mon, 14 Apr 2008 05:52:21 -0700 (PDT) Received: (qmail 16021 invoked from network); 14 Apr 2008 12:52:51 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 14 Apr 2008 12:52:51 -0000 From: "Bert Wijnen - IETF" To: "David B Harrington" , "'Ersue, Mehmet \(NSN - DE/Muenich\)'" , Date: Mon, 14 Apr 2008 14:52:53 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <00f001c89e2b$26430d50$6502a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: Re: [Netconf] Confirmation of Implementation and Drafting plansWAS:RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Inline Bert Wijnen > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > David B Harrington > Verzonden: maandag 14 april 2008 14:29 > Aan: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org > Onderwerp: Re: [Netconf] Confirmation of Implementation and Drafting > plansWAS:RE: Summary of the NETCONF WG Session in IETF 71 and > ActionItems > > > Hi, > > > PS: As you know we need _at least_ two implementations > > for a standard track document. > > Can you identify the RFC that describes the standards process that has > this requirement? Dave, the below is correct. But we were not asking that the spec would be implemented by the time we get to PS. We were asking if anyone had plans to implement NetConf over TLS (anytime as far as I am concerned). And my view is that if we have not at least 2 independent impleemntation plans, that I do not see why we would standardize. Bert > I thought we were developing standards according to > the IETF standards process as documented in RFC2026: > > " A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has > received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. However, such experience is highly desirable, and will > usually represent a strong argument in favor of a Proposed Standard > designation." > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 14 05:52:29 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26A8B3A6A4C; Mon, 14 Apr 2008 05:52:29 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27FCE3A67CE for ; Mon, 14 Apr 2008 05:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[AWL=1.492, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RZtAxDTlQhd for ; Mon, 14 Apr 2008 05:52:26 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 060543A6A7F for ; Mon, 14 Apr 2008 05:52:21 -0700 (PDT) Received: (qmail 16021 invoked from network); 14 Apr 2008 12:52:51 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 14 Apr 2008 12:52:51 -0000 From: "Bert Wijnen - IETF" To: "David B Harrington" , "'Ersue, Mehmet \(NSN - DE/Muenich\)'" , Date: Mon, 14 Apr 2008 14:52:53 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <00f001c89e2b$26430d50$6502a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: Re: [Netconf] Confirmation of Implementation and Drafting plansWAS:RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Inline Bert Wijnen > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > David B Harrington > Verzonden: maandag 14 april 2008 14:29 > Aan: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org > Onderwerp: Re: [Netconf] Confirmation of Implementation and Drafting > plansWAS:RE: Summary of the NETCONF WG Session in IETF 71 and > ActionItems > > > Hi, > > > PS: As you know we need _at least_ two implementations > > for a standard track document. > > Can you identify the RFC that describes the standards process that has > this requirement? Dave, the below is correct. But we were not asking that the spec would be implemented by the time we get to PS. We were asking if anyone had plans to implement NetConf over TLS (anytime as far as I am concerned). And my view is that if we have not at least 2 independent impleemntation plans, that I do not see why we would standardize. Bert > I thought we were developing standards according to > the IETF standards process as documented in RFC2026: > > " A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has > received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. However, such experience is highly desirable, and will > usually represent a strong argument in favor of a Proposed Standard > designation." > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 14 05:57:26 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E6073A6E5E; Mon, 14 Apr 2008 05:57:26 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5871F28C2DA for ; Mon, 14 Apr 2008 05:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[AWL=1.413, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWFmbkqayY6T for ; Mon, 14 Apr 2008 05:57:20 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id D27223A6A4C for ; Mon, 14 Apr 2008 05:57:19 -0700 (PDT) Received: (qmail 20624 invoked from network); 14 Apr 2008 12:57:49 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 14 Apr 2008 12:57:49 -0000 From: "Bert Wijnen - IETF" To: "Ersue, Mehmet \(NSN - DE/Muenich\)" , Date: Mon, 14 Apr 2008 14:57:50 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: Re: [Netconf] Confirmation of Implementation and Drafting plans WAS: RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1515309028==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1515309028== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E2_01C89E3F.E8C10030" This is a multi-part message in MIME format. ------=_NextPart_000_00E2_01C89E3F.E8C10030 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Summary of the NETCONF WG Session in IETF 71 and Action ItemsLet me (as co-chair) also chime in here. You may have found other WGs where WG chairs assume that silence means consent. We however would rather see people explicitly express their interest/plans/volunteership etc. I personally certainly do not like the idea of "silence means consent", except in cases where we as chairs state that that will be our assumption. Bert Wijnen -----Oorspronkelijk bericht----- Van: Ersue, Mehmet (NSN - DE/Muenich) [mailto:mehmet.ersue@nsn.com] Verzonden: maandag 14 april 2008 11:56 Aan: netconf@ietf.org CC: Bert Wijnen - IETF Onderwerp: Confirmation of Implementation and Drafting plans WAS: RE: [Netconf] Summary of the NETCONF WG Session in IETF 71 and ActionItems Hi All, we sent out a summary of the IETF 71 NETCONF session and six requests to confirm the discussion in the WG session (results of a WG session need to be confirmed on the maillist). Unfortunately there was not much feedback on these mails. Below is a summary: - Martin B. is interested in an interoperability event for chartered documents Confirmed Notification draft Implementations: - Martin B. Confirmed NETCONF Monitoring Implementations: - Martin B. - Andy B. confirmed his plan to implement with low priority Confirmed Partial Locking Implementations: - Martin B. Confirmed NETCONF over TLS Implementations: - Mohamad Badra I - Mohamad Badra II (planned as implementation with a different code base) Draft for Netconf Content: - ??? Draft for Notification Content: - Sharon (will check with her organization) Draft for Access Control: - will be deferred a meeting cycle ==> How about others ? Is anybody else going to implement current charter items or to draft the listed topics ? PLEASE CONFIRM your implementation and drafting plans on the maillist. Thank you! PS: As you know we need _at least_ two implementations for a standard track document. Cheers, Mehmet ---------------------------------------------------------------------------- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Muenich) Sent: Wednesday, April 02, 2008 4:36 PM To: netconf@ietf.org Subject: [Netconf] Summary of the NETCONF WG Session in IETF 71 and ActionItems Dear NETCONF WG, after having sent out the preliminary minutes we need to confirm a few results of the NETCONF session. Below is a summary. We'll send out separate mails for important topics for confirmation. => Authors of WG items: Please prepare a new version of your document. => WG members: Please review updated documents and trigger a discussion promptly. ( *) indicates that a separate confirmation mail will be sent out) A) Ongoing or planned implementations for the chartered items: *) (Planned) Implementations of Partial Lock (3 hands): Martin B, Balazs?, Sharon *) (Planned) Implementations of NETCONF Monitoring (4 hands): Martin B, Andy, Sharon, Mark *) (Planned) Implementations of NETCONF over TLS: No one in the audience was planning to implement. After the meeting Mohamad Badra stated that he is implementing. We need 2 implementations to be able to get it to draft standard status. We think that even for a proposed standard, it makes no sense if only one single person is planning to implement. A standards track document should be implemented by many (at least 2, but preferably many more). Therefor the chairs have the opinion that it does not make sense to standardize the document if there is no other interested party to implement. So, please respond to the parallel mail if there is anybody implementing or planning to implement. TLS draft issues and AIs: There were a few issues discussed in the session. Since Badra was not there we couldn't asnwer all and got some action items. Chairs note: This topic is on hold till we have an answer on how many implementations are planned for NETCONF over TLS. *) (Planned) Implementations of the Notification draft (4 hands): Martin B, Sharon (2?), Mark B) Interoperability event: In the NETCONF session we asked whether anybody is interested in an interoperability event for chartered documents or on the published RFCs or both. An additional goal would be to prepare a test report to shift NETCONF RFCs to the draft standard status. There was nobody in the WG session interested in an interoperability event. => If anybody is interested in an interoperability event for chartered documents or on the published RFCs please bring it up on the list. C) Potential documents for non-chartered topics: *) Access Control: Andy Bierman and David Harrington in the session and Kaushik Narayan after the session showed interest to work on Access Control. *) Netconf content: There was interest to prepare I-D's for NETCONF Content for CONFIGURATION (and/or NETCONF related) events and also NETCONF Content for SNMP or SYSLOG notifications. D) Other discussion which needs to be brought to the NETCONF list: => Wes Hardaker: Please post your questions on: - what happens if you copy candidate to running while a partial lock is held? - need a matrix that covers the various operations and their interaction Please also post any other questions that we may have missed above. E) SOAP implementation presentation => Folks who volunteer to read and comment to improve the quality please send your comments to Dan Romascanu and copy the NETCONF maillist. Thank you for your support. Bert & Mehmet ------=_NextPart_000_00E2_01C89E3F.E8C10030 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Summary of the NETCONF WG Session in IETF 71 and = Action Items
Let me=20 (as co-chair) also chime in here.
You=20 may have found other WGs where WG chairs assume that silence means=20 consent.
We=20 however would rather see people explicitly express their=20 interest/plans/volunteership
etc. I=20 personally certainly do not like the idea of "silence means consent", = except=20 in
cases=20 where we as chairs state that that will be our = assumption.
 
Bert Wijnen
-----Oorspronkelijk bericht-----
Van: Ersue, Mehmet = (NSN -=20 DE/Muenich) [mailto:mehmet.ersue@nsn.com]
Verzonden: maandag = 14=20 april 2008 11:56
Aan: netconf@ietf.org
CC: Bert = Wijnen -=20 IETF
Onderwerp: Confirmation of Implementation and Drafting = plans=20 WAS: RE: [Netconf] Summary of the NETCONF WG Session in IETF 71 and=20 ActionItems

Hi All,
 
we sent out a summary of the IETF 71 NETCONF=20
session and six=20 requests to confirm the discussion =
in the WG=20 session (results of a WG session need=20
to be confirmed on=20 the maillist).
 
Unfortunately there was not much feedback on=20
these mails.=20 Below is a summary:
 
- Martin B. is interested in = an=20 interoperability event for chartered documents
 
Confirmed Notification = draft=20 Implementations:
- Martin B.
 
Confirmed NETCONF Monitoring=20 Implementations:
- Martin B.=20
- Andy B. confirmed=20 his plan to implement with low=20 priority
 
Confirmed Partial Locking=20 Implementations:
- Martin B.=20
 
Confirmed NETCONF over=20 TLS Implementations:
- Mohamad = Badra=20 I
- Mohamad = Badra II=20 (planned as implementation with a different code = base)
 
Draft for = Netconf=20 Content:
-=20 ???
 
Draft for = Notification=20 Content:
- Sharon = (will check with=20 her organization)
 
Draft for = Access=20 Control:
- will be=20 deferred a=20 meeting cycle
 
 
=3D=3D> How=20 about others ?
 
Is anybody=20 else going to implement current
charter=20 items or to=20 draft the listed topics ?
 
PLEASE CONFIRM your implementation and = drafting=20
plans on the maillist.=20 Thank = you!
 
PS: As you know we need _at=20 least_ two implementations
for a standard track=20 document.
 
Cheers,
Mehmet =
 

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, = Mehmet (NSN=20 - DE/Muenich)
Sent: Wednesday, April 02, 2008 4:36=20 PM
To: netconf@ietf.org
Subject: [Netconf] = Summary of=20 the NETCONF WG Session in IETF 71 and = ActionItems


Dear NETCONF = WG,=20

after having sent = out the=20 preliminary minutes we need to
confirm a few results of the NETCONF = session. Below is a=20
summary. We'll=20 send out separate mails for important topics
for = confirmation.

=3D> Authors of = WG items:=20
Please prepare a=20 new version of your document.

=3D> WG members: =
Please review=20 updated documents and trigger a
discussion promptly.

( *) indicates that = a separate=20 confirmation mail will be sent out)


A) Ongoing or = planned=20 implementations for the chartered items:

*) (Planned) = Implementations of=20 Partial Lock (3 hands):
Martin B, Balazs?, Sharon

*) (Planned) = Implementations of=20 NETCONF Monitoring (4 hands):
Martin B, Andy, Sharon, Mark =

*) (Planned) = Implementations of=20 NETCONF over TLS:
No one in the audience was planning to = implement.=20
After the meeting = Mohamad Badra=20 stated that he is
implementing.

<Note of the=20 chairs>
We need=20 2 implementations to be able to get it to draft =
standard status. We think = that even for a=20 proposed standard,
it makes no sense if only one single person is planning to=20
implement. A=20 standards track document should be implemented =
by many (at least 2, but = preferably many=20 more).

Therefor the chairs = have the=20 opinion that it does not
make sense to standardize the document if there is no=20
other interested=20 party to implement.
So, please respond to the parallel mail if there is anybody =
implementing or=20 planning to implement.
</Note>

TLS draft issues = and=20 AIs:
There were a=20 few issues discussed in the session. Since Badra =
was not there we couldn't = asnwer all and=20 got some action
items.
Chairs note: This topic is on hold till we have an answer=20 on
how many=20 implementations are planned for NETCONF over TLS. =


*) (Planned) = Implementations of=20 the Notification draft (4 hands):
Martin B, Sharon (2?), Mark =


B) Interoperability = event:

In the NETCONF = session we asked=20 whether anybody is
interested in an interoperability event for chartered=20
documents or on=20 the published RFCs or both. An
additional goal would be to prepare a test = report=20
to = shift NETCONF=20 RFCs to the draft standard status.

There was nobody in = the WG=20 session interested in an
interoperability event.

=3D> If anybody = is interested in=20 an interoperability
    event for chartered documents or on the=20
   =20 published RFCs please bring it up on the list. =


C) Potential = documents for=20 non-chartered topics:

*) Access = Control:=20
Andy Bierman and = David=20 Harrington in the session and
Kaushik Narayan after the session showed = interest to=20
work = on Access=20 Control.

*) Netconf = content:=20
There was interest = to prepare=20 I-D's for NETCONF
Content for CONFIGURATION (and/or NETCONF related)=20
events and also=20 NETCONF Content for SNMP or SYSLOG
notifications.

D) Other discussion = which needs=20 to be brought to the
NETCONF list:

=3D> Wes = Hardaker:=20
Please post your=20 questions on:
-=20 what happens if you copy candidate to running =
  while a partial lock = is held?=20
- = need a matrix=20 that covers the various operations
  and their interaction =
Please also post any other = questions that=20 we may
have missed=20 above.

E) SOAP = implementation=20 presentation

=3D> Folks who = volunteer to read=20 and comment to
    improve the quality please send your = comments=20
   =20 to Dan Romascanu and copy the NETCONF maillist. =


Thank you for your=20 support.

Bert & = Mehmet=20

------=_NextPart_000_00E2_01C89E3F.E8C10030-- --===============1515309028== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1515309028==-- From netconf-bounces@ietf.org Mon Apr 14 05:57:26 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E6073A6E5E; Mon, 14 Apr 2008 05:57:26 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5871F28C2DA for ; Mon, 14 Apr 2008 05:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[AWL=1.413, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWFmbkqayY6T for ; Mon, 14 Apr 2008 05:57:20 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id D27223A6A4C for ; Mon, 14 Apr 2008 05:57:19 -0700 (PDT) Received: (qmail 20624 invoked from network); 14 Apr 2008 12:57:49 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 14 Apr 2008 12:57:49 -0000 From: "Bert Wijnen - IETF" To: "Ersue, Mehmet \(NSN - DE/Muenich\)" , Date: Mon, 14 Apr 2008 14:57:50 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: Re: [Netconf] Confirmation of Implementation and Drafting plans WAS: RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1515309028==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1515309028== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E2_01C89E3F.E8C10030" This is a multi-part message in MIME format. ------=_NextPart_000_00E2_01C89E3F.E8C10030 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Summary of the NETCONF WG Session in IETF 71 and Action ItemsLet me (as co-chair) also chime in here. You may have found other WGs where WG chairs assume that silence means consent. We however would rather see people explicitly express their interest/plans/volunteership etc. I personally certainly do not like the idea of "silence means consent", except in cases where we as chairs state that that will be our assumption. Bert Wijnen -----Oorspronkelijk bericht----- Van: Ersue, Mehmet (NSN - DE/Muenich) [mailto:mehmet.ersue@nsn.com] Verzonden: maandag 14 april 2008 11:56 Aan: netconf@ietf.org CC: Bert Wijnen - IETF Onderwerp: Confirmation of Implementation and Drafting plans WAS: RE: [Netconf] Summary of the NETCONF WG Session in IETF 71 and ActionItems Hi All, we sent out a summary of the IETF 71 NETCONF session and six requests to confirm the discussion in the WG session (results of a WG session need to be confirmed on the maillist). Unfortunately there was not much feedback on these mails. Below is a summary: - Martin B. is interested in an interoperability event for chartered documents Confirmed Notification draft Implementations: - Martin B. Confirmed NETCONF Monitoring Implementations: - Martin B. - Andy B. confirmed his plan to implement with low priority Confirmed Partial Locking Implementations: - Martin B. Confirmed NETCONF over TLS Implementations: - Mohamad Badra I - Mohamad Badra II (planned as implementation with a different code base) Draft for Netconf Content: - ??? Draft for Notification Content: - Sharon (will check with her organization) Draft for Access Control: - will be deferred a meeting cycle ==> How about others ? Is anybody else going to implement current charter items or to draft the listed topics ? PLEASE CONFIRM your implementation and drafting plans on the maillist. Thank you! PS: As you know we need _at least_ two implementations for a standard track document. Cheers, Mehmet ---------------------------------------------------------------------------- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Muenich) Sent: Wednesday, April 02, 2008 4:36 PM To: netconf@ietf.org Subject: [Netconf] Summary of the NETCONF WG Session in IETF 71 and ActionItems Dear NETCONF WG, after having sent out the preliminary minutes we need to confirm a few results of the NETCONF session. Below is a summary. We'll send out separate mails for important topics for confirmation. => Authors of WG items: Please prepare a new version of your document. => WG members: Please review updated documents and trigger a discussion promptly. ( *) indicates that a separate confirmation mail will be sent out) A) Ongoing or planned implementations for the chartered items: *) (Planned) Implementations of Partial Lock (3 hands): Martin B, Balazs?, Sharon *) (Planned) Implementations of NETCONF Monitoring (4 hands): Martin B, Andy, Sharon, Mark *) (Planned) Implementations of NETCONF over TLS: No one in the audience was planning to implement. After the meeting Mohamad Badra stated that he is implementing. We need 2 implementations to be able to get it to draft standard status. We think that even for a proposed standard, it makes no sense if only one single person is planning to implement. A standards track document should be implemented by many (at least 2, but preferably many more). Therefor the chairs have the opinion that it does not make sense to standardize the document if there is no other interested party to implement. So, please respond to the parallel mail if there is anybody implementing or planning to implement. TLS draft issues and AIs: There were a few issues discussed in the session. Since Badra was not there we couldn't asnwer all and got some action items. Chairs note: This topic is on hold till we have an answer on how many implementations are planned for NETCONF over TLS. *) (Planned) Implementations of the Notification draft (4 hands): Martin B, Sharon (2?), Mark B) Interoperability event: In the NETCONF session we asked whether anybody is interested in an interoperability event for chartered documents or on the published RFCs or both. An additional goal would be to prepare a test report to shift NETCONF RFCs to the draft standard status. There was nobody in the WG session interested in an interoperability event. => If anybody is interested in an interoperability event for chartered documents or on the published RFCs please bring it up on the list. C) Potential documents for non-chartered topics: *) Access Control: Andy Bierman and David Harrington in the session and Kaushik Narayan after the session showed interest to work on Access Control. *) Netconf content: There was interest to prepare I-D's for NETCONF Content for CONFIGURATION (and/or NETCONF related) events and also NETCONF Content for SNMP or SYSLOG notifications. D) Other discussion which needs to be brought to the NETCONF list: => Wes Hardaker: Please post your questions on: - what happens if you copy candidate to running while a partial lock is held? - need a matrix that covers the various operations and their interaction Please also post any other questions that we may have missed above. E) SOAP implementation presentation => Folks who volunteer to read and comment to improve the quality please send your comments to Dan Romascanu and copy the NETCONF maillist. Thank you for your support. Bert & Mehmet ------=_NextPart_000_00E2_01C89E3F.E8C10030 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Summary of the NETCONF WG Session in IETF 71 and = Action Items
Let me=20 (as co-chair) also chime in here.
You=20 may have found other WGs where WG chairs assume that silence means=20 consent.
We=20 however would rather see people explicitly express their=20 interest/plans/volunteership
etc. I=20 personally certainly do not like the idea of "silence means consent", = except=20 in
cases=20 where we as chairs state that that will be our = assumption.
 
Bert Wijnen
-----Oorspronkelijk bericht-----
Van: Ersue, Mehmet = (NSN -=20 DE/Muenich) [mailto:mehmet.ersue@nsn.com]
Verzonden: maandag = 14=20 april 2008 11:56
Aan: netconf@ietf.org
CC: Bert = Wijnen -=20 IETF
Onderwerp: Confirmation of Implementation and Drafting = plans=20 WAS: RE: [Netconf] Summary of the NETCONF WG Session in IETF 71 and=20 ActionItems

Hi All,
 
we sent out a summary of the IETF 71 NETCONF=20
session and six=20 requests to confirm the discussion =
in the WG=20 session (results of a WG session need=20
to be confirmed on=20 the maillist).
 
Unfortunately there was not much feedback on=20
these mails.=20 Below is a summary:
 
- Martin B. is interested in = an=20 interoperability event for chartered documents
 
Confirmed Notification = draft=20 Implementations:
- Martin B.
 
Confirmed NETCONF Monitoring=20 Implementations:
- Martin B.=20
- Andy B. confirmed=20 his plan to implement with low=20 priority
 
Confirmed Partial Locking=20 Implementations:
- Martin B.=20
 
Confirmed NETCONF over=20 TLS Implementations:
- Mohamad = Badra=20 I
- Mohamad = Badra II=20 (planned as implementation with a different code = base)
 
Draft for = Netconf=20 Content:
-=20 ???
 
Draft for = Notification=20 Content:
- Sharon = (will check with=20 her organization)
 
Draft for = Access=20 Control:
- will be=20 deferred a=20 meeting cycle
 
 
=3D=3D> How=20 about others ?
 
Is anybody=20 else going to implement current
charter=20 items or to=20 draft the listed topics ?
 
PLEASE CONFIRM your implementation and = drafting=20
plans on the maillist.=20 Thank = you!
 
PS: As you know we need _at=20 least_ two implementations
for a standard track=20 document.
 
Cheers,
Mehmet =
 

From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, = Mehmet (NSN=20 - DE/Muenich)
Sent: Wednesday, April 02, 2008 4:36=20 PM
To: netconf@ietf.org
Subject: [Netconf] = Summary of=20 the NETCONF WG Session in IETF 71 and = ActionItems


Dear NETCONF = WG,=20

after having sent = out the=20 preliminary minutes we need to
confirm a few results of the NETCONF = session. Below is a=20
summary. We'll=20 send out separate mails for important topics
for = confirmation.

=3D> Authors of = WG items:=20
Please prepare a=20 new version of your document.

=3D> WG members: =
Please review=20 updated documents and trigger a
discussion promptly.

( *) indicates that = a separate=20 confirmation mail will be sent out)


A) Ongoing or = planned=20 implementations for the chartered items:

*) (Planned) = Implementations of=20 Partial Lock (3 hands):
Martin B, Balazs?, Sharon

*) (Planned) = Implementations of=20 NETCONF Monitoring (4 hands):
Martin B, Andy, Sharon, Mark =

*) (Planned) = Implementations of=20 NETCONF over TLS:
No one in the audience was planning to = implement.=20
After the meeting = Mohamad Badra=20 stated that he is
implementing.

<Note of the=20 chairs>
We need=20 2 implementations to be able to get it to draft =
standard status. We think = that even for a=20 proposed standard,
it makes no sense if only one single person is planning to=20
implement. A=20 standards track document should be implemented =
by many (at least 2, but = preferably many=20 more).

Therefor the chairs = have the=20 opinion that it does not
make sense to standardize the document if there is no=20
other interested=20 party to implement.
So, please respond to the parallel mail if there is anybody =
implementing or=20 planning to implement.
</Note>

TLS draft issues = and=20 AIs:
There were a=20 few issues discussed in the session. Since Badra =
was not there we couldn't = asnwer all and=20 got some action
items.
Chairs note: This topic is on hold till we have an answer=20 on
how many=20 implementations are planned for NETCONF over TLS. =


*) (Planned) = Implementations of=20 the Notification draft (4 hands):
Martin B, Sharon (2?), Mark =


B) Interoperability = event:

In the NETCONF = session we asked=20 whether anybody is
interested in an interoperability event for chartered=20
documents or on=20 the published RFCs or both. An
additional goal would be to prepare a test = report=20
to = shift NETCONF=20 RFCs to the draft standard status.

There was nobody in = the WG=20 session interested in an
interoperability event.

=3D> If anybody = is interested in=20 an interoperability
    event for chartered documents or on the=20
   =20 published RFCs please bring it up on the list. =


C) Potential = documents for=20 non-chartered topics:

*) Access = Control:=20
Andy Bierman and = David=20 Harrington in the session and
Kaushik Narayan after the session showed = interest to=20
work = on Access=20 Control.

*) Netconf = content:=20
There was interest = to prepare=20 I-D's for NETCONF
Content for CONFIGURATION (and/or NETCONF related)=20
events and also=20 NETCONF Content for SNMP or SYSLOG
notifications.

D) Other discussion = which needs=20 to be brought to the
NETCONF list:

=3D> Wes = Hardaker:=20
Please post your=20 questions on:
-=20 what happens if you copy candidate to running =
  while a partial lock = is held?=20
- = need a matrix=20 that covers the various operations
  and their interaction =
Please also post any other = questions that=20 we may
have missed=20 above.

E) SOAP = implementation=20 presentation

=3D> Folks who = volunteer to read=20 and comment to
    improve the quality please send your = comments=20
   =20 to Dan Romascanu and copy the NETCONF maillist. =


Thank you for your=20 support.

Bert & = Mehmet=20

------=_NextPart_000_00E2_01C89E3F.E8C10030-- --===============1515309028== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============1515309028==-- From netconf-bounces@ietf.org Mon Apr 14 06:13:11 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F5B728C300; Mon, 14 Apr 2008 06:13:11 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 365B53A68DD for ; Mon, 14 Apr 2008 06:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WokI4-4bQSto for ; Mon, 14 Apr 2008 06:13:09 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id C0FBB3A6E8D for ; Mon, 14 Apr 2008 06:13:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,655,1199682000"; d="scan'208";a="117704079" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 14 Apr 2008 09:13:27 -0400 X-IronPort-AV: E=Sophos;i="4.25,655,1199682000"; d="scan'208";a="188590260" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Apr 2008 09:13:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Apr 2008 15:13:21 +0200 Message-ID: In-Reply-To: <00f001c89e2b$26430d50$6502a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Confirmation of Implementation and Drafting plansWAS:RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems Thread-Index: AciUzt/qnNaeOgddTcyfe29+X5lQuwJPnACAAAckpkAAAaiIsA== References: <00f001c89e2b$26430d50$6502a8c0@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "David B Harrington" , "Ersue, Mehmet (NSN - DE/Muenich)" , Subject: Re: [Netconf] Confirmation of Implementation and Drafting plansWAS:RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org David, You are correct - this formal requirement comes later. We need at least two implementations with different code bases and demonstrate interoperability to advance a document from Proposed to Draft. However, I believe that requiring at least a declaration of intent from two different entities (vendors, open code implementers, etc.) in order to charter a work as standards track and then ask the IESG to approve a document as PS is quite in tune with this formal process requirement that comes later. Dan > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of David B Harrington > Sent: Monday, April 14, 2008 3:29 PM > To: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org > Subject: Re: [Netconf] Confirmation of Implementation and > Drafting plansWAS:RE: Summary of the NETCONF WG Session in > IETF 71 and ActionItems > > Hi, > > > PS: As you know we need _at least_ two implementations for > a standard > > track document. > > Can you identify the RFC that describes the standards process > that has this requirement? I thought we were developing > standards according to the IETF standards process as > documented in RFC2026: > > " A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, > has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. However, such experience is highly desirable, and will > usually represent a strong argument in favor of a Proposed Standard > designation." > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 14 06:13:11 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F5B728C300; Mon, 14 Apr 2008 06:13:11 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 365B53A68DD for ; Mon, 14 Apr 2008 06:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WokI4-4bQSto for ; Mon, 14 Apr 2008 06:13:09 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id C0FBB3A6E8D for ; Mon, 14 Apr 2008 06:13:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,655,1199682000"; d="scan'208";a="117704079" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 14 Apr 2008 09:13:27 -0400 X-IronPort-AV: E=Sophos;i="4.25,655,1199682000"; d="scan'208";a="188590260" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Apr 2008 09:13:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Apr 2008 15:13:21 +0200 Message-ID: In-Reply-To: <00f001c89e2b$26430d50$6502a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Confirmation of Implementation and Drafting plansWAS:RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems Thread-Index: AciUzt/qnNaeOgddTcyfe29+X5lQuwJPnACAAAckpkAAAaiIsA== References: <00f001c89e2b$26430d50$6502a8c0@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "David B Harrington" , "Ersue, Mehmet (NSN - DE/Muenich)" , Subject: Re: [Netconf] Confirmation of Implementation and Drafting plansWAS:RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org David, You are correct - this formal requirement comes later. We need at least two implementations with different code bases and demonstrate interoperability to advance a document from Proposed to Draft. However, I believe that requiring at least a declaration of intent from two different entities (vendors, open code implementers, etc.) in order to charter a work as standards track and then ask the IESG to approve a document as PS is quite in tune with this formal process requirement that comes later. Dan > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of David B Harrington > Sent: Monday, April 14, 2008 3:29 PM > To: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org > Subject: Re: [Netconf] Confirmation of Implementation and > Drafting plansWAS:RE: Summary of the NETCONF WG Session in > IETF 71 and ActionItems > > Hi, > > > PS: As you know we need _at least_ two implementations for > a standard > > track document. > > Can you identify the RFC that describes the standards process > that has this requirement? I thought we were developing > standards according to the IETF standards process as > documented in RFC2026: > > " A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, > has received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. However, such experience is highly desirable, and will > usually represent a strong argument in favor of a Proposed Standard > designation." > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 14 06:38:08 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825803A6E95; Mon, 14 Apr 2008 06:38:08 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8AA3A6E70 for ; Mon, 14 Apr 2008 06:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.213 X-Spam-Level: X-Spam-Status: No, score=-5.213 tagged_above=-999 required=5 tests=[AWL=1.386, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8FmK0xp2UnO for ; Mon, 14 Apr 2008 06:38:07 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 8684D3A6DE3 for ; Mon, 14 Apr 2008 06:38:06 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m3EDcPOd023113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 15:38:25 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m3EDcLrU010516; Mon, 14 Apr 2008 15:38:21 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Apr 2008 15:38:21 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Date: Mon, 14 Apr 2008 15:38:19 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Confirmation of Implementation and Drafting plans WAS:RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems Thread-Index: AciUzt/qnNaeOgddTcyfe29+X5lQuwJPnACAAAckpkAAAaiIsAAAga7A References: <00f001c89e2b$26430d50$6502a8c0@china.huawei.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "David B Harrington" X-OriginalArrivalTime: 14 Apr 2008 13:38:21.0126 (UTC) FILETIME=[CDF9FE60:01C89E34] Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of Implementation and Drafting plans WAS:RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi David, the RFC text you copied states also: "However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation." I think this is inline with Dan's statement below. If there is nobody with interest or plans to implement a standard track document the WG item becomes questionable. OTOH: We are not that bad! As discussed in the session we have already a few individuals who implemented or plan to implement. Bert and myself, we would like to have a confirmation to close the action point. Cheers, Mehmet > -----Original Message----- > From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Monday, April 14, 2008 3:13 PM > To: David B Harrington; Ersue, Mehmet (NSN - DE/Muenich); > netconf@ietf.org > Subject: RE: [Netconf] Confirmation of Implementation and > Drafting plansWAS:RE: Summary of the NETCONF WG Session in > IETF 71 and ActionItems > > David, > > You are correct - this formal requirement comes later. We > need at least > two implementations with different code bases and demonstrate > interoperability to advance a document from Proposed to > Draft. However, > I believe that requiring at least a declaration of intent from two > different entities (vendors, open code implementers, etc.) in order to > charter a work as standards track and then ask the IESG to approve a > document as PS is quite in tune with this formal process requirement > that comes later. > > Dan > > > > -----Original Message----- > > From: netconf-bounces@ietf.org > > [mailto:netconf-bounces@ietf.org] On Behalf Of David B Harrington > > Sent: Monday, April 14, 2008 3:29 PM > > To: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org > > Subject: Re: [Netconf] Confirmation of Implementation and > > Drafting plansWAS:RE: Summary of the NETCONF WG Session in > > IETF 71 and ActionItems > > > > Hi, > > > > > PS: As you know we need _at least_ two implementations for > > a standard > > > track document. > > > > Can you identify the RFC that describes the standards process > > that has this requirement? I thought we were developing > > standards according to the IETF standards process as > > documented in RFC2026: > > > > " A Proposed Standard specification is generally stable, > has resolved > > known design choices, is believed to be well-understood, > > has received > > significant community review, and appears to enjoy > enough community > > interest to be considered valuable. However, further experience > > might result in a change or even retraction of the specification > > before it advances. > > > > Usually, neither implementation nor operational experience is > > required for the designation of a specification as a Proposed > > Standard. However, such experience is highly desirable, and will > > usually represent a strong argument in favor of a > Proposed Standard > > designation." > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > dharrington@huawei.com > > > > > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 14 06:38:08 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825803A6E95; Mon, 14 Apr 2008 06:38:08 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8AA3A6E70 for ; Mon, 14 Apr 2008 06:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.213 X-Spam-Level: X-Spam-Status: No, score=-5.213 tagged_above=-999 required=5 tests=[AWL=1.386, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8FmK0xp2UnO for ; Mon, 14 Apr 2008 06:38:07 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 8684D3A6DE3 for ; Mon, 14 Apr 2008 06:38:06 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m3EDcPOd023113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 15:38:25 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m3EDcLrU010516; Mon, 14 Apr 2008 15:38:21 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Apr 2008 15:38:21 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Date: Mon, 14 Apr 2008 15:38:19 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Confirmation of Implementation and Drafting plans WAS:RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems Thread-Index: AciUzt/qnNaeOgddTcyfe29+X5lQuwJPnACAAAckpkAAAaiIsAAAga7A References: <00f001c89e2b$26430d50$6502a8c0@china.huawei.com> From: "Ersue, Mehmet (NSN - DE/Muenich)" To: "David B Harrington" X-OriginalArrivalTime: 14 Apr 2008 13:38:21.0126 (UTC) FILETIME=[CDF9FE60:01C89E34] Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of Implementation and Drafting plans WAS:RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi David, the RFC text you copied states also: "However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation." I think this is inline with Dan's statement below. If there is nobody with interest or plans to implement a standard track document the WG item becomes questionable. OTOH: We are not that bad! As discussed in the session we have already a few individuals who implemented or plan to implement. Bert and myself, we would like to have a confirmation to close the action point. Cheers, Mehmet > -----Original Message----- > From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Monday, April 14, 2008 3:13 PM > To: David B Harrington; Ersue, Mehmet (NSN - DE/Muenich); > netconf@ietf.org > Subject: RE: [Netconf] Confirmation of Implementation and > Drafting plansWAS:RE: Summary of the NETCONF WG Session in > IETF 71 and ActionItems > > David, > > You are correct - this formal requirement comes later. We > need at least > two implementations with different code bases and demonstrate > interoperability to advance a document from Proposed to > Draft. However, > I believe that requiring at least a declaration of intent from two > different entities (vendors, open code implementers, etc.) in order to > charter a work as standards track and then ask the IESG to approve a > document as PS is quite in tune with this formal process requirement > that comes later. > > Dan > > > > -----Original Message----- > > From: netconf-bounces@ietf.org > > [mailto:netconf-bounces@ietf.org] On Behalf Of David B Harrington > > Sent: Monday, April 14, 2008 3:29 PM > > To: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org > > Subject: Re: [Netconf] Confirmation of Implementation and > > Drafting plansWAS:RE: Summary of the NETCONF WG Session in > > IETF 71 and ActionItems > > > > Hi, > > > > > PS: As you know we need _at least_ two implementations for > > a standard > > > track document. > > > > Can you identify the RFC that describes the standards process > > that has this requirement? I thought we were developing > > standards according to the IETF standards process as > > documented in RFC2026: > > > > " A Proposed Standard specification is generally stable, > has resolved > > known design choices, is believed to be well-understood, > > has received > > significant community review, and appears to enjoy > enough community > > interest to be considered valuable. However, further experience > > might result in a change or even retraction of the specification > > before it advances. > > > > Usually, neither implementation nor operational experience is > > required for the designation of a specification as a Proposed > > Standard. However, such experience is highly desirable, and will > > usually represent a strong argument in favor of a > Proposed Standard > > designation." > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > dharrington@huawei.com > > > > > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 14 08:12:46 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF143A6BD4; Mon, 14 Apr 2008 08:12:46 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8A23A6BD2 for ; Mon, 14 Apr 2008 08:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.256 X-Spam-Level: X-Spam-Status: No, score=-1.256 tagged_above=-999 required=5 tests=[AWL=1.343, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkgSL9lEZGSm for ; Mon, 14 Apr 2008 08:12:44 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id AAD913A6AFF for ; Mon, 14 Apr 2008 08:12:43 -0700 (PDT) Received: (qmail 55558 invoked from network); 14 Apr 2008 15:13:13 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 14 Apr 2008 15:13:13 -0000 From: "Bert Wijnen - IETF" To: Date: Mon, 14 Apr 2008 17:13:15 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B413E7A825@zcarhxm2.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org WG members, I have only seen Phil Shafer and Tom Pech speak up on this topic. I have difficulty determining WG consensus on this topic if we do not get more responses aka - I agree with the change - I see issues: (with details) - I don't care. As stated in an earlier email, your current WG chairs will not take silence as a signal of consent. PLEASE DO speak out what your opinion is. Bert Wijnen notifications document shepherd (and co-chair) > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > Sharon Chisholm > Verzonden: vrijdag 4 april 2008 21:24 > Aan: netconf@ietf.org > Onderwerp: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: > DateTime > > > Hi > > There are no objections to mandating use of time zone in eventTime? > > Sharon > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Chisholm, Sharon (CAR:ZZ00) > Sent: Wednesday, April 02, 2008 1:12 PM > To: netconf@ietf.org > Subject: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime > > Hi > > This is one of the discuss topics on the notification draft. This will > potentially result in two changes > - Additional reference (to point to specifications that indicate how > dateTime provides sufficient precision) > - Adding a statement, if the working group agrees, that makes > supporting time zone mandatory. > > Sharon > > -----Original Message----- > From: Chisholm, Sharon (CAR:ZZ00) > Sent: Wednesday, April 02, 2008 12:25 PM > To: 'Chris Newman'; 'dwaFrom netconf-bounces@ietf.org Mon Apr 14 08:12:46 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF143A6BD4; Mon, 14 Apr 2008 08:12:46 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8A23A6BD2 for ; Mon, 14 Apr 2008 08:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.256 X-Spam-Level: X-Spam-Status: No, score=-1.256 tagged_above=-999 required=5 tests=[AWL=1.343, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkgSL9lEZGSm for ; Mon, 14 Apr 2008 08:12:44 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id AAD913A6AFF for ; Mon, 14 Apr 2008 08:12:43 -0700 (PDT) Received: (qmail 55558 invoked from network); 14 Apr 2008 15:13:13 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 14 Apr 2008 15:13:13 -0000 From: "Bert Wijnen - IETF" To: Date: Mon, 14 Apr 2008 17:13:15 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B413E7A825@zcarhxm2.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org WG members, I have only seen Phil Shafer and Tom Pech speak up on this topic. I have difficulty determining WG consensus on this topic if we do not get more responses aka - I agree with the change - I see issues: (with details) - I don't care. As stated in an earlier email, your current WG chairs will not take silence as a signal of consent. PLEASE DO speak out what your opinion is. Bert Wijnen notifications document shepherd (and co-chair) > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > Sharon Chisholm > Verzonden: vrijdag 4 april 2008 21:24 > Aan: netconf@ietf.org > Onderwerp: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: > DateTime > > > Hi > > There are no objections to mandating use of time zone in eventTime? > > Sharon > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Chisholm, Sharon (CAR:ZZ00) > Sent: Wednesday, April 02, 2008 1:12 PM > To: netconf@ietf.org > Subject: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime > > Hi > > This is one of the discuss topics on the notification draft. This will > potentially result in two changes > - Additional reference (to point to specifications that indicate how > dateTime provides sufficient precision) > - Adding a statement, if the working group agrees, that makes > supporting time zone mandatory. > > Sharon > > -----Original Message----- > From: Chisholm, Sharon (CAR:ZZ00) > Sent: Wednesday, April 02, 2008 12:25 PM > To: 'Chris Newman'rd@cisco.com' > Cc: 'Hector Trevino (htrevino)'; 'Bert Wijnen - IETF'; 'Ersue, Mehmet > (NSN - DE/Muenich)'; 'Dan Romascanu' > Subject: Netconf Notification: Issues 8 & 18: DateTime > > Please reply to this email either indicating that you consider this > issue resolved or by providing additional feedback as to why the > response is not sufficient. > > > 18. Discuss: dateTime (David Ward) > [2008-03-26] ** All of the time references are in "type dateTime" which > is XMLschema speak is "YYYY-MM-DDThh:mm:ss" (although there is no > reference). > > Given the output of config events from networking nodes can happen at an > incredible rate, why is it felt that seconds are a satisfactory > granularity? Most vendors are in fact already implementing event down to > the ms. This is critical for fault messages. It is impossible to > understand what is happening on a network node with the granularity of > seconds. > > 8. dateTime (Chris Newman) > > The dateTime XML schema data type makes the timezone optional, in which > case time stamps are ambiguous and non-interoperable. This document > needs to explicitly require that timezones be present in order to > interoperate. I observe that dateTime does permit arbitrary fractions > of a second so I do not agree with Dave Ward's DISCUSS on the accuracy > issue, however he's right that a normative reference to XML schema data > types is necessary to clarify this and should be referenced when the > "dateTime" data type is first mentioned. RFC 3339 discusses these > issues in more detail. > > > There is no restriction as to the number of decimal digits. We'll add a > reference to XML XL documentation and to RFC 3339. > > FROM ISO 8601 > If necessary for a particular application a decimal fraction of hour, > minute or second may be included. If a decimal fraction is included, > lower order time elements (if any) shall be omitted and the decimal > fraction shall be divided from the integer part by the decimal sign > specified in ISO 31-0, i.e. the comma [,] or full stop [.]. Of these, > the comma is the preferred sign. If the magnitude of the number is less > than unity, the decimal sign shall be preceded by two zeros in > accordance with 3.6. > The interchange parties, dependent upon the application, shall agree the > number of digits in the decimal fraction. The format shall be > [hhmmss,ss], [hhmm,mm] or [hh,hh] as appropriate (hour minute second, > hour minute, and hour, respectively), with as many digits as necessary > following the decimal sign. A decimal fraction shall have at least one > digit. In the examples below it has been agreed to give the smallest > time element a decimal fraction with one digit. > > As for the timezone issue, I know in the past we have discussed whether > or not you could mandate use of timezones. At the time it was felt there > were machines that would be unable to support this feature. Keep in mind > that this solution needs to work on smaller, lower-end boxes as well as > fancy ones. Adding text mandating use of timezones would need to be > approved by the working group. Assuming the working group agrees, I have > no problem adding this text. > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ; 'dward@cisco.com' > Cc: 'Hector Trevino (htrevino)'; 'Bert Wijnen - IETF'; 'Ersue, Mehmet > (NSN - DE/Muenich)'; 'Dan Romascanu' > Subject: Netconf Notification: Issues 8 & 18: DateTime > > Please reply to this email either indicating that you consider this > issue resolved or by providing additional feedback as to why the > response is not sufficient. > > > 18. Discuss: dateTime (David Ward) > [2008-03-26] ** All of the time references are in "type dateTime" which > is XMLschema speak is "YYYY-MM-DDThh:mm:ss" (although there is no > reference). > > Given the output of config events from networking nodes can happen at an > incredible rate, why is it felt that seconds are a satisfactory > granularity? Most vendors are in fact already implementing event down to > the ms. This is critical for fault messages. It is impossible to > understand what is happening on a network node with the granularity of > seconds. > > 8. dateTime (Chris Newman) > > The dateTime XML schema data type makes the timezone optional, in which > case time stamps are ambiguous and non-interoperable. This document > needs to explicitly require that timezones be present in order to > interoperate. I observe that dateTime does permit arbitrary fractions > of a second so I do not agree with Dave Ward's DISCUSS on the accuracy > issue, however he's right that a normative reference to XML schema data > types is necessary to clarify this and should be referenced when the > "dateTime" data type is first mentioned. RFC 3339 discusses these > issues in more detail. > > > There is no restriction as to the number of decimal digits. We'll add a > reference to XML XL documentation and to RFC 3339. > > FROM ISO 8601 > If necessary for a particular application a decimal fraction of hour, > minute or second may be included. If a decimal fraction is included, > lower order time elements (if any) shall be omitted and the decimal > fraction shall be divided from the integer part by the decimal sign > specified in ISO 31-0, i.e. the comma [,] or full stop [.]. Of these, > the comma is the preferred sign. If the magnitude of the number is less > than unity, the decimal sign shall be preceded by two zeros in > accordance with 3.6. > The interchange parties, dependent upon the application, shall agree the > number of digits in the decimal fraction. The format shall be > [hhmmss,ss], [hhmm,mm] or [hh,hh] as appropriate (hour minute second, > hour minute, and hour, respectively), with as many digits as necessary > following the decimal sign. A decimal fraction shall have at least one > digit. In the examples below it has been agreed to give the smallest > time element a decimal fraction with one digit. > > As for the timezone issue, I know in the past we have discussed whether > or not you could mandate use of timezones. At the time it was felt there > were machines that would be unable to support this feature. Keep in mind > that this solution needs to work on smaller, lower-end boxes as well as > fancy ones. Adding text mandating use of timezones would need to be > approved by the working group. Assuming the working group agrees, I have > no problem adding this text. > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 14 08:13:55 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA99E28C30B; Mon, 14 Apr 2008 08:13:55 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E064028C30B for ; Mon, 14 Apr 2008 08:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k2mUpeL2AqG for ; Mon, 14 Apr 2008 08:13:52 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 9739A28C301 for ; Mon, 14 Apr 2008 08:13:51 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA10.westchester.pa.mail.comcast.net with comcast id DQ561Z0021GhbT85A0GG00; Mon, 14 Apr 2008 15:13:16 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA07.westchester.pa.mail.comcast.net with comcast id DTEF1Z0064HwxpC3T00000; Mon, 14 Apr 2008 15:14:19 +0000 X-Authority-Analysis: v=1.0 c=1 a=wCYW7-4fSC8A:10 a=QEOogkkYNQEA:10 a=48vgC7mUAAAA:8 a=CSneS6Jsfd8cFJmJeLoA:9 a=7lRs8BZg5pGkkPWRlgMA:7 a=gjGifNSTNgYtuy5VhDip3KpXfOgA:4 a=zwC7bnKO5xoA:10 a=lZB815dzVvQA:10 a=4dyfk4FV-b8A:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Ersue, Mehmet \(NSN - DE/Muenich\)'" References: <00f001c89e2b$26430d50$6502a8c0@china.huawei.com> Date: Mon, 14 Apr 2008 11:14:15 -0400 Message-ID: <011401c89e42$33f19680$6502a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: thread-index: AciUzt/qnNaeOgddTcyfe29+X5lQuwJPnACAAAckpkAAAaiIsAAAga7AAAJ8RDA= Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of Implementation and Drafting plans WAS:RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I understand the desire. I wanted to clarify that the WG does not "need" to have commitments for two implementations; the WG chairs (and presumably the WG) "wants" commitment for two implementations. I think it is important to keep what is required for proposed standard and what is desired distinct. That is my point. As Bert observes in one of his responses, other implementations may come later. I have a concern about "shutting down" work based on the fact that people on the list are not currently committing to implementation plans. Some people cannot speak for their company and are not personally implementing. I know that Huawei engineers are constrained by strong IT security policies, and are not allowed to implement as part of their daily work, so they cannot honestly make such commitments to implement. That does not mean they are not interested in the standards effort, and they could contribute toward developing a specification that is "generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable." Are there any rules to these commitments? Nortel has three commitments to implement. Is that enough, even if no other vendor commits to do so? Does a commitment include a commitment to "ship it in product" or just prototypes? The issue is that the chairs, by **requiring** such commitments, significantly raise the entry costs for participation in this WG. I am not sure that is a good thing to do to ensure a process that is fair and open to all, which follows IETF-established guidelines for process, and to ensure vendor-neutral standards; I think this approach favors certain companies. I do not object to chairs trying to determine consensus for each proposal; that is their job. I do not object to chairs constraining the scope to try to ensure we finish the work and don't try to boil the ocean. But when the chairs say that two commitments are **needed** for standards-track proposals, I believe that is not consistent with IETF policy. dbh > -----Original Message----- > From: Ersue, Mehmet (NSN - DE/Muenich) [mailto:mehmet.ersue@nsn.com] > Sent: Monday, April 14, 2008 9:38 AM > To: David B Harrington > Cc: ext Romascanu, Dan (Dan); netconf@ietf.org; ext Bert Wijnen - IETF > Subject: RE: [Netconf] Confirmation of Implementation and > Drafting plans WAS:RE: Summary of the NETCONF WG Session in > IETF 71 and ActionItems > > > Hi David, > > the RFC text you copied states also: > "However, such experience is highly desirable, and will usually > represent a strong argument in favor of a Proposed Standard > designation." > > I think this is inline with Dan's statement below. If there is > nobody with interest or plans to implement a standard track > document the WG item becomes questionable. > > OTOH: We are not that bad! As discussed in the session we have > already a few individuals who implemented or plan to implement. > Bert and myself, we would like to have a confirmation to close the > action point. > > Cheers, > Mehmet > > > > -----Original Message----- > > From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Monday, April 14, 2008 3:13 PM > > To: David B Harrington; Ersue, Mehmet (NSN - DE/Muenich); > > netconf@ietf.org > > Subject: RE: [Netconf] Confirmation of Implementation and > > Drafting plansWAS:RE: Summary of the NETCONF WG Session in > > IETF 71 and ActionItems > > > > David, > > > > You are correct - this formal requirement comes later. We > > need at least > > two implementations with different code bases and demonstrate > > interoperability to advance a document from Proposed to > > Draft. However, > > I believe that requiring at least a declaration of intent from two > > different entities (vendors, open code implementers, etc.) > in order to > > charter a work as standards track and then ask the IESG to approve a > > document as PS is quite in tune with this formal process requirement > > that comes later. > > > > Dan > > > > > > > -----Original Message----- > > > From: netconf-bounces@ietf.org > > > [mailto:netconf-bounces@ietf.org] On Behalf Of David B Harrington > > > Sent: Monday, April 14, 2008 3:29 PM > > > To: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org > > > Subject: Re: [Netconf] Confirmation of Implementation and > > > Drafting plansWAS:RE: Summary of the NETCONF WG Session in > > > IETF 71 and ActionItems > > > > > > Hi, > > > > > > > PS: As you know we need _at least_ two implementations for > > > a standard > > > > track document. > > > > > > Can you identify the RFC that describes the standards process > > > that has this requirement? I thought we were developing > > > standards according to the IETF standards process as > > > documented in RFC2026: > > > > > > " A Proposed Standard specification is generally stable, > > has resolved > > > known design choices, is believed to be well-understood, > > > has received > > > significant community review, and appears to enjoy > > enough community > > > interest to be considered valuable. However, further > experience > > > might result in a change or even retraction of the > specification > > > before it advances. > > > > > > Usually, neither implementation nor operational experience is > > > required for the designation of a specification as a Proposed > > > Standard. However, such experience is highly > desirable, and will > > > usually represent a strong argument in favor of a > > Proposed Standard > > > designation." > > > > > > David Harrington > > > dbharrington@comcast.net > > > ietfdbh@comcast.net > > > dharrington@huawei.com > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 14 08:13:55 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA99E28C30B; Mon, 14 Apr 2008 08:13:55 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E064028C30B for ; Mon, 14 Apr 2008 08:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k2mUpeL2AqG for ; Mon, 14 Apr 2008 08:13:52 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 9739A28C301 for ; Mon, 14 Apr 2008 08:13:51 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA10.westchester.pa.mail.comcast.net with comcast id DQ561Z0021GhbT85A0GG00; Mon, 14 Apr 2008 15:13:16 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA07.westchester.pa.mail.comcast.net with comcast id DTEF1Z0064HwxpC3T00000; Mon, 14 Apr 2008 15:14:19 +0000 X-Authority-Analysis: v=1.0 c=1 a=wCYW7-4fSC8A:10 a=QEOogkkYNQEA:10 a=48vgC7mUAAAA:8 a=CSneS6Jsfd8cFJmJeLoA:9 a=7lRs8BZg5pGkkPWRlgMA:7 a=gjGifNSTNgYtuy5VhDip3KpXfOgA:4 a=zwC7bnKO5xoA:10 a=lZB815dzVvQA:10 a=4dyfk4FV-b8A:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Ersue, Mehmet \(NSN - DE/Muenich\)'" References: <00f001c89e2b$26430d50$6502a8c0@china.huawei.com> Date: Mon, 14 Apr 2008 11:14:15 -0400 Message-ID: <011401c89e42$33f19680$6502a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: thread-index: AciUzt/qnNaeOgddTcyfe29+X5lQuwJPnACAAAckpkAAAaiIsAAAga7AAAJ8RDA= Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of Implementation and Drafting plans WAS:RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I understand the desire. I wanted to clarify that the WG does not "need" to have commitments for two implementations; the WG chairs (and presumably the WG) "wants" commitment for two implementations. I think it is important to keep what is required for proposed standard and what is desired distinct. That is my point. As Bert observes in one of his responses, other implementations may come later. I have a concern about "shutting down" work based on the fact that people on the list are not currently committing to implementation plans. Some people cannot speak for their company and are not personally implementing. I know that Huawei engineers are constrained by strong IT security policies, and are not allowed to implement as part of their daily work, so they cannot honestly make such commitments to implement. That does not mean they are not interested in the standards effort, and they could contribute toward developing a specification that is "generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable." Are there any rules to these commitments? Nortel has three commitments to implement. Is that enough, even if no other vendor commits to do so? Does a commitment include a commitment to "ship it in product" or just prototypes? The issue is that the chairs, by **requiring** such commitments, significantly raise the entry costs for participation in this WG. I am not sure that is a good thing to do to ensure a process that is fair and open to all, which follows IETF-established guidelines for process, and to ensure vendor-neutral standards; I think this approach favors certain companies. I do not object to chairs trying to determine consensus for each proposal; that is their job. I do not object to chairs constraining the scope to try to ensure we finish the work and don't try to boil the ocean. But when the chairs say that two commitments are **needed** for standards-track proposals, I believe that is not consistent with IETF policy. dbh > -----Original Message----- > From: Ersue, Mehmet (NSN - DE/Muenich) [mailto:mehmet.ersue@nsn.com] > Sent: Monday, April 14, 2008 9:38 AM > To: David B Harrington > Cc: ext Romascanu, Dan (Dan); netconf@ietf.org; ext Bert Wijnen - IETF > Subject: RE: [Netconf] Confirmation of Implementation and > Drafting plans WAS:RE: Summary of the NETCONF WG Session in > IETF 71 and ActionItems > > > Hi David, > > the RFC text you copied states also: > "However, such experience is highly desirable, and will usually > represent a strong argument in favor of a Proposed Standard > designation." > > I think this is inline with Dan's statement below. If there is > nobody with interest or plans to implement a standard track > document the WG item becomes questionable. > > OTOH: We are not that bad! As discussed in the session we have > already a few individuals who implemented or plan to implement. > Bert and myself, we would like to have a confirmation to close the > action point. > > Cheers, > Mehmet > > > > -----Original Message----- > > From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Monday, April 14, 2008 3:13 PM > > To: David B Harrington; Ersue, Mehmet (NSN - DE/Muenich); > > netconf@ietf.org > > Subject: RE: [Netconf] Confirmation of Implementation and > > Drafting plansWAS:RE: Summary of the NETCONF WG Session in > > IETF 71 and ActionItems > > > > David, > > > > You are correct - this formal requirement comes later. We > > need at least > > two implementations with different code bases and demonstrate > > interoperability to advance a document from Proposed to > > Draft. However, > > I believe that requiring at least a declaration of intent from two > > different entities (vendors, open code implementers, etc.) > in order to > > charter a work as standards track and then ask the IESG to approve a > > document as PS is quite in tune with this formal process requirement > > that comes later. > > > > Dan > > > > > > > -----Original Message----- > > > From: netconf-bounces@ietf.org > > > [mailto:netconf-bounces@ietf.org] On Behalf Of David B Harrington > > > Sent: Monday, April 14, 2008 3:29 PM > > > To: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org > > > Subject: Re: [Netconf] Confirmation of Implementation and > > > Drafting plansWAS:RE: Summary of the NETCONF WG Session in > > > IETF 71 and ActionItems > > > > > > Hi, > > > > > > > PS: As you know we need _at least_ two implementations for > > > a standard > > > > track document. > > > > > > Can you identify the RFC that describes the standards process > > > that has this requirement? I thought we were developing > > > standards according to the IETF standards process as > > > documented in RFC2026: > > > > > > " A Proposed Standard specification is generally stable, > > has resolved > > > known design choices, is believed to be well-understood, > > > has received > > > significant community review, and appears to enjoy > > enough community > > > interest to be considered valuable. However, further > experience > > > might result in a change or even retraction of the > specification > > > before it advances. > > > > > > Usually, neither implementation nor operational experience is > > > required for the designation of a specification as a Proposed > > > Standard. However, such experience is highly > desirable, and will > > > usually represent a strong argument in favor of a > > Proposed Standard > > > designation." > > > > > > David Harrington > > > dbharrington@comcast.net > > > ietfdbh@comcast.net > > > dharrington@huawei.com > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 14 09:21:31 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4FF28C2EB; Mon, 14 Apr 2008 09:21:31 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEA9E3A67D8 for ; Mon, 14 Apr 2008 09:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[AWL=1.279, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xenY4HWOq5J for ; Mon, 14 Apr 2008 09:21:25 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 4EB6328C15D for ; Mon, 14 Apr 2008 09:21:23 -0700 (PDT) Received: (qmail 97957 invoked from network); 14 Apr 2008 16:21:54 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 14 Apr 2008 16:21:54 -0000 From: "Bert Wijnen - IETF" To: "David B Harrington" , "'Ersue, Mehmet \(NSN - DE/Muenich\)'" Date: Mon, 14 Apr 2008 18:21:55 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <011401c89e42$33f19680$6502a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of Implementation and Drafting plans WAS:RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dave, we (WG co-chairs) are not trying to raise the (formal) bar at all. But we want to make sure that whatever work the WG is doing makes sense. As such, we asked for people to let us know about "implementation plans" for each of the work items (documents). Pls note the word PLAN. That is nto a commitment. But we also assume it is not a lightly made statement and then forgotten about. We do understand that an "implementation plan" can get trashed/canceled (for all sorts of reasons). And if such happens, then too bad. W.r.t. people not wanting to state any plans in public, we have offered that such people can send the info to the WG chairs and we commit (note the word COMMIT) that we will NOT disclose that information and count it as a "plan to implement by annonymous A" (if we have many, we can have B, C, D etc. The more we have, the more it seems that the work we are doing makes sense. We have CERTAINLY not asked to make commitments to have implementations complete by the time that we want to publish a document as RFC (at PS). As you state, that would be outside of the normal requirements (RTG area does have such a requirment thoug, so if needed we could see if we would want to require that too; but I do not see a need for that). Hope this helps/explains. Bert Wijnen > -----Oorspronkelijk bericht----- > Van: David B Harrington [mailto:dbharrington@comcast.net] > Verzonden: maandag 1From netconf-bounces@ietf.org Mon Apr 14 09:21:31 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4FF28C2EB; Mon, 14 Apr 2008 09:21:31 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEA9E3A67D8 for ; Mon, 14 Apr 2008 09:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[AWL=1.279, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xenY4HWOq5J for ; Mon, 14 Apr 2008 09:21:25 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 4EB6328C15D for ; Mon, 14 Apr 2008 09:21:23 -0700 (PDT) Received: (qmail 97957 invoked from network); 14 Apr 2008 16:21:54 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 14 Apr 2008 16:21:54 -0000 From: "Bert Wijnen - IETF" To: "David B Harrington" , "'Ersue, Mehmet \(NSN - DE/Muenich\)'" Date: Mon, 14 Apr 2008 18:21:55 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <011401c89e42$33f19680$6502a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of Implementation and Drafting plans WAS:RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dave, we (WG co-chairs) are not trying to raise the (formal) bar at all. But we want to make sure that whatever work the WG is doing makes sense. As such, we asked for people to let us know about "implementation plans" for each of the work items (documents). Pls note the word PLAN. That is nto a commitment. But we also assume it is not a lightly made statement and then forgotten about. We do understand that an "implementation plan" can get trashed/canceled (for all sorts of reasons). And if such happens, then too bad. W.r.t. people not wanting to state any plans in public, we have offered that such people can send the info to the WG chairs and we commit (note the word COMMIT) that we will NOT disclose that information and count it as a "plan to implement by annonymous A" (if we have many, we can have B, C, D etc. The more we have, the more it seems that the work we are doing makes sense. We have CERTAINLY not asked to make commitments to have implementations complete by the time that we want to publish a document as RFC (at PS). As you state, that would be outside of the normal requirements (RTG area does have such a requirment thoug, so if needed we could see if we would want to require that too; but I do not see a need for that). Hope this helps/explains. Bert Wijnen > -----Oorspronkelijk bericht----- > Van: David B Harrington [mailto:dbharrington@comcast.net] > Verzonden: maa4 april 2008 17:14 > Aan: 'Ersue, Mehmet (NSN - DE/Muenich)' > CC: 'ext Romascanu, Dan (Dan)'; netconf@ietf.org; 'ext Bert Wijnen - > IETF' > Onderwerp: RE: [Netconf] Confirmation of Implementation and Drafting > plans WAS:RE: Summary of the NETCONF WG Session in IETF 71 and > ActionItems > > > Hi, > > I understand the desire. I wanted to clarify that the WG does not > "need" to have commitments for two implementations; the WG chairs (and > presumably the WG) "wants" commitment for two implementations. I think > it is important to keep what is required for proposed standard and > what is desired distinct. That is my point. > > As Bert observes in one of his responses, other implementations may > come later. I have a concern about "shutting down" work based on the > fact that people on the list are not currently committing to > implementation plans. Some people cannot speak for their company and > are not personally implementing. > > I know that Huawei engineers are constrained by strong IT security > policies, and are not allowed to implement as part of their daily > work, so they cannot honestly make such commitments to implement. That > does not mean they are not interested in the standards effort, and > they could contribute toward developing a specification that is > "generally stable, has resolved known design choices, is believed to > be well-understood, has received significant community review, and > appears to enjoy enough community interest to be considered valuable." > > > Are there any rules to these commitments? Nortel has three commitments > to implement. Is that enough, even if no other vendor commits to do > so? Does a commitment include a commitment to "ship it in product" or > just prototypes? > > The issue is that the chairs, by **requiring** such commitments, > significantly raise the entry costs for participation in this WG. I am > not sure that is a good thing to do to ensure a process that is fair > and open to all, which follows IETF-established guidelines for > process, and to ensure vendor-neutral standards; I think this approach > favors certain companies. > > I do not object to chairs trying to determine consensus for each > proposal; that is their job. I do not object to chairs constraining > the scope to try to ensure we finish the work and don't try to boil > the ocean. But when the chairs say that two commitments are **needed** > for standards-track proposals, I believe that is not consistent with > IETF policy. > > dbh > > > -----Original Message----- > > From: Ersue, Mehmet (NSN - DE/Muenich) [mailto:mehmet.ersue@nsn.com] > > > Sent: Monday, April 14, 2008 9:38 AM > > To: David B Harrington > > Cc: ext Romascanu, Dan (Dan); netconf@ietf.org; ext Bert Wijnen - > IETF > > Subject: RE: [Netconf] Confirmation of Implementation and > > Drafting plans WAS:RE: Summary of the NETCONF WG Session in > > IETF 71 and ActionItems > > > > > > Hi David, > > > > the RFC text you copied states also: > > "However, such experience is highly desirable, and will usually > > represent a strong argument in favor of a Proposed Standard > > designation." > > > > I think this is inline with Dan's statement below. If there is > > nobody with interest or plans to implement a standard track > > document the WG item becomes questionable. > > > > OTOH: We are not that bad! As discussed in the session we have > > already a few individuals who implemented or plan to implement. > > Bert and myself, we would like to have a confirmation to close the > > action point. > > > > Cheers, > > Mehmet > > > > > > > -----Original Message----- > > > From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > Sent: Monday, April 14, 2008 3:13 PM > > > To: David B Harrington; Ersue, Mehmet (NSN - DE/Muenich); > > > netconf@ietf.org > > > Subject: RE: [Netconf] Confirmation of Implementation and > > > Drafting plansWAS:RE: Summary of the NETCONF WG Session in > > > IETF 71 and ActionItems > > > > > > David, > > > > > > You are correct - this formal requirement comes later. We > > > need at least > > > two implementations with different code bases and demonstrate > > > interoperability to advance a document from Proposed to > > > Draft. However, > > > I believe that requiring at least a declaration of intent from two > > > different entities (vendors, open code implementers, etc.) > > in order to > > > charter a work as standards track and then ask the IESG to approve > a > > > document as PS is quite in tune with this formal process > requirement > > > that comes later. > > > > > > Dan > > > > > > > > > > -----Original Message----- > > > > From: netconf-bounces@ietf.org > > > > [mailto:netconf-bounces@ietf.org] On Behalf Of David B > Harrington > > > > Sent: Monday, April 14, 2008 3:29 PM > > > > To: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org > > > > Subject: Re: [Netconf] Confirmation of Implementation and > > > > Drafting plansWAS:RE: Summary of the NETCONF WG Session in > > > > IETF 71 and ActionItems > > > > > > > > Hi, > > > > > > > > > PS: As you know we need _at least_ two implementations for > > > > a standard > > > > > track document. > > > > > > > > Can you identify the RFC that describes the standards process > > > > that has this requirement? I thought we were developing > > > > standards according to the IETF standards process as > > > > documented in RFC2026: > > > > > > > > " A Proposed Standard specification is generally stable, > > > has resolved > > > > known design choices, is believed to be well-understood, > > > > has received > > > > significant community review, and appears to enjoy > > > enough community > > > > interest to be considered valuable. However, further > > experience > > > > might result in a change or even retraction of the > > specification > > > > before it advances. > > > > > > > > Usually, neither implementation nor operational experience is > > > > required for the designation of a specification as a Proposed > > > > Standard. However, such experience is highly > > desirable, and will > > > > usually represent a strong argument in favor of a > > > Proposed Standard > > > > designation." > > > > > > > > David Harrington > > > > dbharrington@comcast.net > > > > ietfdbh@comcast.net > > > > dharrington@huawei.com > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Netconf mailing list > > > > Netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ndag 14 april 2008 17:14 > Aan: 'Ersue, Mehmet (NSN - DE/Muenich)' > CC: 'ext Romascanu, Dan (Dan)'; netconf@ietf.org; 'ext Bert Wijnen - > IETF' > Onderwerp: RE: [Netconf] Confirmation of Implementation and Drafting > plans WAS:RE: Summary of the NETCONF WG Session in IETF 71 and > ActionItems > > > Hi, > > I understand the desire. I wanted to clarify that the WG does not > "need" to have commitments for two implementations; the WG chairs (and > presumably the WG) "wants" commitment for two implementations. I think > it is important to keep what is required for proposed standard and > what is desired distinct. That is my point. > > As Bert observes in one of his responses, other implementations may > come later. I have a concern about "shutting down" work based on the > fact that people on the list are not currently committing to > implementation plans. Some people cannot speak for their company and > are not personally implementing. > > I know that Huawei engineers are constrained by strong IT security > policies, and are not allowed to implement as part of their daily > work, so they cannot honestly make such commitments to implement. That > does not mean they are not interested in the standards effort, and > they could contribute toward developing a specification that is > "generally stable, has resolved known design choices, is believed to > be well-understood, has received significant community review, and > appears to enjoy enough community interest to be considered valuable." > > > Are there any rules to these commitments? Nortel has three commitments > to implement. Is that enough, even if no other vendor commits to do > so? Does a commitment include a commitment to "ship it in product" or > just prototypes? > > The issue is that the chairs, by **requiring** such commitments, > significantly raise the entry costs for participation in this WG. I am > not sure that is a good thing to do to ensure a process that is fair > and open to all, which follows IETF-established guidelines for > process, and to ensure vendor-neutral standards; I think this approach > favors certain companies. > > I do not object to chairs trying to determine consensus for each > proposal; that is their job. I do not object to chairs constraining > the scope to try to ensure we finish the work and don't try to boil > the ocean. But when the chairs say that two commitments are **needed** > for standards-track proposals, I believe that is not consistent with > IETF policy. > > dbh > > > -----Original Message----- > > From: Ersue, Mehmet (NSN - DE/Muenich) [mailto:mehmet.ersue@nsn.com] > > > Sent: Monday, April 14, 2008 9:38 AM > > To: David B Harrington > > Cc: ext Romascanu, Dan (Dan); netconf@ietf.org; ext Bert Wijnen - > IETF > > Subject: RE: [Netconf] Confirmation of Implementation and > > Drafting plans WAS:RE: Summary of the NETCONF WG Session in > > IETF 71 and ActionItems > > > > > > Hi David, > > > > the RFC text you copied states also: > > "However, such experience is highly desirable, and will usually > > represent a strong argument in favor of a Proposed Standard > > designation." > > > > I think this is inline with Dan's statement below. If there is > > nobody with interest or plans to implement a standard track > > document the WG item becomes questionable. > > > > OTOH: We are not that bad! As discussed in the session we have > > already a few individuals who implemented or plan to implement. > > Bert and myself, we would like to have a confirmation to close the > > action point. > > > > Cheers, > > Mehmet > > > > > > > -----Original Message----- > > > From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > Sent: Monday, April 14, 2008 3:13 PM > > > To: David B Harrington; Ersue, Mehmet (NSN - DE/Muenich); > > > netconf@ietf.org > > > Subject: RE: [Netconf] Confirmation of Implementation and > > > Drafting plansWAS:RE: Summary of the NETCONF WG Session in > > > IETF 71 and ActionItems > > > > > > David, > > > > > > You are correct - this formal requirement comes later. We > > > need at least > > > two implementations with different code bases and demonstrate > > > interoperability to advance a document from Proposed to > > > Draft. However, > > > I believe that requiring at least a declaration of intent from two > > > different entities (vendors, open code implementers, etc.) > > in order to > > > charter a work as standards track and then ask the IESG to approve > a > > > document as PS is quite in tune with this formal process > requirement > > > that comes later. > > > > > > Dan > > > > > > > > > > -----Original Message----- > > > > From: netconf-bounces@ietf.org > > > > [mailto:netconf-bounces@ietf.org] On Behalf Of David B > Harrington > > > > Sent: Monday, April 14, 2008 3:29 PM > > > > To: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org > > > > Subject: Re: [Netconf] Confirmation of Implementation and > > > > Drafting plansWAS:RE: Summary of the NETCONF WG Session in > > > > IETF 71 and ActionItems > > > > > > > > Hi, > > > > > > > > > PS: As you know we need _at least_ two implementations for > > > > a standard > > > > > track document. > > > > > > > > Can you identify the RFC that describes the standards process > > > > that has this requirement? I thought we were developing > > > > standards according to the IETF standards process as > > > > documented in RFC2026: > > > > > > > > " A Proposed Standard specification is generally stable, > > > has resolved > > > > known design choices, is believed to be well-understood, > > > > has received > > > > significant community review, and appears to enjoy > > > enough community > > > > interest to be considered valuable. However, further > > experience > > > > might result in a change or even retraction of the > > specification > > > > before it advances. > > > > > > > > Usually, neither implementation nor operational experience is > > > > required for the designation of a specification as a Proposed > > > > Standard. However, such experience is highly > > desirable, and will > > > > usually represent a strong argument in favor of a > > > Proposed Standard > > > > designation." > > > > > > > > David Harrington > > > > dbharrington@comcast.net > > > > ietfdbh@comcast.net > > > > dharrington@huawei.com > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Netconf mailing list > > > > Netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 14 10:03:07 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEC6D3A6D94; Mon, 14 Apr 2008 10:03:07 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3B5728C324 for ; Mon, 14 Apr 2008 10:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7VpSGxsp4ef for ; Mon, 14 Apr 2008 10:03:04 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 09AF028C2F6 for ; Mon, 14 Apr 2008 10:03:04 -0700 (PDT) Received: (qmail 67693 invoked from network); 14 Apr 2008 17:03:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.143.70 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 14 Apr 2008 17:03:33 -0000 X-YMail-OSG: mUCik1UVM1n30qBVYIVmleX7D7VH5051fXcnhi7eluy18SV2tEZdE9zlLVh0vsGT1RR6qg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48038E58.7010301@andybierman.com> Date: Mon, 14 Apr 2008 10:03:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Bert Wijnen - IETF References: In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of Implementation and Drafting plans WAS:RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Isn't this type of discussion more appropriate before the charter is approved? IMO, you both have valid arguments. The most relevant question is whether or not there are enough skilled people willing to write and review the document, and stay involved until the 'RFC Announcement' is sent. Since vendors with no plans to implement are also likely to ignore the document work, it seems relevant to ask about implementation plans. When a WG is developing 4 very different work items at once, you cannot expect that all the WG participants care about all the documents, or that people should be expected to work on documents they don't care about. Andy > Dave, > > we (WG co-chairs) are not trying to raise the (formal) bar at all. > But we want to make sure that whatever work the WG is doing makes > sense. As such, we asked for people to let us know about "implementation > plans" for each of the work items (documents). Pls note the word PLAN. > That is nto a commitment. But we also assume it is not a lightly made > statement and then forgotten about. We do understand that an "implementation > plan" can get trashed/canceled (for all sorts of reasons). And if such > happens, > then too bad. > > W.r.t. people not wanting to state any plans in public, we have offered that > such people can send the info to the WG chairs and we commit (note the word > COMMIT) that we will NOT disclose that information and count it as a > "plan to implement by annonymous A" (if we have many, we can have B, C, D > etc. > The more we have, the more it seems that the work we are doing makes sense. > > We have CERTAINLY not asked to make commitments to have implementations > complete by the time that we want to publish a document as RFC (at PS). > As you state, that would be outside of the normal requirements (RTG area > does have such a requirment thoug, so if needed we could see if we would > want to require that too; but I do not see a need for that). > > Hope this helps/explains. > > Bert Wijnen > >> -----Oorspronkelijk bericht----- >> Van: David B Harrington [mailto:dbharrington@comcast.net] >> Verzonden: maandag 14 april 2008 17:14 >> Aan: 'Ersue, Mehmet (NSN - DE/Muenich)' >> CC: 'ext Romascanu, Dan (Dan)'; netconf@ietf.org; 'ext Bert Wijnen - >> IETF' >> Onderwerp: RE: [Netconf] Confirmation of Implementation and Drafting >> plans WAS:RE: Summary of the NETCONF WG Session in IETF 71 and >> ActionItems >> >> >> Hi, >> >> I understand the desire. I wanted to clarify that the WG does not >> "need" to have commitments for two implementations; the WG chairs (and >> presumably the WG) "wants" commitment for two implementations. I think >> it is important to keep what is required for proposed standard and >> what is desired distinct. That is my point. >> >> As Bert observes in one of his responses, other implementations may >> come later. I have a concern about "shutting down" work based on the >> fact that people on the list are not currently committing to >> implementation plans. Some people cannot speak for their company and >> are not personally implementing. >> >> I know that Huawei engineers are constrained by strong IT security >> policies, and are not allowed to implement as part of their daily >> work, so they cannot honestly make such commitments to implement. That >> does not mean they are not interested in the standards effort, and >> they could contribute toward developing a specification that is >> "generally stable, has resolved known design choices, is believed to >> be well-understood, has received significant community review, and >> appears to enjoy enough community interest to be considered valuable." >> >> >> Are there any rules to these commitments? Nortel has three commitments >> to implement. Is that enough, even if no other vendor commits to do >> so? Does a commitment include a commitment to "ship it in product" or >> just prototypes? >> >> The issue is that the chairs, by **requiring** such commitments, >> significantly raise the entry costs for participation in this WG. I am >> not sure that is a good thing to do to ensure a process that is fair >> and open to all, which follows IETF-established guidelines for >> process, and to ensure vendor-neutral standards; I think this approach >> favors certain companies. >> >> I do not object to chairs trying to determine consensus for each >> proposal; that is their job. I do not object to chairs constraining >> the scope to try to ensure we finish the work and don't try to boil >> the ocean. But when the chairs say that two commitments are **needed** >> for standards-track proposals, I believe that is not consistent with >> IETF policy. >> >> dbh >> >>> -----Original Message----- >>> From: Ersue, Mehmet (NSN - DE/Muenich) [mailto:mehmet.ersue@nsn.com] >>> Sent: Monday, April 14, 2008 9:38 AM >>> To: David B Harrington >>> Cc: ext Romascanu, Dan (Dan); netconf@ietf.org; ext Bert Wijnen - >> IETF >>> Subject: RE: [Netconf] Confirmation of Implementation and >>> Drafting plans WAS:RE: Summary of the NETCONF WG Session in >>> IETF 71 and ActionItems >>> >>> >>> Hi David, >>> >>> the RFC text you copied states also: >>> "However, such experience is highly desirable, and will usually >>> represent a strong argument in favor of a Proposed Standard >>> designation." >>> >>> I think this is inline with Dan's statement below. If there is >>> nobody with interest or plans to implement a standard track >>> document the WG item becomes questionable. >>> >>> OTOH: We are not that bad! As discussed in the session we have >>> already a few individuals who implemented or plan to implement. >>> Bert and myself, we would like to have a confirmation to close the >>> action point. >>> >>> Cheers, >>> Mehmet >>> >>> >>>> -----Original Message----- >>>> From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] >>>> Sent: Monday, April 14, 2008 3:13 PM >>>> To: David B Harrington; Ersue, Mehmet (NSN - DE/Muenich); >>>> netconf@ietf.org >>>> Subject: RE: [Netconf] Confirmation of Implementation and >>>> Drafting plansWAS:RE: Summary of the NETCONF WG Session in >>>> IETF 71 and ActionItems >>>> >>>> David, >>>> >>>> You are correct - this formal requirement comes later. We >>>> need at least >>>> two implementations with different code bases and demonstrate >>>> interoperability to advance a document from Proposed to >>>> Draft. However, >>>> I believe that requiring at least a declaration of intent from two >>>> different entities (vendors, open code implementers, etc.) >>> in order to >>>> charter a work as standards track and then ask the IESG to approve >> a >>>> document as PS is quite in tune with this formal process >> requirement >>>> that comes later. >>>> >>>> Dan >>>> >>>> >>>>> -----Original Message----- >>>>> From: netconf-bounces@ietf.org >>>>> [mailto:netconf-bounces@ietf.org] On Behalf Of David B >> Harrington >>>>> Sent: Monday, April 14, 2008 3:29 PM >>>>> To: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org >>>>> Subject: Re: [Netconf] Confirmation of Implementation and >>>>> Drafting plansWAS:RE: Summary of the NETCONF WG Session in >>>>> IETF 71 and ActionItems >>>>> >>>>> Hi, >>>>> >>>>>> PS: As you know we need _at least_ two implementations for >>>>> a standard >>>>>> track document. >>>>> Can you identify the RFC that describes the standards process >>>>> that has this requirement? I thought we were developing >>>>> standards according to the IETF standards process as >>>>> documented in RFC2026: >>>>> >>>>> " A Proposed Standard specification is generally stable, >>>> has resolved >>>>> known design choices, is believed to be well-understood, >>>>> has received >>>>> significant community review, and appears to enjoy >>>> enough community >>>>> interest to be considered valuable. However, further >>> experience >>>>> might result in a change or even retraction of the >>> specification >>>>> before it advances. >>>>> >>>>> Usually, neither implementation nor operational experience is >>>>> required for the designation of a specification as a Proposed >>>>> Standard. However, such experience is highly >>> desirable, and will >>>>> usually represent a strong argument in favor of a >>>> Proposed Standard >>>>> designation." >>>>> >>>>> David Harrington >>>>> dbharrington@comcast.net >>>>> ietfdbh@comcast.net >>>>> dharrington@huawei.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Netconf mailing list >>>>> Netconf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netconf >>>>> >> >> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 14 10:03:07 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEC6D3A6D94; Mon, 14 Apr 2008 10:03:07 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3B5728C324 for ; Mon, 14 Apr 2008 10:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7VpSGxsp4ef for ; Mon, 14 Apr 2008 10:03:04 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 09AF028C2F6 for ; Mon, 14 Apr 2008 10:03:04 -0700 (PDT) Received: (qmail 67693 invoked from network); 14 Apr 2008 17:03:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.143.70 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 14 Apr 2008 17:03:33 -0000 X-YMail-OSG: mUCik1UVM1n30qBVYIVmleX7D7VH5051fXcnhi7eluy18SV2tEZdE9zlLVh0vsGT1RR6qg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48038E58.7010301@andybierman.com> Date: Mon, 14 Apr 2008 10:03:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Bert Wijnen - IETF References: In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] Confirmation of Implementation and Drafting plans WAS:RE: Summary of the NETCONF WG Session in IETF 71 and ActionItems X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Isn't this type of discussion more appropriate before the charter is approved? IMO, you both have valid arguments. The most relevant question is whether or not there are enough skilled people willing to write and review the document, and stay involved until the 'RFC Announcement' is sent. Since vendors with no plans to implement are also likely to ignore the document work, it seems relevant to ask about implementation plans. When a WG is developing 4 very different work items at once, you cannot expect that all the WG participants care about all the documents, or that people should be expected to work on documents they don't care about. Andy > Dave, > > we (WG co-chairs) are not trying to raise the (formal) bar at all. > But we want to make sure that whatever work the WG is doing makes > sense. As such, we asked for people to let us know about "implementation > plans" for each of the work items (documents). Pls note the word PLAN. > That is nto a commitment. But we also assume it is not a lightly made > statement and then forgotten about. We do understand that an "implementation > plan" can get trashed/canceled (for all sorts of reasons). And if such > happens, > then too bad. > > W.r.t. people not wanting to state any plans in public, we have offered that > such people can send the info to the WG chairs and we commit (note the word > COMMIT) that we will NOT disclose that information and count it as a > "plan to implement by annonymous A" (if we have many, we can have B, C, D > etc. > The more we have, the more it seems that the work we are doing makes sense. > > We have CERTAINLY not asked to make commitments to have implementations > complete by the time that we want to publish a document as RFC (at PS). > As you state, that would be outside of the normal requirements (RTG area > does have such a requirment thoug, so if needed we could see if we would > want to require that too; but I do not see a need for that). > > Hope this helps/explains. > > Bert Wijnen > >> -----Oorspronkelijk bericht----- >> Van: David B Harrington [mailto:dbharrington@comcast.net] >> Verzonden: maandag 14 april 2008 17:14 >> Aan: 'Ersue, Mehmet (NSN - DE/Muenich)' >> CC: 'ext Romascanu, Dan (Dan)'; netconf@ietf.org; 'ext Bert Wijnen - >> IETF' >> Onderwerp: RE: [Netconf] Confirmation of Implementation and Drafting >> plans WAS:RE: Summary of the NETCONF WG Session in IETF 71 and >> ActionItems >> >> >> Hi, >> >> I understand the desire. I wanted to clarify that the WG does not >> "need" to have commitments for two implementations; the WG chairs (and >> presumably the WG) "wants" commitment for two implementations. I think >> it is important to keep what is required for proposed standard and >> what is desired distinct. That is my point. >> >> As Bert observes in one of his responses, other implementations may >> come later. I have a concern about "shutting down" work based on the >> fact that people on the list are not currently committing to >> implementation plans. Some people cannot speak for their company and >> are not personally implementing. >> >> I know that Huawei engineers are constrained by strong IT security >> policies, and are not allowed to implement as part of their daily >> work, so they cannot honestly make such commitments to implement. That >> does not mean they are not interested in the standards effort, and >> they could contribute toward developing a specification that is >> "generally stable, has resolved known design choices, is believed to >> be well-understood, has received significant community review, and >> appears to enjoy enough community interest to be considered valuable." >> >> >> Are there any rules to these commitments? Nortel has three commitments >> to implement. Is that enough, even if no other vendor commits to do >> so? Does a commitment include a commitment to "ship it in product" or >> just prototypes? >> >> The issue is that the chairs, by **requiring** such commitments, >> significantly raise the entry costs for participation in this WG. I am >> not sure that is a good thing to do to ensure a process that is fair >> and open to all, which follows IETF-established guidelines for >> process, and to ensure vendor-neutral standards; I think this approach >> favors certain companies. >> >> I do not object to chairs trying to determine consensus for each >> proposal; that is their job. I do not object to chairs constraining >> the scope to try to ensure we finish the work and don't try to boil >> the ocean. But when the chairs say that two commitments are **needed** >> for standards-track proposals, I believe that is not consistent with >> IETF policy. >> >> dbh >> >>> -----Original Message----- >>> From: Ersue, Mehmet (NSN - DE/Muenich) [mailto:mehmet.ersue@nsn.com] >>> Sent: Monday, April 14, 2008 9:38 AM >>> To: David B Harrington >>> Cc: ext Romascanu, Dan (Dan); netconf@ietf.org; ext Bert Wijnen - >> IETF >>> Subject: RE: [Netconf] Confirmation of Implementation and >>> Drafting plans WAS:RE: Summary of the NETCONF WG Session in >>> IETF 71 and ActionItems >>> >>> >>> Hi David, >>> >>> the RFC text you copied states also: >>> "However, such experience is highly desirable, and will usually >>> represent a strong argument in favor of a Proposed Standard >>> designation." >>> >>> I think this is inline with Dan's statement below. If there is >>> nobody with interest or plans to implement a standard track >>> document the WG item becomes questionable. >>> >>> OTOH: We are not that bad! As discussed in the session we have >>> already a few individuals who implemented or plan to implement. >>> Bert and myself, we would like to have a confirmation to close the >>> action point. >>> >>> Cheers, >>> Mehmet >>> >>> >>>> -----Original Message----- >>>> From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] >>>> Sent: Monday, April 14, 2008 3:13 PM >>>> To: David B Harrington; Ersue, Mehmet (NSN - DE/Muenich); >>>> netconf@ietf.org >>>> Subject: RE: [Netconf] Confirmation of Implementation and >>>> Drafting plansWAS:RE: Summary of the NETCONF WG Session in >>>> IETF 71 and ActionItems >>>> >>>> David, >>>> >>>> You are correct - this formal requirement comes later. We >>>> need at least >>>> two implementations with different code bases and demonstrate >>>> interoperability to advance a document from Proposed to >>>> Draft. However, >>>> I believe that requiring at least a declaration of intent from two >>>> different entities (vendors, open code implementers, etc.) >>> in order to >>>> charter a work as standards track and then ask the IESG to approve >> a >>>> document as PS is quite in tune with this formal process >> requirement >>>> that comes later. >>>> >>>> Dan >>>> >>>> >>>>> -----Original Message----- >>>>> From: netconf-bounces@ietf.org >>>>> [mailto:netconf-bounces@ietf.org] On Behalf Of David B >> Harrington >>>>> Sent: Monday, April 14, 2008 3:29 PM >>>>> To: 'Ersue, Mehmet (NSN - DE/Muenich)'; netconf@ietf.org >>>>> Subject: Re: [Netconf] Confirmation of Implementation and >>>>> Drafting plansWAS:RE: Summary of the NETCONF WG Session in >>>>> IETF 71 and ActionItems >>>>> >>>>> Hi, >>>>> >>>>>> PS: As you know we need _at least_ two implementations for >>>>> a standard >>>>>> track document. >>>>> Can you identify the RFC that describes the standards process >>>>> that has this requirement? I thought we were developing >>>>> standards according to the IETF standards process as >>>>> documented in RFC2026: >>>>> >>>>> " A Proposed Standard specification is generally stable, >>>> has resolved >>>>> known design choices, is believed to be well-understood, >>>>> has received >>>>> significant community review, and appears to enjoy >>>> enough community >>>>> interest to be considered valuable. However, further >>> experience >>>>> might result in a change or even retraction of the >>> specification >>>>> before it advances. >>>>> >>>>> Usually, neither implementation nor operational experience is >>>>> required for the designation of a specification as a Proposed >>>>> Standard. However, such experience is highly >>> desirable, and will >>>>> usually represent a strong argument in favor of a >>>> Proposed Standard >>>>> designation." >>>>> >>>>> David Harrington >>>>> dbharrington@comcast.net >>>>> ietfdbh@comcast.net >>>>> dharrington@huawei.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Netconf mailing list >>>>> Netconf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netconf >>>>> >> >> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 15 04:18:07 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215C928C3A7; Tue, 15 Apr 2008 04:18:07 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3791D28C3A7 for ; Tue, 15 Apr 2008 04:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.487 X-Spam-Level: X-Spam-Status: No, score=-0.487 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C70qioFguggu for ; Tue, 15 Apr 2008 04:18:05 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 6081028C399 for ; Tue, 15 Apr 2008 04:18:05 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id EFFF91B80CB; Tue, 15 Apr 2008 13:18:36 +0200 (CEST) Date: Tue, 15 Apr 2008 13:18:48 +0200 (CEST) Message-Id: <20080415.131848.99722467.mbj@tail-f.com> To: schishol@nortel.com From: Martin Bjorklund In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B413E7AF64@zcarhxm2.corp.nortel.com> References: <713043CE8B8E1348AF3C546DBE02C1B413E7A825@zcarhxm2.corp.nortel.com> <200804041926.m34JQcYk085662@idle.juniper.net> <713043CE8B8E1348AF3C546DBE02C1B413E7AF64@zcarhxm2.corp.nortel.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I think it would have been nice to say that timezone SHOULD be used, in order to handle systems that don't know the timezone. But after looking at all the corner cases, I'm not sure it's worth it, and I think we should say that timezone MUST be used. Some of these corner cases: "Sharon Chisholm" wrote: > Hi > > Good question. I'm going to assume here that if we do this we do it for > all three of our dateTime elements for consistency. I think there are > two cases > 1) Not specified by client in a or but > supported on the NE, then the default time zone of the box is assumed So if you get the startTime 02.15 for the date when you go to winter time, what does it mean? Same for stopTime? What if the client specifies a timezone, but the server doesn't know anything about timezones? /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 15 04:18:07 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215C928C3A7; Tue, 15 Apr 2008 04:18:07 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3791D28C3A7 for ; Tue, 15 Apr 2008 04:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.487 X-Spam-Level: X-Spam-Status: No, score=-0.487 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C70qioFguggu for ; Tue, 15 Apr 2008 04:18:05 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 6081028C399 for ; Tue, 15 Apr 2008 04:18:05 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id EFFF91B80CB; Tue, 15 Apr 2008 13:18:36 +0200 (CEST) Date: Tue, 15 Apr 2008 13:18:48 +0200 (CEST) Message-Id: <20080415.131848.99722467.mbj@tail-f.com> To: schishol@nortel.com From: Martin Bjorklund In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B413E7AF64@zcarhxm2.corp.nortel.com> References: <713043CE8B8E1348AF3C546DBE02C1B413E7A825@zcarhxm2.corp.nortel.com> <200804041926.m34JQcYk085662@idle.juniper.net> <713043CE8B8E1348AF3C546DBE02C1B413E7AF64@zcarhxm2.corp.nortel.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I think it would have been nice to say that timezone SHOULD be used, in order to handle systems that don't know the timezone. But after looking at all the corner cases, I'm not sure it's worth it, and I think we should say that timezone MUST be used. Some of these corner cases: "Sharon Chisholm" wrote: > Hi > > Good question. I'm going to assume here that if we do this we do it for > all three of our dateTime elements for consistency. I think there are > two cases > 1) Not specified by client in a or but > supported on the NE, then the default time zone of the box is assumed So if you get the startTime 02.15 for the date when you go to winter time, what does it mean? Same for stopTime? What if the client specifies a timezone, but the server doesn't know anything about timezones? /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 15 05:43:31 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D4B3A6B5A; Tue, 15 Apr 2008 05:43:31 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E9E3A6830 for ; Tue, 15 Apr 2008 05:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Th7pK7TJ4WIh for ; Tue, 15 Apr 2008 05:43:27 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 74B7A3A6CB9 for ; Tue, 15 Apr 2008 05:43:27 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EE595214E5; Tue, 15 Apr 2008 14:40:36 +0200 (CEST) X-AuditID: c1b4fb3e-b019cbb000004ec0-df-4804a2440aea Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CF4C6214DF; Tue, 15 Apr 2008 14:40:36 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 14:40:36 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 14:40:36 +0200 Message-ID: <4804A244.5010808@ericsson.com> Date: Tue, 15 Apr 2008 14:40:36 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <713043CE8B8E1348AF3C546DBE02C1B413E7A825@zcarhxm2.corp.nortel.com> <200804041926.m34JQcYk085662@idle.juniper.net> <713043CE8B8E1348AF3C546DBE02C1B413E7AF64@zcarhxm2.corp.nortel.com> <20080415.131848.99722467.mbj@tail-f.com> In-Reply-To: <20080415.131848.99722467.mbj@tail-f.com> X-OriginalArrivalTime: 15 Apr 2008 12:40:36.0599 (UTC) FILETIME=[E75EE070:01C89EF5] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Mandatory timezone indicator is fine with me. As Sharon stated DateTime allows arbitrary precision so I don't see a need for change there. If we nned to choose between the formats [hhmmss,ss] is the best. Balazs Martin Bjorklund wrote: > Hi, > > I think it would have been nice to say that timezone SHOULD be used, > in order to handle systems that don't know the timezone. But after > looking at all the corner cases, I'm not sure it's worth it, and I > think we should say that timezone MUST be used. > > Some of these corner cases: > > "Sharon Chisholm" wrote: >> Hi >> >> Good question. I'm going to assume here that if we do this we do it for >> all three of our dateTime elements for consistency. I think there are >> two cases >> 1) Not specified by client in a or but >> supported on the NE, then the default time zone of the box is assumed > > So if you get the startTime 02.15 for the date when you go to winter > time, what does it mean? Same for stopTime? > > What if the client specifies a timezone, but the server doesn't know > anything about timezones? > > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 15 05:43:31 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D4B3A6B5A; Tue, 15 Apr 2008 05:43:31 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E9E3A6830 for ; Tue, 15 Apr 2008 05:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Th7pK7TJ4WIh for ; Tue, 15 Apr 2008 05:43:27 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 74B7A3A6CB9 for ; Tue, 15 Apr 2008 05:43:27 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EE595214E5; Tue, 15 Apr 2008 14:40:36 +0200 (CEST) X-AuditID: c1b4fb3e-b019cbb000004ec0-df-4804a2440aea Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CF4C6214DF; Tue, 15 Apr 2008 14:40:36 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 14:40:36 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Apr 2008 14:40:36 +0200 Message-ID: <4804A244.5010808@ericsson.com> Date: Tue, 15 Apr 2008 14:40:36 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Martin Bjorklund References: <713043CE8B8E1348AF3C546DBE02C1B413E7A825@zcarhxm2.corp.nortel.com> <200804041926.m34JQcYk085662@idle.juniper.net> <713043CE8B8E1348AF3C546DBE02C1B413E7AF64@zcarhxm2.corp.nortel.com> <20080415.131848.99722467.mbj@tail-f.com> In-Reply-To: <20080415.131848.99722467.mbj@tail-f.com> X-OriginalArrivalTime: 15 Apr 2008 12:40:36.0599 (UTC) FILETIME=[E75EE070:01C89EF5] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Mandatory timezone indicator is fine with me. As Sharon stated DateTime allows arbitrary precision so I don't see a need for change there. If we nned to choose between the formats [hhmmss,ss] is the best. Balazs Martin Bjorklund wrote: > Hi, > > I think it would have been nice to say that timezone SHOULD be used, > in order to handle systems that don't know the timezone. But after > looking at all the corner cases, I'm not sure it's worth it, and I > think we should say that timezone MUST be used. > > Some of these corner cases: > > "Sharon Chisholm" wrote: >> Hi >> >> Good question. I'm going to assume here that if we do this we do it for >> all three of our dateTime elements for consistency. I think there are >> two cases >> 1) Not specified by client in a or but >> supported on the NE, then the default time zone of the box is assumed > > So if you get the startTime 02.15 for the date when you go to winter > time, what does it mean? Same for stopTime? > > What if the client specifies a timezone, but the server doesn't know > anything about timezones? > > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 15 08:28:06 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 408313A6D5D; Tue, 15 Apr 2008 08:28:06 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7BED3A6C9D for ; Tue, 15 Apr 2008 08:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCsoQ4+VT7kH for ; Tue, 15 Apr 2008 08:28:03 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id 19B0C3A69D1 for ; Tue, 15 Apr 2008 08:27:59 -0700 (PDT) Received: (qmail 76387 invoked from network); 15 Apr 2008 15:28:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.161 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 15 Apr 2008 15:28:30 -0000 X-YMail-OSG: 22bkECUVM1kV8Ih4v8Vzb91dSRhozNtI_zQwVE9AFCYFBYY4Ws_bp4yDc6s7DXI4G04sLw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4804C99F.10303@andybierman.com> Date: Tue, 15 Apr 2008 08:28:31 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Bert Wijnen - IETF References: In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Bert Wijnen - IETF wrote: > WG members, > > I have only seen Phil Shafer and Tom Pech speak up on this topic. > I have difficulty determining WG consensus on this topic if we do > not get more responses aka > - I agree with the change > - I see issues: (with details) > - I don't care. > (d) no objections -- which should mean the same as not stating an opinion. Sharon's original email was double-checking that there are no objections to the edit. This has been fairly normal SOP for the last 20 years or so. Somebody discovers a technical problem. Somebody else suggests a minor, although normative change to fix the technical problem. Rather than looking for a debate and trying to extend the decision process as long as possible, it is common to just ask for objections (sometimes even just STRONG objections), and accept the bug-fix unless somebody demonstrates that: 1) the bug-fix will not completely work 2) the bug-fix has a ripple effect and impacts other protocol features 3) the bug-fix is not really needed (disagree there is a problem to solve) That's the process I thought was being used when Sharon sent her email. My non-response meant 'no objections to the proposed bug-fix'. Andy > As stated in an earlier email, your current WG chairs will not take > silence as a signal of consent. PLEASE DO speak out what your opinion is. > > Bert Wijnen > notifications document shepherd (and co-chair) > >> -----Oorspronkelijk bericht----- >> Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens >> Sharon Chisholm >> Verzonden: vrijdag 4 april 2008 21:24 >> Aan: netconf@ietf.org >> Onderwerp: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: >> DateTime >> >> >> Hi >> >> There are no objections to mandating use of time zone in eventTime? >> >> Sharon >> >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On >> Behalf Of Chisholm, Sharon (CAR:ZZ00) >> Sent: Wednesday, April 02, 2008 1:12 PM >> To: netconf@ietf.org >> Subject: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime >> >> Hi >> >> This is one of the discuss topics on the notification draft. This will >> potentially result in two changes >> - Additional reference (to point to specifications that indicate how >> dateTime provides sufficient precision) >> - Adding a statement, if the working group agrees, that makes >> supporting time zone mandatory. >> >> Sharon >> >> -----Original Message----- >> From: Chisholm, Sharon (CAR:ZZ00) >> Sent: Wednesday, April 02, 2008 12:25 PM >> To: 'Chris Newman'; 'dward@cisco.com' >> Cc: 'Hector Trevino (htrevino)'; 'Bert Wijnen - IETF'; 'Ersue, Mehmet >> (NSN - DE/Muenich)'; 'Dan Romascanu' >> Subject: Netconf Notification: Issues 8 & 18: DateTime >> >> Please reply to this email either indicating that you consider this >> issue resolved or by providing additional feedback as to why the >> response is not sufficient. >> >> >> 18. Discuss: dateTime (David Ward) >> [2008-03-26] ** All of the time references are in "type dateTime" which >> is XMLschema speak is "YYYY-MM-DDThh:mm:ss" (although there is no >> reference). >> >> Given the output of config events from networking nodes can happen at an >> incredible rate, why is it felt that seconds are a satisfactory >> granularity? Most vendors are in fact already implementing event down to >> the ms. This is critical for fault messages. It is impossible to >> understand what is happening on a network node with the granularity of >> seconds. >> >> 8. dateTime (Chris Newman) >> >> The dateTime XML schema data type makes the timezone optional, in which >> case time stamps are ambiguous and non-interoperable. This document >> needs to explicitly require that timezones be present in order to >> interoperate. I observe that dateTime does permit arbitrary fractions >> of a second so I do not agree with Dave Ward's DISCUSS on the accuracy >> issue, however he's right that a normative reference to XML schema data >> types is necessary to clarify this and should be referenced when the >> "dateTime" data type is first mentioned. RFC 3339 discusses these >> issues in more detail. >> >> >> There is no restriction as to the number of decimal digits. We'll add a >> reference to XML XL documentation and to RFC 3339. >> >> FROM ISO 8601 >> If necessary for a particular application a decimal fraction of hour, >> minute or second may be included. If a decimal fraction is included, >> lower order time elements (if any) shall be omitted and the decimal >> fraction shall be divided from the integer part by the decimal sign >> specified in ISO 31-0, i.e. the comma [,] or full stop [.]. Of these, >> the comma is the preferred sign. If the magnitude of the number is less >> than unity, the decimal sign shall be preceded by two zeros in >> accordance with 3.6. >> The interchange parties, dependent upon the application, shall agree the >> number of digits in the decimal fraction. The format shall be >> [hhmmss,ss], [hhmm,mm] or [hh,hh] as appropriate (hour minute second, >> hour minute, and hour, respectively), with as many digits as necessary >> following the decimal sign. A decimal fraction shall have at least one >> digit. In the examples below it has been agreed to give the smallest >> time element a decimal fraction with one digit. >> >> As for the timezone issue, I know in the past we have discussed whether >> or not you could mandate use of timezones. At the time it was felt there >> were machines that would be unable to support this feature. Keep in mind >> that this solution needs to work on smaller, lower-end boxes as well as >> fancy ones. Adding text mandating use of timezones would need to be >> approved by the working group. Assuming the working group agrees, I have >> no problem adding this text. >> >> Sharon Chisholm >> Nortel >> Ottawa, Ontario >> Canada >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 15 08:28:06 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 408313A6D5D; Tue, 15 Apr 2008 08:28:06 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7BED3A6C9D for ; Tue, 15 Apr 2008 08:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCsoQ4+VT7kH for ; Tue, 15 Apr 2008 08:28:03 -0700 (PDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id 19B0C3A69D1 for ; Tue, 15 Apr 2008 08:27:59 -0700 (PDT) Received: (qmail 76387 invoked from network); 15 Apr 2008 15:28:32 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.121.107.161 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 15 Apr 2008 15:28:30 -0000 X-YMail-OSG: 22bkECUVM1kV8Ih4v8Vzb91dSRhozNtI_zQwVE9AFCYFBYY4Ws_bp4yDc6s7DXI4G04sLw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4804C99F.10303@andybierman.com> Date: Tue, 15 Apr 2008 08:28:31 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Bert Wijnen - IETF References: In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Bert Wijnen - IETF wrote: > WG members, > > I have only seen Phil Shafer and Tom Pech speak up on this topic. > I have difficulty determining WG consensus on this topic if we do > not get more responses aka > - I agree with the change > - I see issues: (with details) > - I don't care. > (d) no objections -- which should mean the same as not stating an opinion. Sharon's original email was double-checking that there are no objections to the edit. This has been fairly normal SOP for the last 20 years or so. Somebody discovers a technical problem. Somebody else suggests a minor, although normative change to fix the technical problem. Rather than looking for a debate and trying to extend the decision process as long as possible, it is common to just ask for objections (sometimes even just STRONG objections), and accept the bug-fix unless somebody demonstrates that: 1) the bug-fix will not completely work 2) the bug-fix has a ripple effect and impacts other protocol features 3) the bug-fix is not really needed (disagree there is a problem to solve) That's the process I thought was being used when Sharon sent her email. My non-response meant 'no objections to the proposed bug-fix'. Andy > As stated in an earlier email, your current WG chairs will not take > silence as a signal of consent. PLEASE DO speak out what your opinion is. > > Bert Wijnen > notifications document shepherd (and co-chair) > >> -----Oorspronkelijk bericht----- >> Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens >> Sharon Chisholm >> Verzonden: vrijdag 4 april 2008 21:24 >> Aan: netconf@ietf.org >> Onderwerp: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: >> DateTime >> >> >> Hi >> >> There are no objections to mandating use of time zone in eventTime? >> >> Sharon >> >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On >> Behalf Of Chisholm, Sharon (CAR:ZZ00) >> Sent: Wednesday, April 02, 2008 1:12 PM >> To: netconf@ietf.org >> Subject: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime >> >> Hi >> >> This is one of the discuss topics on the notification draft. This will >> potentially result in two changes >> - Additional reference (to point to specifications that indicate how >> dateTime provides sufficient precision) >> - Adding a statement, if the working group agrees, that makes >> supporting time zone mandatory. >> >> Sharon >> >> -----Original Message----- >> From: Chisholm, Sharon (CAR:ZZ00) >> Sent: Wednesday, April 02, 2008 12:25 PM >> To: 'Chris Newman'; 'dward@cisco.com' >> Cc: 'Hector Trevino (htrevino)'; 'Bert Wijnen - IETF'; 'Ersue, Mehmet >> (NSN - DE/Muenich)'; 'Dan Romascanu' >> Subject: Netconf Notification: Issues 8 & 18: DateTime >> >> Please reply to this email either indicating that you consider this >> issue resolved or by providing additional feedback as to why the >> response is not sufficient. >> >> >> 18. Discuss: dateTime (David Ward) >> [2008-03-26] ** All of the time references are in "type dateTime" which >> is XMLschema speak is "YYYY-MM-DDThh:mm:ss" (although there is no >> reference). >> >> Given the output of config events from networking nodes can happen at an >> incredible rate, why is it felt that seconds are a satisfactory >> granularity? Most vendors are in fact already implementing event down to >> the ms. This is critical for fault messages. It is impossible to >> understand what is happening on a network node with the granularity of >> seconds. >> >> 8. dateTime (Chris Newman) >> >> The dateTime XML schema data type makes the timezone optional, in which >> case time stamps are ambiguous and non-interoperable. This document >> needs to explicitly require that timezones be present in order to >> interoperate. I observe that dateTime does permit arbitrary fractions >> of a second so I do not agree with Dave Ward's DISCUSS on the accuracy >> issue, however he's right that a normative reference to XML schema data >> types is necessary to clarify this and should be referenced when the >> "dateTime" data type is first mentioned. RFC 3339 discusses these >> issues in more detail. >> >> >> There is no restriction as to the number of decimal digits. We'll add a >> reference to XML XL documentation and to RFC 3339. >> >> FROM ISO 8601 >> If necessary for a particular application a decimal fraction of hour, >> minute or second may be included. If a decimal fraction is included, >> lower order time elements (if any) shall be omitted and the decimal >> fraction shall be divided from the integer part by the decimal sign >> specified in ISO 31-0, i.e. the comma [,] or full stop [.]. Of these, >> the comma is the preferred sign. If the magnitude of the number is less >> than unity, the decimal sign shall be preceded by two zeros in >> accordance with 3.6. >> The interchange parties, dependent upon the application, shall agree the >> number of digits in the decimal fraction. The format shall be >> [hhmmss,ss], [hhmm,mm] or [hh,hh] as appropriate (hour minute second, >> hour minute, and hour, respectively), with as many digits as necessary >> following the decimal sign. A decimal fraction shall have at least one >> digit. In the examples below it has been agreed to give the smallest >> time element a decimal fraction with one digit. >> >> As for the timezone issue, I know in the past we have discussed whether >> or not you could mandate use of timezones. At the time it was felt there >> were machines that would be unable to support this feature. Keep in mind >> that this solution needs to work on smaller, lower-end boxes as well as >> fancy ones. Adding text mandating use of timezones would need to be >> approved by the working group. Assuming the working group agrees, I have >> no problem adding this text. >> >> Sharon Chisholm >> Nortel >> Ottawa, Ontario >> Canada >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 15 08:33:40 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E194B3A6E96; Tue, 15 Apr 2008 08:33:40 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261A43A6830 for ; Tue, 15 Apr 2008 08:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[AWL=1.221, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhvSjpjTC0TE for ; Tue, 15 Apr 2008 08:33:34 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 4D05A3A6ECB for ; Tue, 15 Apr 2008 08:33:34 -0700 (PDT) Received: (qmail 33369 invoked from network); 15 Apr 2008 15:34:06 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 15 Apr 2008 15:34:06 -0000 From: "Bert Wijnen - IETF" To: "Andy Bierman" Date: Tue, 15 Apr 2008 17:34:08 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <4804C99F.10303@andybierman.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Thanks Andy. The idea is not to get "extended debate" or to "delay approval as long as possible". But I have difficulty figuring out what silence means. Maybe nobody saw the message. A short :no objection" or "OK" ir "wfm" (works for me) is really appreciated. Bert Wijnen > -----Oorspronkelijk bericht----- > Van: Andy Bierman [mailto:ietf@andybierman.com] > Verzonden: dinsdag 15 april 2008 17:29 > Aan: Bert Wijnen - IETF > CC: netconf@ietf.org > Onderwerp: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: > DateTime > > > Bert Wijnen - IETF wrote: > > WG members, > > > > I have only seen Phil Shafer and Tom Pech speak up on this topic. > > I have difficulty determining WG consensus on this topic if we do > > not get more responses aka > > - I agree with the change > > - I see issues: (with details) > > - I don't care. > > > > (d) no objections -- which should mean the same as not stating > an opinion. Sharon's original email was double-checking that > there are no objections to the edit. > > This has been fairly normal SOP for the last 20 years or so. > Somebody discovers a technical problem. Somebody else suggests > a minor, although normative change to fix the technical problem. > > Rather than looking for a debate and trying to extend the > decision process as long as possible, it is common to just ask > for objections (sometimes even just STRONG objections), > and accept the bug-fix unless somebody demonstrates that: > > 1) the bug-fix will not completely work > 2) the bug-fix has a ripple effect and impacts other protocol features > 3) the bug-fix is not really needed (disagree there is a > problem to solve) > > That's the process I thought was being used when Sharon sent her > email. My non-response meant 'no objections to the proposed bug-fix'. > > > Andy > > > As stated in an earlier email, your current WG chairs will not take > > silence as a signal of consent. PLEASE DO speak out what your > opinion is. > > > > Bert Wijnen > > notifications document shepherd (and co-chair) > > > >> -----Oorspronkelijk bericht----- > >> Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > >> Sharon Chisholm > >> Verzonden: vrijdag 4 april 2008 21:24 > >> Aan: netconf@ietf.org > >> Onderwerp: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: > >> DateTime > >> > >> > >> Hi > >> > >> There are no objections to mandating use of time zone in eventTime? > >> > >> Sharon > >> > >> -----Original Message----- > >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > >> Behalf Of Chisholm, Sharon (CAR:ZZ00) > >> Sent: Wednesday, April 02, 2008 1:12 PM > >> To: netconf@ietf.org > >> Subject: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime > >> > >> Hi > >> > >> This is one of the discuss topics on the notification draft. This will > >> potentially result in two changes > >> - Additional reference (to point to specifications that indicate how > >> dateTime provides sufficient precision) > >> - Adding a statement, if the working group agrees, that makes > >> supporting time zone mandatory. > >> > >> Sharon > >> > >> -----Original Message----- > >> From: Chisholm, Sharon (CAR:ZZ00) > >> Sent: Wednesday, April 02, 2008 12:25 PM > >> To: 'Chris Newman'; 'dward@cisco.com' > >> Cc: 'Hector Trevino (htrevino)'; 'Bert Wijnen - IETF'; 'Ersue, Mehmet > >> (NSN - DE/Muenich)'; 'Dan Romascanu' > >> Subject: Netconf Notification: Issues 8 & 18: DateTime > >> > >> Please reply to this email either indicating that you consider this > >> issue resolved or by providing additional feedback as to why the > >> response is not sufficient. > >> > >> > >> 18. Discuss: dateTime (David Ward) > >> [2008-03-26] ** All of the time references are in "type dateTime" which > >> is XMLschema speak is "YYYY-MM-DDThh:mm:ss" (although there is no > >> reference). > >> > >> Given the output of config events from networking nodes can > happen at an > >> incredible rate, why is it felt that seconds are a satisfactory > >> granularity? Most vendors are in fact already implementing > event down to > >> the ms. This is critical for fault messages. It is impossible to > >> understand what is happening on a network node with the granularity of > >> seconds. > >> > >> 8. dateTime (Chris Newman) > >> > >> The dateTime XML schema data type makes the timezone optional, in which > >> case time stamps are ambiguous and non-interoperable. This document > >> needs to explicitly require that timezones be present in order to > >> interoperate. I observe that dateTime does permit arbitrary fractions > >> of a second so I do not agree with Dave Ward's DISCUSS on the accuracy > >> issue, however he's right that a normative reference to XML schema data > >> types is necessary to clarify this and should be referenced when the > >> "dateTime" data type is first mentioned. RFC 3339 discusses these > >> issues in more detail. > >> > >> > >> There is no restriction as to the number of decimal digits. We'll add a > >> reference to XML XL documentation and to RFC 3339. > >> > >> FROM ISO 8601 > >> If necessary for a particular application a decimal fraction of hour, > >> minute or second may be included. If a decimal fraction is included, > >> lower order time elements (if any) shall be omitted and the decimal > >> fraction shall be divided from the integer part by the decimal sign > >> specified in ISO 31-0, i.e. the comma [,] or full stop [.]. Of these, > >> the comma is the preferred sign. If the magnitude of the number is less > >> than unity, the decimal sign shall be preceded by two zeros in > >> accordance with 3.6. > >> The interchange parties, dependent upon the application, shall > agree the > >> number of digits in the decimal fraction. The format shall be > >> [hhmmss,ss], [hhmm,mm] or [hh,hh] as appropriate (hour minute second, > >> hour minute, and hour, respectively), with as many digits as necessary > >> following the decimal sign. A decimal fraction shall have at least one > >> digit. In the examples below it has been agreed to give the smallest > >> time element a decimal fraction with one digit. > >> > >> As for the timezone issue, I know in the past we have discussed whether > >> or not you could mandate use of timezones. At the time it was > felt there > >> were machines that would be unable to support this feature. > Keep in mind > >> that this solution needs to work on smaller, lower-end boxes as well as > >> fancy ones. Adding text mandating use of timezones would need to be > >> approved by the working group. Assuming the working group > agrees, I have > >> no problem adding this text. > >> > >> Sharon Chisholm > >> Nortel > >> Ottawa, Ontario > >> Canada > >> _______________________________________________ > >> Netconf mailing list > >> Netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > >> _______________________________________________ > >> Netconf mailing list > >> Netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > >> > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 15 08:33:40 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E194B3A6E96; Tue, 15 Apr 2008 08:33:40 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261A43A6830 for ; Tue, 15 Apr 2008 08:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[AWL=1.221, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhvSjpjTC0TE for ; Tue, 15 Apr 2008 08:33:34 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 4D05A3A6ECB for ; Tue, 15 Apr 2008 08:33:34 -0700 (PDT) Received: (qmail 33369 invoked from network); 15 Apr 2008 15:34:06 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 15 Apr 2008 15:34:06 -0000 From: "Bert Wijnen - IETF" To: "Andy Bierman" Date: Tue, 15 Apr 2008 17:34:08 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <4804C99F.10303@andybierman.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Thanks Andy. The idea is not to get "extended debate" or to "delay approval as long as possible". But I have difficulty figuring out what silence means. Maybe nobody saw the message. A short :no objection" or "OK" ir "wfm" (works for me) is really appreciated. Bert Wijnen > -----Oorspronkelijk bericht----- > Van: Andy Bierman [mailto:ietf@andybierman.com] > Verzonden: dinsdag 15 april 2008 17:29 > Aan: Bert Wijnen - IETF > CC: netconf@ietf.org > Onderwerp: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: > DateTime > > > Bert Wijnen - IETF wrote: > > WG members, > > > > I have only seen Phil Shafer and Tom Pech speak up on this topic. > > I have difficulty determining WG consensus on this topic if we do > > not get more responses aka > > - I agree with the change > > - I see issues: (with details) > > - I don't care. > > > > (d) no objections -- which should mean the same as not stating > an opinion. Sharon's original email was double-checking that > there are no objections to the edit. > > This has been fairly normal SOP for the last 20 years or so. > Somebody discovers a technical problem. Somebody else suggests > a minor, although normative change to fix the technical problem. > > Rather than looking for a debate and trying to extend the > decision process as long as possible, it is common to just ask > for objections (sometimes even just STRONG objections), > and accept the bug-fix unless somebody demonstrates that: > > 1) the bug-fix will not completely work > 2) the bug-fix has a ripple effect and impacts other protocol features > 3) the bug-fix is not really needed (disagree there is a > problem to solve) > > That's the process I thought was being used when Sharon sent her > email. My non-response meant 'no objections to the proposed bug-fix'. > > > Andy > > > As stated in an earlier email, your current WG chairs will not take > > silence as a signal of consent. PLEASE DO speak out what your > opinion is. > > > > Bert Wijnen > > notifications document shepherd (and co-chair) > > > >> -----Oorspronkelijk bericht----- > >> Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > >> Sharon Chisholm > >> Verzonden: vrijdag 4 april 2008 21:24 > >> Aan: netconf@ietf.org > >> Onderwerp: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: > >> DateTime > >> > >> > >> Hi > >> > >> There are no objections to mandating use of time zone in eventTime? > >> > >> Sharon > >> > >> -----Original Message----- > >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > >> Behalf Of Chisholm, Sharon (CAR:ZZ00) > >> Sent: Wednesday, April 02, 2008 1:12 PM > >> To: netconf@ietf.org > >> Subject: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime > >> > >> Hi > >> > >> This is one of the discuss topics on the notification draft. This will > >> potentially result in two changes > >> - Additional reference (to point to specifications that indicate how > >> dateTime provides sufficient precision) > >> - Adding a statement, if the working group agrees, that makes > >> supporting time zone mandatory. > >> > >> Sharon > >> > >> -----Original Message----- > >> From: Chisholm, Sharon (CAR:ZZ00) > >> Sent: Wednesday, April 02, 2008 12:25 PM > >> To: 'Chris Newman'; 'dward@cisco.com' > >> Cc: 'Hector Trevino (htrevino)'; 'Bert Wijnen - IETF'; 'Ersue, Mehmet > >> (NSN - DE/Muenich)'; 'Dan Romascanu' > >> Subject: Netconf Notification: Issues 8 & 18: DateTime > >> > >> Please reply to this email either indicating that you consider this > >> issue resolved or by providing additional feedback as to why the > >> response is not sufficient. > >> > >> > >> 18. Discuss: dateTime (David Ward) > >> [2008-03-26] ** All of the time references are in "type dateTime" which > >> is XMLschema speak is "YYYY-MM-DDThh:mm:ss" (although there is no > >> reference). > >> > >> Given the output of config events from networking nodes can > happen at an > >> incredible rate, why is it felt that seconds are a satisfactory > >> granularity? Most vendors are in fact already implementing > event down to > >> the ms. This is critical for fault messages. It is impossible to > >> understand what is happening on a network node with the granularity of > >> seconds. > >> > >> 8. dateTime (Chris Newman) > >> > >> The dateTime XML schema data type makes the timezone optional, in which > >> case time stamps are ambiguous and non-interoperable. This document > >> needs to explicitly require that timezones be present in order to > >> interoperate. I observe that dateTime does permit arbitrary fractions > >> of a second so I do not agree with Dave Ward's DISCUSS on the accuracy > >> issue, however he's right that a normative reference to XML schema data > >> types is necessary to clarify this and should be referenced when the > >> "dateTime" data type is first mentioned. RFC 3339 discusses these > >> issues in more detail. > >> > >> > >> There is no restriction as to the number of decimal digits. We'll add a > >> reference to XML XL documentation and to RFC 3339. > >> > >> FROM ISO 8601 > >> If necessary for a particular application a decimal fraction of hour, > >> minute or second may be included. If a decimal fraction is included, > >> lower order time elements (if any) shall be omitted and the decimal > >> fraction shall be divided from the integer part by the decimal sign > >> specified in ISO 31-0, i.e. the comma [,] or full stop [.]. Of these, > >> the comma is the preferred sign. If the magnitude of the number is less > >> than unity, the decimal sign shall be preceded by two zeros in > >> accordance with 3.6. > >> The interchange parties, dependent upon the application, shall > agree the > >> number of digits in the decimal fraction. The format shall be > >> [hhmmss,ss], [hhmm,mm] or [hh,hh] as appropriate (hour minute second, > >> hour minute, and hour, respectively), with as many digits as necessary > >> following the decimal sign. A decimal fraction shall have at least one > >> digit. In the examples below it has been agreed to give the smallest > >> time element a decimal fraction with one digit. > >> > >> As for the timezone issue, I know in the past we have discussed whether > >> or not you could mandate use of timezones. At the time it was > felt there > >> were machines that would be unable to support this feature. > Keep in mind > >> that this solution needs to work on smaller, lower-end boxes as well as > >> fancy ones. Adding text mandating use of timezones would need to be > >> approved by the working group. Assuming the working group > agrees, I have > >> no problem adding this text. > >> > >> Sharon Chisholm > >> Nortel > >> Ottawa, Ontario > >> Canada > >> _______________________________________________ > >> Netconf mailing list > >> Netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > >> _______________________________________________ > >> Netconf mailing list > >> Netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > >> > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 15 11:26:27 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B649C3A68DD; Tue, 15 Apr 2008 11:26:27 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735C63A68DD for ; Tue, 15 Apr 2008 11:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BUwHvUXdzAa for ; Tue, 15 Apr 2008 11:26:25 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 8F4C03A67C0 for ; Tue, 15 Apr 2008 11:26:25 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id DrJ71Z00A1GXsucAA0NB00; Tue, 15 Apr 2008 18:26:19 +0000 Received: from Harrington73653 ([66.122.107.58]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id DuSM1Z0071Fdc9e8T00000; Tue, 15 Apr 2008 18:26:56 +0000 X-Authority-Analysis: v=1.0 c=1 a=SwVsmxaiRQQA:10 a=leqh2dLNEHMA:10 a=SSmOFEACAAAA:8 a=48vgC7mUAAAA:8 a=AX3-6SLH1RABf9pQqdcA:9 a=lDcrCCuI3IuLRRUsxZkA:7 a=yIGVDvauyxr_MiFNNom_j8agR_EA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=ZPn7O4N2MpQA:10 a=peF9eE_zjQwA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'tom.petch'" , "'Sharon Chisholm'" , "'Phil Shafer'" References: <713043CE8B8E1348AF3C546DBE02C1B413E7A825@zcarhxm2.corp.nortel.com><200804041926.m34JQcYk085662@idle.juniper.net><713043CE8B8E1348AF3C546DBE02C1B413E7AF64@zcarhxm2.corp.nortel.com> <000401c89ba7$eae3cae0$0601a8c0@allison> Date: Tue, 15 Apr 2008 11:26:19 -0700 Message-ID: <00a001c89f26$3f086eb0$5e0a0a0a@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000401c89ba7$eae3cae0$0601a8c0@allison> thread-index: AcibsNiRsT0p/UtjRVOxvrYfBnTd9ADdCjOQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I have reviewed the W3C discussion Tom mentions, which is mostly about devices that do not support timezones in their dateTime formats, and how to compare dateTimes with/without timezones. I have reviewed RFC3339 section 4.4 that Sharon mentioned: " A number of devices currently connected to the Internet run their internal clocks in local time and are unaware of UTC. While the Internet does have a tradition of accepting reality when creating specifications, this should not be done at the expense of interoperability. Since interpretation of an unqualified local time zone will fail in approximately 23/24 of the globe, the interoperability problems of unqualified local time are deemed unacceptable for the Internet. Systems that are configured with a local time, are unaware of the corresponding UTC offset, and depend on time synchronization with other Internet systems, MUST use a mechanism that ensures correct synchronization with UTC. " Since Netconf Notifications is a new technology that does not exist in legacy devices, and if legacy devices are updated to handle Netconf Notifications, they can be updated to provide workaround functionality as called for by RFC3339, I believe we should follow the standards-track guidance of RFC3339 and make the timezone a MUST for compliance, to ensure interoperability. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of tom.petch > Sent: Thursday, April 10, 2008 8:41 AM > To: Sharon Chisholm; Phil Shafer > Cc: netconf@ietf.org > Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & > 18: DateTime > > This can of worms has been opened by W3C in > > http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ > > s3.2.7 and especially 3.2.7.4. > > They cover the cases of time zones present and not present, > and if the end > results are not magically helpful, then I think that the same > applies to any > other proposal. > > But I do think that we should use their work as a basis and > have good reason for > departing from it. It is more likely to be what others > expect and what XML > tools provide. > > Tom Petch > > ----- Original Message ----- > From: "Sharon Chisholm" > To: "Phil Shafer" > Cc: > Sent: Monday, April 07, 2008 3:11 PM > Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & > 18: DateTime > > > > Hi > > > > Good question. I'm going to assume here that if we do this > we do it for > > all three of our dateTime elements for consistency. I > think there are > > two cases > > 1) Not specified by client in a or but > > supported on the NE, then the default time zone of the box > is assumed > > 2) Not configured on the box. Then I don't think there is > actually a > > workaround. This would be a non-compliant device. > > > > Note that if we don't do this we need to answer the issues raised in > > http://tools.ietf.org/html/rfc3339#section-4.4 > > > > Sharon > > > > -----Original Message----- > > From: Phil Shafer [mailto:phil@juniper.net] > > Sent: Friday, April 04, 2008 3:27 PM > > To: Chisholm, Sharon (CAR:ZZ00) > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & > 18: DateTime > > > > "Sharon Chisholm" writes: > > >There are no objections to mandating use of time zone in eventTime? > > > > What does one use when the time zone is unknown (not configured)? > > > > Thanks, > > Phil > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 15 11:26:27 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B649C3A68DD; Tue, 15 Apr 2008 11:26:27 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735C63A68DD for ; Tue, 15 Apr 2008 11:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BUwHvUXdzAa for ; Tue, 15 Apr 2008 11:26:25 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 8F4C03A67C0 for ; Tue, 15 Apr 2008 11:26:25 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id DrJ71Z00A1GXsucAA0NB00; Tue, 15 Apr 2008 18:26:19 +0000 Received: from Harrington73653 ([66.122.107.58]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id DuSM1Z0071Fdc9e8T00000; Tue, 15 Apr 2008 18:26:56 +0000 X-Authority-Analysis: v=1.0 c=1 a=SwVsmxaiRQQA:10 a=leqh2dLNEHMA:10 a=SSmOFEACAAAA:8 a=48vgC7mUAAAA:8 a=AX3-6SLH1RABf9pQqdcA:9 a=lDcrCCuI3IuLRRUsxZkA:7 a=yIGVDvauyxr_MiFNNom_j8agR_EA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=ZPn7O4N2MpQA:10 a=peF9eE_zjQwA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'tom.petch'" , "'Sharon Chisholm'" , "'Phil Shafer'" References: <713043CE8B8E1348AF3C546DBE02C1B413E7A825@zcarhxm2.corp.nortel.com><200804041926.m34JQcYk085662@idle.juniper.net><713043CE8B8E1348AF3C546DBE02C1B413E7AF64@zcarhxm2.corp.nortel.com> <000401c89ba7$eae3cae0$0601a8c0@allison> Date: Tue, 15 Apr 2008 11:26:19 -0700 Message-ID: <00a001c89f26$3f086eb0$5e0a0a0a@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000401c89ba7$eae3cae0$0601a8c0@allison> thread-index: AcibsNiRsT0p/UtjRVOxvrYfBnTd9ADdCjOQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I have reviewed the W3C discussion Tom mentions, which is mostly about devices that do not support timezones in their dateTime formats, and how to compare dateTimes with/without timezones. I have reviewed RFC3339 section 4.4 that Sharon mentioned: " A number of devices currently connected to the Internet run their internal clocks in local time and are unaware of UTC. While the Internet does have a tradition of accepting reality when creating specifications, this should not be done at the expense of interoperability. Since interpretation of an unqualified local time zone will fail in approximately 23/24 of the globe, the interoperability problems of unqualified local time are deemed unacceptable for the Internet. Systems that are configured with a local time, are unaware of the corresponding UTC offset, and depend on time synchronization with other Internet systems, MUST use a mechanism that ensures correct synchronization with UTC. " Since Netconf Notifications is a new technology that does not exist in legacy devices, and if legacy devices are updated to handle Netconf Notifications, they can be updated to provide workaround functionality as called for by RFC3339, I believe we should follow the standards-track guidance of RFC3339 and make the timezone a MUST for compliance, to ensure interoperability. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of tom.petch > Sent: Thursday, April 10, 2008 8:41 AM > To: Sharon Chisholm; Phil Shafer > Cc: netconf@ietf.org > Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & > 18: DateTime > > This can of worms has been opened by W3C in > > http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ > > s3.2.7 and especially 3.2.7.4. > > They cover the cases of time zones present and not present, > and if the end > results are not magically helpful, then I think that the same > applies to any > other proposal. > > But I do think that we should use their work as a basis and > have good reason for > departing from it. It is more likely to be what others > expect and what XML > tools provide. > > Tom Petch > > ----- Original Message ----- > From: "Sharon Chisholm" > To: "Phil Shafer" > Cc: > Sent: Monday, April 07, 2008 3:11 PM > Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & > 18: DateTime > > > > Hi > > > > Good question. I'm going to assume here that if we do this > we do it for > > all three of our dateTime elements for consistency. I > think there are > > two cases > > 1) Not specified by client in a or but > > supported on the NE, then the default time zone of the box > is assumed > > 2) Not configured on the box. Then I don't think there is > actually a > > workaround. This would be a non-compliant device. > > > > Note that if we don't do this we need to answer the issues raised in > > http://tools.ietf.org/html/rfc3339#section-4.4 > > > > Sharon > > > > -----Original Message----- > > From: Phil Shafer [mailto:phil@juniper.net] > > Sent: Friday, April 04, 2008 3:27 PM > > To: Chisholm, Sharon (CAR:ZZ00) > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & > 18: DateTime > > > > "Sharon Chisholm" writes: > > >There are no objections to mandating use of time zone in eventTime? > > > > What does one use when the time zone is unknown (not configured)? > > > > Thanks, > > Phil > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 16 03:47:34 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2E228C417; Wed, 16 Apr 2008 03:47:34 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DEB328C45F for ; Wed, 16 Apr 2008 03:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p35S-C-HmkT1 for ; Wed, 16 Apr 2008 03:47:32 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id C7C1C28C498 for ; Wed, 16 Apr 2008 03:47:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,664,1199664000"; d="scan'208";a="374546" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 16 Apr 2008 11:47:48 +0100 In-Reply-To: <20080415.131848.99722467.mbj@tail-f.com> To: Martin Bjorklund MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Stephen.Morris@nominet.org.uk Date: Wed, 16 Apr 2008 11:47:47 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 16/04/2008 11:47:48 AM, Serialize complete at 16/04/2008 11:47:48 AM Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote on 15/04/2008 12:18:48: > Hi, > > I think it would have been nice to say that timezone SHOULD be used, > in order to handle systems that don't know the timezone. But after > looking at all the corner cases, I'm not sure it's worth it, and I > think we should say that timezone MUST be used. I agree. Stephen _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 16 03:47:34 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2E228C417; Wed, 16 Apr 2008 03:47:34 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DEB328C45F for ; Wed, 16 Apr 2008 03:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p35S-C-HmkT1 for ; Wed, 16 Apr 2008 03:47:32 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id C7C1C28C498 for ; Wed, 16 Apr 2008 03:47:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,664,1199664000"; d="scan'208";a="374546" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 16 Apr 2008 11:47:48 +0100 In-Reply-To: <20080415.131848.99722467.mbj@tail-f.com> To: Martin Bjorklund MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: From: Stephen.Morris@nominet.org.uk Date: Wed, 16 Apr 2008 11:47:47 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 16/04/2008 11:47:48 AM, Serialize complete at 16/04/2008 11:47:48 AM Cc: netconf@ietf.org Subject: Re: [Netconf] FW: Netconf Notification: Issues 8 & 18: DateTime X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote on 15/04/2008 12:18:48: > Hi, > > I think it would have been nice to say that timezone SHOULD be used, > in order to handle systems that don't know the timezone. But after > looking at all the corner cases, I'm not sure it's worth it, and I > think we should say that timezone MUST be used. I agree. Stephen _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 09:42:05 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 017D428C203; Mon, 21 Apr 2008 09:42:05 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59AB528C1F1 for ; Mon, 21 Apr 2008 09:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b271vOZNQKem for ; Mon, 21 Apr 2008 09:42:03 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id E88E428C273 for ; Mon, 21 Apr 2008 09:42:02 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3LGg6p14607 for ; Mon, 21 Apr 2008 16:42:06 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Apr 2008 12:41:49 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41426EB6B@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Netconf Notification: Issues 22: Import Statements Thread-Index: AcijzphqIvw0Qy2NRgyZ0Jwh970+ew== From: "Sharon Chisholm" To: Subject: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi This is the last of the DISCUSS issues that requires a bit of airing. The rest are fairly straight forward and I'll send the proposed edits for those shortly. I've been putting this one off since the choice seems to be between delaying the document or making a change I'm not all that happy with. One of our DISCUSS issues is that there is an objection to using URL-based schema locations in import statements. The concern is that this will cause a lot of traffic to IETF/IANA websites by dumb tools. Although I think a lot of us prefer URL-based locations since it would mean people won't have to spend as much time hunting down and extracting Schema as they did with MIBs, there is a realization that fighting this might result in a delay in publication of the Notification work. The proposed resolution would be to continue this discussion for the sake of future specifications, but to make the following change to this one: Replace With (I think) To: Subject: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi This is the last of the DISCUSS issues that requires a bit of airing. The rest are fairly straight forward and I'll send the proposed edits for those shortly. I've been putting this one off since the choice seems to be between delaying the document or making a change I'm not all that happy with. One of our DISCUSS issues is that there is an objection to using URL-based schema locations in import statements. The concern is that this will cause a lot of traffic to IETF/IANA websites by dumb tools. Although I think a lot of us prefer URL-based locations since it would mean people won't have to spend as much time hunting down and extracting Schema as they did with MIBs, there is a realization that fighting this might result in a delay in publication of the Notification work. The proposed resolution would be to continue this discussion for the sake of future specifications, but to make the following change to this one: Replace With (I think) Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf nf:notification:1.0"/> Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 10:30:19 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B839E3A6F63; Mon, 21 Apr 2008 10:30:19 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 739D13A6F69 for ; Mon, 21 Apr 2008 10:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=0.771, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNM4bND6oy8T for ; Mon, 21 Apr 2008 10:30:14 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id E10353A6F60 for ; Mon, 21 Apr 2008 10:30:11 -0700 (PDT) Received: (qmail 55814 invoked from network); 21 Apr 2008 17:30:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.208 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 21 Apr 2008 17:30:16 -0000 X-YMail-OSG: ulpYpDIVM1nds20O3U.TgKRaJxLd.i2C1gG.4TofR.O7_E1ag54VG3mz6VrMPa9cH35O9IitnqrkDlfuiA4916yI0Kem_q6MLxJ7TgbPUN5fpyFfCivKtqAqjBQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <480CCF26.4020607@andybierman.com> Date: Mon, 21 Apr 2008 10:30:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B41426EB6B@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41426EB6B@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > > This is the last of the DISCUSS issues that requires a bit of airing. > The rest are fairly straight forward and I'll send the proposed edits > for those shortly. I've been putting this one off since the choice seems > to be between delaying the document or making a change I'm not all that > happy with. > > One of our DISCUSS issues is that there is an objection to using > URL-based schema locations in import statements. The concern is that > this will cause a lot of traffic to IETF/IANA websites by dumb tools. > Although I think a lot of us prefer URL-based locations since it would > mean people won't have to spend as much time hunting down and extracting > Schema as they did with MIBs, there is a realization that fighting this > might result in a delay in publication of the Notification work. > I do not agree with the problem statement. Is there a demonstrated impact on the ietf.org WEB site due to 'over-use' of the IANA registries? When the IETF posts files in the xml-registry/schema directory, is the expectation that only humans will retrieve the files, and HTML caches will not be used, causing repeated retrievals? I do not understand this objection. Isn't the point of the IANA registries to have a stable home for standard-related data which may need to be retrieved by applications or humans? ApplicatioFrom netconf-bounces@ietf.org Mon Apr 21 10:30:19 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B839E3A6F63; Mon, 21 Apr 2008 10:30:19 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 739D13A6F69 for ; Mon, 21 Apr 2008 10:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=0.771, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNM4bND6oy8T for ; Mon, 21 Apr 2008 10:30:14 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id E10353A6F60 for ; Mon, 21 Apr 2008 10:30:11 -0700 (PDT) Received: (qmail 55814 invoked from network); 21 Apr 2008 17:30:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.208 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 21 Apr 2008 17:30:16 -0000 X-YMail-OSG: ulpYpDIVM1nds20O3U.TgKRaJxLd.i2C1gG.4TofR.O7_E1ag54VG3mz6VrMPa9cH35O9IitnqrkDlfuiA4916yI0Kem_q6MLxJ7TgbPUN5fpyFfCivKtqAqjBQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <480CCF26.4020607@andybierman.com> Date: Mon, 21 Apr 2008 10:30:14 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B41426EB6B@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41426EB6B@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > > This is the last of the DISCUSS issues that requires a bit of airing. > The rest are fairly straight forward and I'll send the proposed edits > for those shortly. I've been putting this one off since the choice seems > to be between delaying the document or making a change I'm not all that > happy with. > > One of our DISCUSS issues is that there is an objection to using > URL-based schema locations in import statements. The concern is that > this will cause a lot of traffic to IETF/IANA websites by dumb tools. > Although I think a lot of us prefer URL-based locations since it would > mean people won't have to spend as much time hunting down and extracting > Schema as they did with MIBs, there is a realization that fighting this > might result in a delay in publication of the Notification work. > I do not agree with the problem statement. Is there a demonstrated impact on the ietf.org WEB site due to 'over-use' of the IANA registries? When the IETF posts files in the xml-registry/schema directory, is the expectation that only humans will retrieve the files, and HTML caches will not be used, causing repeated retrievals? I do not understand this objection. Isn't the point of the IANA registries to have a stable home for standard-related data which may need to be retrieved by applications or humans? Applications which utilize the schemaLocation attribute for finding XSDs they do not know about are not dumb. The purpose of the schemaLocation attribute is to provide a URL associated with a schema that defines the namespace contents. This field is not supposed to contain a generic URN. Andy > The proposed resolution would be to continue this discussion for the > sake of future specifications, but to make the following change to this > one: > > Replace > > schemaLocation= > "http://www.iana.org/assignments/xml-registry/schema/netconf.xsd"/> > "urn:ietf:params:xml:ns:netconf:notification:1.0" > schemaLocation= > "http://www.iana.org/assignments/xml-registry/schema/notification.xsd"/> > > With (I think) > > schemaLocation= > "urn:ietf:params:xml:ns:netconf:base:1.0"/> > "urn:ietf:params:xml:ns:netconf:notification:1.0" > schemaLocation= > "urn:ietf:params:xml:ns:netconf:notification:1.0"/> > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ns which utilize the schemaLocation attribute for finding XSDs they do not know about are not dumb. The purpose of the schemaLocation attribute is to provide a URL associated with a schema that defines the namespace contents. This field is not supposed to contain a generic URN. Andy > The proposed resolution would be to continue this discussion for the > sake of future specifications, but to make the following change to this > one: > > Replace > > schemaLocation= > "http://www.iana.org/assignments/xml-registry/schema/netconf.xsd"/> > "urn:ietf:params:xml:ns:netconf:notification:1.0" > schemaLocation= > "http://www.iana.org/assignments/xml-registry/schema/notification.xsd"/> > > With (I think) > > schemaLocation= > "urn:ietf:params:xml:ns:netconf:base:1.0"/> > "urn:ietf:params:xml:ns:netconf:notification:1.0" > schemaLocation= > "urn:ietf:params:xml:ns:netconf:notification:1.0"/> > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 10:49:38 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3E9E3A6C0B; Mon, 21 Apr 2008 10:49:38 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10BCA3A6835 for ; Mon, 21 Apr 2008 10:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNafQxR8cLVv for ; Mon, 21 Apr 2008 10:49:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F2DB13A69B4 for ; Mon, 21 Apr 2008 10:49:35 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 75A9BC000D; Mon, 21 Apr 2008 19:49:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tTj99RfiYL8H; Mon, 21 Apr 2008 19:49:36 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 35849C0012; Mon, 21 Apr 2008 19:49:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A5408542783; Mon, 21 Apr 2008 19:49:35 +0200 (CEST) Date: Mon, 21 Apr 2008 19:49:35 +0200 From: Juergen Schoenwaelder To: Sharon Chisholm Message-ID: <20080421174935.GA9485@elstar.local> Mail-Followup-To: Sharon Chisholm , netconf@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B41426EB6B@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41426EB6B@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Mon, Apr 21, 2008 at 12:41:49PM -0400, Sharon Chisholm wrote: > The proposed resolution would be to continue this discussion for the > sake of future specifications, but to make the following change to this > one: [...] Does it make sense to store a URN in schemaLocation? Perhaps simply dropping the whole attribute is a simpler solution. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 10:49:38 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3E9E3A6C0B; Mon, 21 Apr 2008 10:49:38 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10BCA3A6835 for ; Mon, 21 Apr 2008 10:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNafQxR8cLVv for ; Mon, 21 Apr 2008 10:49:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F2DB13A69B4 for ; Mon, 21 Apr 2008 10:49:35 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 75A9BC000D; Mon, 21 Apr 2008 19:49:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tTj99RfiYL8H; Mon, 21 Apr 2008 19:49:36 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 35849C0012; Mon, 21 Apr 2008 19:49:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A5408542783; Mon, 21 Apr 2008 19:49:35 +0200 (CEST) Date: Mon, 21 Apr 2008 19:49:35 +0200 From: Juergen Schoenwaelder To: Sharon Chisholm Message-ID: <20080421174935.GA9485@elstar.local> Mail-Followup-To: Sharon Chisholm , netconf@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B41426EB6B@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41426EB6B@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Mon, Apr 21, 2008 at 12:41:49PM -0400, Sharon Chisholm wrote: > The proposed resolution would be to continue this discussion for the > sake of future specifications, but to make the following change to this > one: [...] Does it make sense to store a URN in schemaLocation? Perhaps simply dropping the whole attribute is a simpler solution. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 11:09:57 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3EDF3A6F68; Mon, 21 Apr 2008 11:09:57 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C6123A6F5D for ; Mon, 21 Apr 2008 11:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0a9wOP3ujBNj for ; Mon, 21 Apr 2008 11:09:53 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 77F443A6F49 for ; Mon, 21 Apr 2008 11:09:53 -0700 (PDT) Received: (qmail 21124 invoked from network); 21 Apr 2008 18:09:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.208 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 21 Apr 2008 18:09:58 -0000 X-YMail-OSG: Pxn1zWkVM1krH.27wI50LLHyeMWefrfyZ29N00pV18ey2.SQVhjRzIFsPBnFsyp33iqVBgkUBKZwnxk0uhsU8WeAFuTFIjXldQkl1qNC_Pyjbg_K.neVm963VpM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <480CD874.6040802@andybierman.com> Date: Mon, 21 Apr 2008 11:09:56 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Sharon Chisholm , netconf@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B41426EB6B@zcarhxm2.corp.nortel.com> <20080421174935.GA9485@elstar.local> In-Reply-To: <20080421174935.GA9485@elstar.local> Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > On Mon, Apr 21, 2008 at 12:41:49PM -0400, Sharon Chisholm wrote: > = >> The proposed resolution would be to continue this discussion for the sak= e of future >> specifications, but to make the following change to this one: > = > [...] > = > Does it make sense to store a URN in schemaLocation? Perhaps simply dropp= ing the whole attribute > is a simpler solution. > = I agree that no schemaLocation attribute has as much value as having one which does not contain a URL. I think automated retrieval of XSDs via schemaLocation is a feature, not something that will cause harm to the Internet. From the spec: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-= import The element information item identifies namespaces used in externa= l references, i.e. those whose =B7QName=B7 identifies them as coming from a different namespace (or = none) than the enclosing schema document's targetNamespace. The =B7actual value=B7 of its namespace = [attribute] indicates that the containing schema document may contain qualified references to schema c= omponents in that namespace (via one or more prefixes declared with namespace declarations in= the normal way). If that attribute is absent, then the import allows unqualified reference to c= omponents with From netconf-bounces@ietf.org Mon Apr 21 11:09:57 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3EDF3A6F68; Mon, 21 Apr 2008 11:09:57 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C6123A6F5D for ; Mon, 21 Apr 2008 11:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0a9wOP3ujBNj for ; Mon, 21 Apr 2008 11:09:53 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 77F443A6F49 for ; Mon, 21 Apr 2008 11:09:53 -0700 (PDT) Received: (qmail 21124 invoked from network); 21 Apr 2008 18:09:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.208 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 21 Apr 2008 18:09:58 -0000 X-YMail-OSG: Pxn1zWkVM1krH.27wI50LLHyeMWefrfyZ29N00pV18ey2.SQVhjRzIFsPBnFsyp33iqVBgkUBKZwnxk0uhsU8WeAFuTFIjXldQkl1qNC_Pyjbg_K.neVm963VpM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <480CD874.6040802@andybierman.com> Date: Mon, 21 Apr 2008 11:09:56 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Sharon Chisholm , netconf@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B41426EB6B@zcarhxm2.corp.nortel.com> <20080421174935.GA9485@elstar.local> In-Reply-To: <20080421174935.GA9485@elstar.local> Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > On Mon, Apr 21, 2008 at 12:41:49PM -0400, Sharon Chisholm wrote: > = >> The proposed resolution would be to continue this discussion for the sak= e of future >> specifications, but to make the following change to this one: > = > [...] > = > Does it make sense to store a URN in schemaLocation? Perhaps simply dropp= ing the whole attribute > is a simpler solution. > = I agree that no schemaLocation attribute has as much value as having one which does not contain a URL. I think automated retrieval of XSDs via schemaLocation is a feature, not something that will cause harm to the Internet. From the spec: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-= import The element information item identifies namespaces used in externa= l references, i.e. those whose =B7QName=B7 identifies them as coming from a different namespace (or = none) than the enclosing schema document's targetNamespace. The =B7actual value=B7 of its namespace = [attribute] indicates that the containing schema document may contain qualified references to schema c= omponents in that namespace (via one or more prefixes declared with namespace declarations in= the normal way). If that attribute is absent, then the import allows unqualified reference to c= omponents with no tarno target namespace. Note that components to be imported need not be in the form of a= =B7schema document=B7; the processor is free to access or construct components using means of its own = choosing. The =B7actual value=B7 of the schemaLocation, if present, gives a hint as t= o where a serialization of a =B7schema document=B7 with declarations and definitions for that namespace = (or none) may be found. When no schemaLocation [attribute] is present, the schema author is leaving the = identification of that schema to the instance, application or user, via the mechanisms described b= elow in Layer 3: Schema Document Access and Web-interoperability (=A74.3). When a schemaLocation is= present, it must contain a single URI reference which the schema author warrants will resolve to a s= erialization of a =B7schema document=B7 containing the component(s) in the ed namespa= ce referred to elsewhere in the containing schema document. > /js > = Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf get namespace. Note that components to be imported need not be in the form of a= =B7schema document=B7; the processor is free to access or construct components using means of its own = choosing. The =B7actual value=B7 of the schemaLocation, if present, gives a hint as t= o where a serialization of a =B7schema document=B7 with declarations and definitions for that namespace = (or none) may be found. When no schemaLocation [attribute] is present, the schema author is leaving the = identification of that schema to the instance, application or user, via the mechanisms described b= elow in Layer 3: Schema Document Access and Web-interoperability (=A74.3). When a schemaLocation is= present, it must contain a single URI reference which the schema author warrants will resolve to a s= erialization of a =B7schema document=B7 containing the component(s) in the ed namespa= ce referred to elsewhere in the containing schema document. > /js > = Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 11:17:30 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4141F3A69B4; Mon, 21 Apr 2008 11:17:30 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A0A3A6D1C for ; Mon, 21 Apr 2008 11:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVK2-I7W4Iy6 for ; Mon, 21 Apr 2008 11:17:22 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id CFDC228C434 for ; Mon, 21 Apr 2008 11:16:54 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3LIGvp27790; Mon, 21 Apr 2008 18:16:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Apr 2008 14:16:35 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41426EE25@zcarhxm2.corp.nortel.com> In-Reply-To: <480CD874.6040802@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Netconf Notification: Issues 22: Import Statements Thread-Index: Acij2uyhdmoG4XDwS3aQAkZqEsCGYwAAFy1g References: <713043CE8B8E1348AF3C546DBE02C1B41426EB6B@zcarhxm2.corp.nortel.com> <20080421174935.GA9485@elstar.local> <480CD874.6040802@andybierman.com> From: "Sharon Chisholm" To: "Andy Bierman" , Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi To be fair, I should probably provide some more content from those opposed = to URL-based schema locations. Personally, I think we need them. - This is apparently a long standing IETF policy - W3C gets a lot of hits http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic - "At the time of this writing, IANA or IETF does not provide a registratio= n service for HTTP URLs (something they'd commit to being stable and pointi= ng to the same file over long term). Creating such a service has indeed been proposed -- but do we want to block= this document until that proposal has been accepted?" Sharon = -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com] = Sent: Monday, April 21, 2008 2:10 PM To: Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements Juergen Schoenwaelder wrote: > On Mon, Apr 21, 2008 at 12:41:49PM -0400, Sharon Chisholm wrote: > = >> The proposed resolution would be to continue this discussion for the = >> sake of future specifications, but to make the following change to this = one: > = > [...] > = > Does it make sense to store a URN in schemaLocation? Perhaps simply = > dropping the whole attribute is a simpler solution. > = I agree that no schemaLocation attribute has as much value as having one wh= ich does not contain a URL. I think automated retrieval of XSDs via schema= Location is a feature, not something that will cause harm to the Internet. From the spec: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-= import The element information item identifies namespaces used in externa= l references, i.e. those whose =B7QName=B7 identifies them as coming from a= different namespace (or none) than the enclosing schema document's targetN= amespace. The =B7actual value=B7 of its namespace [attribute] indicates tha= t the containing schema document may contain qualified references to schema= components in that namespace (via one or more prefixes declared with names= pace declarations in the normal way). If that attribute is absent, then the= import allows unqualified reference to components with no target namespace= . Note that components to be imported need not be in the form of a =B7schem= a document=B7; the processor is free to access or construct components usin= g means of its own choosing. The =B7actual value=B7 of the schemaLocation, if present, gives a hint as t= o where a serialization of a =B7schema document=B7 with declarations and de= finitions for that namespace (or none) may be found. When no schemaLocation= [attribute] is present, the schema author is leaving the identification of= that schema to the instance, application or user, via the mechanisms descr= ibed below in Layer 3: Schema Document Access and Web-interoperability (=A7= 4.3). When a schemaLocation is present, it must contain a single URI refere= nce which the schema author warrants will resolve to a serialization of a = =B7schema document=B7 containing the component(s) in the ed namespa= ce referred to elsewhere in the containing schema document. > /js > = Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 11:17:30 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4141F3A69B4; Mon, 21 Apr 2008 11:17:30 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A0A3A6D1C for ; Mon, 21 Apr 2008 11:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVK2-I7W4Iy6 for ; Mon, 21 Apr 2008 11:17:22 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id CFDC228C434 for ; Mon, 21 Apr 2008 11:16:54 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3LIGvp27790; Mon, 21 Apr 2008 18:16:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Apr 2008 14:16:35 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41426EE25@zcarhxm2.corp.nortel.com> In-Reply-To: <480CD874.6040802@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Netconf Notification: Issues 22: Import Statements Thread-Index: Acij2uyhdmoG4XDwS3aQAkZqEsCGYwAAFy1g References: <713043CE8B8E1348AF3C546DBE02C1B41426EB6B@zcarhxm2.corp.nortel.com> <20080421174935.GA9485@elstar.local> <480CD874.6040802@andybierman.com> From: "Sharon Chisholm" To: "Andy Bierman" , Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi To be fair, I should probably provide some more content from those opposed = to URL-based schema locations. Personally, I think we need them. - This is apparently a long standing IETF policy - W3C gets a lot of hits http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic - "At the time of this writing, IANA or IETF does not provide a registratio= n service for HTTP URLs (something they'd commit to being stable and pointi= ng to the same file over long term). Creating such a service has indeed been proposed -- but do we want to block= this document until that proposal has been accepted?" Sharon = -----Original Message----- From: Andy Bierman [mailto:ietf@andybierman.com] = Sent: Monday, April 21, 2008 2:10 PM To: Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements Juergen Schoenwaelder wrote: > On Mon, Apr 21, 2008 at 12:41:49PM -0400, Sharon Chisholm wrote: > = >> The proposed resolution would be to continue this discussion for the = >> sake of future specifications, but to make the following change to this = one: > = > [...] > = > Does it make sense to store a URN in schemaLocation? Perhaps simply = > dropping the whole attribute is a simpler solution. > = I agree that no schemaLocation attribute has as much value as having one wh= ich does not contain a URL. I think automated retrieval of XSDs via schema= Location is a feature, not something that will cause harm to the Internet. From the spec: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-= import The element information item identifies namespaces used in externa= l references, i.e. those whose =B7QName=B7 identifies them as coming from a= different namespace (or none) than the enclosing schema document's targetN= amespace. The =B7actual value=B7 of its namespace [attribute] indicates tha= t the containing schema document may contain qualified references to schema= components in that namespace (via one or more prefixes declared with names= pace declarations in the normal way). If that attribute is absent, then the= import allows unqualified reference to components with no target namespace= . Note that components to be imported need not be in the form of a =B7schem= a document=B7; the processor is free to access or construct components usin= g means of its own choosing. The =B7actual value=B7 of the schemaLocation, if present, gives a hint as t= o where a serialization of a =B7schema document=B7 with declarations and de= finitions for that namespace (or none) may be found. When no schemaLocation= [attribute] is present, the schema author is leaving the identification of= that schema to the instance, application or user, via the mechanisms descr= ibed below in Layer 3: Schema Document Access and Web-interoperability (=A7= 4.3). When a schemaLocation is present, it must contain a single URI refere= nce which the schema author warrants will resolve to a serialization of a = =B7schema document=B7 containing the component(s) in the ed namespa= ce referred to elsewhere in the containing schema document. > /js > = Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 11:36:20 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46CF13A6B3C; Mon, 21 Apr 2008 11:36:20 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE93B3A68FE for ; Mon, 21 Apr 2008 11:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiZt-kOfhRkC for ; Mon, 21 Apr 2008 11:36:19 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 9290D28C446 for ; Mon, 21 Apr 2008 11:36:07 -0700 (PDT) Received: (qmail 36041 invoked from network); 21 Apr 2008 18:36:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.208 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 21 Apr 2008 18:36:12 -0000 X-YMail-OSG: _ktbbdIVM1linkYlV16hzsV7tORgzbGvkhjzf8j0omuYoCZAdcJ8CvLpOEbWAKcsJGbHh42iRPbtpYp0d9nuStUE1qaB0rXFYU4g.34R2IESvccVF_Nlym6_fxE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <480CDE9A.5030304@andybierman.com> Date: Mon, 21 Apr 2008 11:36:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B41426EB6B@zcarhxm2.corp.nortel.com> <20080421174935.GA9485@elstar.local> <480CD874.6040802@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B41426EE25@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41426EE25@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > = > To be fair, I should probably provide some more content from those oppose= d to URL-based schema locations. Personally, I think we need them. > = > - This is apparently a long standing IETF policy > = > - W3C gets a lot of hits > http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic > = > - "At the time of this writing, IANA or IETF does not provide a registrat= ion service for HTTP URLs (something they'd commit to being stable and poin= ting to the same file over long term). > = > Creating such a service has indeed been proposed -- but do we want to blo= ck this document until that proposal has been accepted?" > = I think Juergen's suggestion of removing the schemaLocation attribute is the least worst option. > Sharon Andy > = > = > = > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] = > Sent: Monday, April 21, 2008 2:10 PM > To: Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org > Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements > = > Juergen Schoenwaelder wrote: >> On Mon, Apr 21, 2008 at 12:41:49PM -0400, Sharon Chisholm wrote: >> >>> The proposed resolution would be to continue this discussion for the = >>> sake of future specifications, but to make the following change to this= one: >> [...] >> >> Does it make sense to store a URN in schemaLocation? Perhaps simply = >> dropping the whole attribute is a simpler solution. >> > = > I agree that no schemaLocation attribute has as much value as having one = which does not contain a URL. I think automated retrieval of XSDs via sche= maLocation is a feature, not something that will cause harm to the Internet. > = > = > From the spec: > http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#elemen= t-import > = > The element information item identifies namespaces used in exter= nal references, i.e. those whose =B7QName=B7 identifies them as coming from= a different namespace (or none) than the enclosing schema document's targe= tNamespace. The =B7actual value=B7 of its namespace [attribute] indicates t= hat the containing schema document may contain qualified references to sche= ma components in that namespace (via one or more prefixes declared with nam= espace declarations in the normal way). If that attribute is absent, then t= he import allows unqualified reference to components with no target namespa= ce. Note that components to be imported need not be in the form of a =B7sch= ema document=B7; the processor is free to access or construct components us= ing means of its own choosing. > = > The =B7actual value=B7 of the schemaLocation, if present, gives a hint as= to where a serialization of a =B7schema document=B7 with declarations and = definitions for that namespace (or none) may be found. When no schemaLocati= on [attribute] is present, the schema author is leaving the identification = of that schema to the instance, application or user, via the mechanisms des= cribed below in Layer 3: Schema Document Access and Web-interoperability (= =A74.3). When a schemaLocation is present, it must contain a single URI ref= erence which the schema author warrants will resolve to a serialization of = a =B7schema document=B7 containing the component(s) in the ed names= pace referred to elsewhere in the containing schema document. > = > = >> /js >> > = > Andy > = > = > = > = _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 11:36:20 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46CF13A6B3C; Mon, 21 Apr 2008 11:36:20 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE93B3A68FE for ; Mon, 21 Apr 2008 11:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiZt-kOfhRkC for ; Mon, 21 Apr 2008 11:36:19 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 9290D28C446 for ; Mon, 21 Apr 2008 11:36:07 -0700 (PDT) Received: (qmail 36041 invoked from network); 21 Apr 2008 18:36:13 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.208 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 21 Apr 2008 18:36:12 -0000 X-YMail-OSG: _ktbbdIVM1linkYlV16hzsV7tORgzbGvkhjzf8j0omuYoCZAdcJ8CvLpOEbWAKcsJGbHh42iRPbtpYp0d9nuStUE1qaB0rXFYU4g.34R2IESvccVF_Nlym6_fxE- X-Yahoo-Newman-Property: ymail-3 Message-ID: <480CDE9A.5030304@andybierman.com> Date: Mon, 21 Apr 2008 11:36:10 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B41426EB6B@zcarhxm2.corp.nortel.com> <20080421174935.GA9485@elstar.local> <480CD874.6040802@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B41426EE25@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41426EE25@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > Hi > = > To be fair, I should probably provide some more content from those oppose= d to URL-based schema locations. Personally, I think we need them. > = > - This is apparently a long standing IETF policy > = > - W3C gets a lot of hits > http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic > = > - "At the time of this writing, IANA or IETF does not provide a registrat= ion service for HTTP URLs (something they'd commit to being stable and poin= ting to the same file over long term). > = > Creating such a service has indeed been proposed -- but do we want to blo= ck this document until that proposal has been accepted?" > = I think Juergen's suggestion of removing the schemaLocation attribute is the least worst option. > Sharon Andy > = > = > = > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] = > Sent: Monday, April 21, 2008 2:10 PM > To: Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org > Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements > = > Juergen Schoenwaelder wrote: >> On Mon, Apr 21, 2008 at 12:41:49PM -0400, Sharon Chisholm wrote: >> >>> The proposed resolution would be to continue this discussion for the = >>> sake of future specifications, but to make the following change to this= one: >> [...] >> >> Does it make sense to store a URN in schemaLocation? Perhaps simply = >> dropping the whole attribute is a simpler solution. >> > = > I agree that no schemaLocation attribute has as much value as having one = which does not contain a URL. I think automated retrieval of XSDs via sche= maLocation is a feature, not something that will cause harm to the Internet. > = > = > From the spec: > http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#elemen= t-import > = > The element information item identifies namespaces used in exter= nal references, i.e. those whose =B7QName=B7 identifies them as coming from= a different namespace (or none) than the enclosing schema document's targe= tNamespace. The =B7actual value=B7 of its namespace [attribute] indicates t= hat the containing schema document may contain qualified references to sche= ma components in that namespace (via one or more prefixes declared with nam= espace declarations in the normal way). If that attribute is absent, then t= he import allows unqualified reference to components with no target namespa= ce. Note that components to be imported need not be in the form of a =B7sch= ema document=B7; the processor is free to access or construct components us= ing means of its own choosing. > = > The =B7actual value=B7 of the schemaLocation, if present, gives a hint as= to where a serialization of a =B7schema document=B7 with declarations and = definitions for that namespace (or none) may be found. When no schemaLocati= on [attribute] is present, the schema author is leaving the identification = of that schema to the instance, application or user, via the mechanisms des= cribed below in Layer 3: Schema Document Access and Web-interoperability (= =A74.3). When a schemaLocation is present, it must contain a single URI ref= erence which the schema author warrants will resolve to a serialization of = a =B7schema document=B7 containing the component(s) in the ed names= pace referred to elsewhere in the containing schema document. > = > = >> /js >> > = > Andy > = > = > = > = _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 11:41:02 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52E3628C425; Mon, 21 Apr 2008 11:41:02 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69B963A6835 for ; Mon, 21 Apr 2008 11:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRE+HITbhYQk for ; Mon, 21 Apr 2008 11:40:56 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 93BC528C43D for ; Mon, 21 Apr 2008 11:40:56 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 6A4411B80C7; Mon, 21 Apr 2008 20:41:02 +0200 (CEST) Date: Mon, 21 Apr 2008 20:40:41 +0200 (CEST) Message-Id: <20080421.204041.262826694.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <480CDE9A.5030304@andybierman.com> References: <480CD874.6040802@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B41426EE25@zcarhxm2.corp.nortel.com> <480CDE9A.5030304@andybierman.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > I think Juergen's suggestion of removing the schemaLocation attribute > is the least worst option. I agree. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 11:41:02 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52E3628C425; Mon, 21 Apr 2008 11:41:02 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69B963A6835 for ; Mon, 21 Apr 2008 11:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRE+HITbhYQk for ; Mon, 21 Apr 2008 11:40:56 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 93BC528C43D for ; Mon, 21 Apr 2008 11:40:56 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 6A4411B80C7; Mon, 21 Apr 2008 20:41:02 +0200 (CEST) Date: Mon, 21 Apr 2008 20:40:41 +0200 (CEST) Message-Id: <20080421.204041.262826694.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <480CDE9A.5030304@andybierman.com> References: <480CD874.6040802@andybierman.com> <713043CE8B8E1348AF3C546DBE02C1B41426EE25@zcarhxm2.corp.nortel.com> <480CDE9A.5030304@andybierman.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > I think Juergen's suggestion of removing the schemaLocation attribute > is the least worst option. I agree. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 12:18:47 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B43E13A6DAD; Mon, 21 Apr 2008 12:18:47 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F9DA28C17C for ; Mon, 21 Apr 2008 12:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7nl0--FyClu for ; Mon, 21 Apr 2008 12:18:41 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 47B223A691E for ; Mon, 21 Apr 2008 12:18:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=MFYAgpBvWfSd5RMlQLS7u3ocjB40rzYU4nLzAFgrvQ/RBypIIaqUS5PTNhpz+kS/; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.80.109] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Jo1XL-000722-7b for netconf@ietf.org; Mon, 21 Apr 2008 15:18:47 -0400 Message-ID: <001201c8a3dc$48055220$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <480CD874.6040802@andybierman.com><713043CE8B8E1348AF3C546DBE02C1B41426EE25@zcarhxm2.corp.nortel.com><480CDE9A.5030304@andybierman.com> <20080421.204041.262826694.mbj@tail-f.com> Date: Mon, 21 Apr 2008 12:19:46 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117ad62947f5a1eb177112087a1e80c87bd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.109 Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Monday, April 21, 2008 12:40 PM > Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements > > Andy Bierman wrote: > > I think Juergen's suggestion of removing the schemaLocation attribute > > is the least worst option. > > I agree. As long as the solution is no worse than SNMP, and gets the work unstuck, in IETF terms we should consider it progress. Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 12:18:47 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B43E13A6DAD; Mon, 21 Apr 2008 12:18:47 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F9DA28C17C for ; Mon, 21 Apr 2008 12:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7nl0--FyClu for ; Mon, 21 Apr 2008 12:18:41 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 47B223A691E for ; Mon, 21 Apr 2008 12:18:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=MFYAgpBvWfSd5RMlQLS7u3ocjB40rzYU4nLzAFgrvQ/RBypIIaqUS5PTNhpz+kS/; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.80.109] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Jo1XL-000722-7b for netconf@ietf.org; Mon, 21 Apr 2008 15:18:47 -0400 Message-ID: <001201c8a3dc$48055220$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <480CD874.6040802@andybierman.com><713043CE8B8E1348AF3C546DBE02C1B41426EE25@zcarhxm2.corp.nortel.com><480CDE9A.5030304@andybierman.com> <20080421.204041.262826694.mbj@tail-f.com> Date: Mon, 21 Apr 2008 12:19:46 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117ad62947f5a1eb177112087a1e80c87bd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.80.109 Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Monday, April 21, 2008 12:40 PM > Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements > > Andy Bierman wrote: > > I think Juergen's suggestion of removing the schemaLocation attribute > > is the least worst option. > > I agree. As long as the solution is no worse than SNMP, and gets the work unstuck, in IETF terms we should consider it progress. Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 12:29:27 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90FAB3A6B16; Mon, 21 Apr 2008 12:29:27 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB66B3A6B16 for ; Mon, 21 Apr 2008 12:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AzSq9EqlqrX for ; Mon, 21 Apr 2008 12:29:26 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id D91F83A6B09 for ; Mon, 21 Apr 2008 12:29:25 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m3LJTVgd011060 for ; Mon, 21 Apr 2008 15:29:31 -0400 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m3LJTVtG011055 for ; Mon, 21 Apr 2008 15:29:31 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Apr 2008 15:28:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Apr 2008 15:27:52 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F029E34AA@IMCSRV2.MITRE.ORG> In-Reply-To: <20080421.204041.262826694.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Netconf Notification: Issues 22: Import Statements Thread-Index: Acij33/2Weass4e/Qdmm/WxwMJ1EhQAAzl7A References: <480CD874.6040802@andybierman.com><713043CE8B8E1348AF3C546DBE02C1B41426EE25@zcarhxm2.corp.nortel.com><480CDE9A.5030304@andybierman.com> <20080421.204041.262826694.mbj@tail-f.com> From: "Natale, Bob" To: X-OriginalArrivalTime: 21 Apr 2008 19:28:44.0360 (UTC) FILETIME=[E9B12C80:01C8A3E5] Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I agree also. Just two associated points from the broader thread - A registry is logically distinct from a repository. The IETF probably needs IANA to provide a registry for such artifacts (well-known source for authoritative information about somethings), but IANA might not want to provide the corresponding (and possibly distributed) repository service (the location where the somethings can be gotten). Indeed, as W3C found, no organization should sign-up to deliver a service (esp. implicitly) w/o considering supply, demand, administration, cost-recovery, priorities, trade-offs, etc. - For IETF *standard* MIBs, I guess, roughly speaking, that the RFC database was the repository (assuming the necessary extraction function) and the latest RFC index (RFC n000) was the registry (assuming inclusion of new RFCs in between indexes n and n+1). Cheers, BobN -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Martin Bjorklund Sent: Monday, April 21, 2008 2:41 PM To: ietf@andybierman.com Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements Andy Bierman wrote: > I think Juergen's suggestion of removing the schemaLocation attribute > is the least worst option. I agree. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 12:29:27 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90FAB3A6B16; Mon, 21 Apr 2008 12:29:27 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB66B3A6B16 for ; Mon, 21 Apr 2008 12:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AzSq9EqlqrX for ; Mon, 21 Apr 2008 12:29:26 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id D91F83A6B09 for ; Mon, 21 Apr 2008 12:29:25 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m3LJTVgd011060 for ; Mon, 21 Apr 2008 15:29:31 -0400 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m3LJTVtG011055 for ; Mon, 21 Apr 2008 15:29:31 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Apr 2008 15:28:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Apr 2008 15:27:52 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F029E34AA@IMCSRV2.MITRE.ORG> In-Reply-To: <20080421.204041.262826694.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Netconf Notification: Issues 22: Import Statements Thread-Index: Acij33/2Weass4e/Qdmm/WxwMJ1EhQAAzl7A References: <480CD874.6040802@andybierman.com><713043CE8B8E1348AF3C546DBE02C1B41426EE25@zcarhxm2.corp.nortel.com><480CDE9A.5030304@andybierman.com> <20080421.204041.262826694.mbj@tail-f.com> From: "Natale, Bob" To: X-OriginalArrivalTime: 21 Apr 2008 19:28:44.0360 (UTC) FILETIME=[E9B12C80:01C8A3E5] Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I agree also. Just two associated points from the broader thread - A registry is logically distinct from a repository. The IETF probably needs IANA to provide a registry for such artifacts (well-known source for authoritative information about somethings), but IANA might not want to provide the corresponding (and possibly distributed) repository service (the location where the somethings can be gotten). Indeed, as W3C found, no organization should sign-up to deliver a service (esp. implicitly) w/o considering supply, demand, administration, cost-recovery, priorities, trade-offs, etc. - For IETF *standard* MIBs, I guess, roughly speaking, that the RFC database was the repository (assuming the necessary extraction function) and the latest RFC index (RFC n000) was the registry (assuming inclusion of new RFCs in between indexes n and n+1). Cheers, BobN -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Martin Bjorklund Sent: Monday, April 21, 2008 2:41 PM To: ietf@andybierman.com Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements Andy Bierman wrote: > I think Juergen's suggestion of removing the schemaLocation attribute > is the least worst option. I agree. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 12:37:33 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABCC328C419; Mon, 21 Apr 2008 12:37:33 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FDFB3A6F73 for ; Mon, 21 Apr 2008 12:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XENxDr9I8mA0 for ; Mon, 21 Apr 2008 12:37:32 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 1449928C423 for ; Mon, 21 Apr 2008 12:37:31 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Mon, 21 Apr 2008 12:37:24 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Apr 2008 12:33:27 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m3LJXRD16621; Mon, 21 Apr 2008 12:33:27 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m3LJVwLZ035874; Mon, 21 Apr 2008 19:31:58 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200804211931.m3LJVwLZ035874@idle.juniper.net> To: "Randy Presuhn" In-reply-to: <001201c8a3dc$48055220$6801a8c0@oemcomputer> Date: Mon, 21 Apr 2008 15:31:58 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Apr 2008 19:33:27.0330 (UTC) FILETIME=[925AF820:01C8A3E6] Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Randy Presuhn" writes: >As long as the solution is no worse than SNMP, >and gets the work unstuck, >in IETF terms we should consider it progress. That's too close to haiku to leave it alone: No worse than SNMP The IETF Should consider it progress But seriously, is the IESG refusing to host XSD files in the basis that another standards organizations that hosts a file referenced by a zillion web pages gets significant hits from crappy software? If the number of crappy netconf implementations ever reaches a number where it can be called significant, we can declare netconf successful. The problem is that this is a bad precedent, meaning the IETF will likely refuse to host YANG files and other netconf collateral that applications will need access to. Yes, this can be solved by yang-central.org, but it sure seems like putting this material on ietf/iana/iesg/imumble.org would be better. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 12:37:33 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABCC328C419; Mon, 21 Apr 2008 12:37:33 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FDFB3A6F73 for ; Mon, 21 Apr 2008 12:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XENxDr9I8mA0 for ; Mon, 21 Apr 2008 12:37:32 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 1449928C423 for ; Mon, 21 Apr 2008 12:37:31 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Mon, 21 Apr 2008 12:37:24 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Apr 2008 12:33:27 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m3LJXRD16621; Mon, 21 Apr 2008 12:33:27 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m3LJVwLZ035874; Mon, 21 Apr 2008 19:31:58 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200804211931.m3LJVwLZ035874@idle.juniper.net> To: "Randy Presuhn" In-reply-to: <001201c8a3dc$48055220$6801a8c0@oemcomputer> Date: Mon, 21 Apr 2008 15:31:58 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Apr 2008 19:33:27.0330 (UTC) FILETIME=[925AF820:01C8A3E6] Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Randy Presuhn" writes: >As long as the solution is no worse than SNMP, >and gets the work unstuck, >in IETF terms we should consider it progress. That's too close to haiku to leave it alone: No worse than SNMP The IETF Should consider it progress But seriously, is the IESG refusing to host XSD files in the basis that another standards organizations that hosts a file referenced by a zillion web pages gets significant hits from crappy software? If the number of crappy netconf implementations ever reaches a number where it can be called significant, we can declare netconf successful. The problem is that this is a bad precedent, meaning the IETF will likely refuse to host YANG files and other netconf collateral that applications will need access to. Yes, this can be solved by yang-central.org, but it sure seems like putting this material on ietf/iana/iesg/imumble.org would be better. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 12:38:07 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87693A6C24; Mon, 21 Apr 2008 12:38:07 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 587563A6B00 for ; Mon, 21 Apr 2008 12:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTObS4OrfS0Z for ; Mon, 21 Apr 2008 12:38:04 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id D618228C43D for ; Mon, 21 Apr 2008 12:37:33 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Mon, 21 Apr 2008 12:37:24 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Apr 2008 12:34:53 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m3LJYrD17186; Mon, 21 Apr 2008 12:34:53 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m3LJXO39035932; Mon, 21 Apr 2008 19:33:24 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200804211933.m3LJXO39035932@idle.juniper.net> To: "Natale, Bob" In-reply-to: <4915F014FDD99049A9C3A8C1B832004F029E34AA@IMCSRV2.MITRE.ORG> Date: Mon, 21 Apr 2008 15:33:24 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Apr 2008 19:34:53.0685 (UTC) FILETIME=[C5D3B250:01C8A3E6] Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Natale, Bob" writes: >- For IETF *standard* MIBs, I guess, roughly speaking, that the RFC >database was the repository (assuming the necessary extraction >function) and the latest RFC index (RFC n000) was the registry >(assuming inclusion of new RFCs in between indexes n and n+1). RFCs make a fairly horrible source file for mib compilers. I'm hoping we can do something more modern for NETCONF and YANG. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 12:38:07 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87693A6C24; Mon, 21 Apr 2008 12:38:07 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 587563A6B00 for ; Mon, 21 Apr 2008 12:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTObS4OrfS0Z for ; Mon, 21 Apr 2008 12:38:04 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id D618228C43D for ; Mon, 21 Apr 2008 12:37:33 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Mon, 21 Apr 2008 12:37:24 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Apr 2008 12:34:53 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m3LJYrD17186; Mon, 21 Apr 2008 12:34:53 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m3LJXO39035932; Mon, 21 Apr 2008 19:33:24 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200804211933.m3LJXO39035932@idle.juniper.net> To: "Natale, Bob" In-reply-to: <4915F014FDD99049A9C3A8C1B832004F029E34AA@IMCSRV2.MITRE.ORG> Date: Mon, 21 Apr 2008 15:33:24 -0400 From: Phil Shafer X-OriginalArrivalTime: 21 Apr 2008 19:34:53.0685 (UTC) FILETIME=[C5D3B250:01C8A3E6] Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Natale, Bob" writes: >- For IETF *standard* MIBs, I guess, roughly speaking, that the RFC >database was the repository (assuming the necessary extraction >function) and the latest RFC index (RFC n000) was the registry >(assuming inclusion of new RFCs in between indexes n and n+1). RFCs make a fairly horrible source file for mib compilers. I'm hoping we can do something more modern for NETCONF and YANG. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 12:42:58 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A93103A6F29; Mon, 21 Apr 2008 12:42:58 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EE583A6AFD for ; Mon, 21 Apr 2008 12:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnBuT5yUVJCw for ; Mon, 21 Apr 2008 12:42:56 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 9338E3A6F77 for ; Mon, 21 Apr 2008 12:42:56 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m3LJh2F4015818 for ; Mon, 21 Apr 2008 15:43:02 -0400 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m3LJh2TO015807; Mon, 21 Apr 2008 15:43:02 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Apr 2008 15:43:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Apr 2008 15:42:02 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F029E34B5@IMCSRV2.MITRE.ORG> In-Reply-To: <200804211933.m3LJXO39035932@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Netconf Notification: Issues 22: Import Statements Thread-Index: Acij5z85WuJp86aeSPO7hiEC/7q3BAAACXqA References: <4915F014FDD99049A9C3A8C1B832004F029E34AA@IMCSRV2.MITRE.ORG> <200804211933.m3LJXO39035932@idle.juniper.net> From: "Natale, Bob" To: "Phil Shafer" X-OriginalArrivalTime: 21 Apr 2008 19:43:02.0506 (UTC) FILETIME=[E92FDCA0:01C8A3E7] Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Phil, Yes, having written tools to work with MIBs embedded in RFCs, I definitely agree -- we just need to work out explicit repository arrangements for our more modern artifacts. Cheers, BobN -----Original Message----- From: Phil Shafer [mailto:phil@juniper.net] Sent: Monday, April 21, 2008 3:33 PM To: Natale, Bob Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements "Natale, Bob" writes: >- For IETF *standard* MIBs, I guess, roughly speaking, that the RFC >database was the repository (assuming the necessary extraction >function) and the latest RFC index (RFC n000) was the registry >(assuming inclusion of new RFCs in between indexes n and n+1). RFCs make a fairly horrible source file for mib compilers. I'm hoping we can do something more modern for NETCONF and YANG. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 12:42:58 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A93103A6F29; Mon, 21 Apr 2008 12:42:58 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EE583A6AFD for ; Mon, 21 Apr 2008 12:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnBuT5yUVJCw for ; Mon, 21 Apr 2008 12:42:56 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 9338E3A6F77 for ; Mon, 21 Apr 2008 12:42:56 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m3LJh2F4015818 for ; Mon, 21 Apr 2008 15:43:02 -0400 Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m3LJh2TO015807; Mon, 21 Apr 2008 15:43:02 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Apr 2008 15:43:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Apr 2008 15:42:02 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F029E34B5@IMCSRV2.MITRE.ORG> In-Reply-To: <200804211933.m3LJXO39035932@idle.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Netconf Notification: Issues 22: Import Statements Thread-Index: Acij5z85WuJp86aeSPO7hiEC/7q3BAAACXqA References: <4915F014FDD99049A9C3A8C1B832004F029E34AA@IMCSRV2.MITRE.ORG> <200804211933.m3LJXO39035932@idle.juniper.net> From: "Natale, Bob" To: "Phil Shafer" X-OriginalArrivalTime: 21 Apr 2008 19:43:02.0506 (UTC) FILETIME=[E92FDCA0:01C8A3E7] Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Phil, Yes, having written tools to work with MIBs embedded in RFCs, I definitely agree -- we just need to work out explicit repository arrangements for our more modern artifacts. Cheers, BobN -----Original Message----- From: Phil Shafer [mailto:phil@juniper.net] Sent: Monday, April 21, 2008 3:33 PM To: Natale, Bob Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements "Natale, Bob" writes: >- For IETF *standard* MIBs, I guess, roughly speaking, that the RFC >database was the repository (assuming the necessary extraction >function) and the latest RFC index (RFC n000) was the registry >(assuming inclusion of new RFCs in between indexes n and n+1). RFCs make a fairly horrible source file for mib compilers. I'm hoping we can do something more modern for NETCONF and YANG. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 14:07:30 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F170E3A6DB4; Mon, 21 Apr 2008 14:07:29 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B963A67B4 for ; Mon, 21 Apr 2008 14:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T82Z0aJ0gbol for ; Mon, 21 Apr 2008 14:07:25 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 4080528C1B7 for ; Mon, 21 Apr 2008 14:06:38 -0700 (PDT) Received: (qmail 55060 invoked from network); 21 Apr 2008 21:06:44 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.208 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 21 Apr 2008 21:06:43 -0000 X-YMail-OSG: V5z0j1wVM1nvtHk8zCAeMKRlMQVWJh4iSA2UnzWpioix1UxtKWO3P291.LmKxmsSulirisP0efa.GP7ypPZ64ywkOSZX4Gh7zYSe5fj41WEMz3Uz5DLfwGQim3s- X-Yahoo-Newman-Property: ymail-3 Message-ID: <480D01E1.9070208@andybierman.com> Date: Mon, 21 Apr 2008 14:06:41 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Natale, Bob" References: <480CD874.6040802@andybierman.com><713043CE8B8E1348AF3C546DBE02C1B41426EE25@zcarhxm2.corp.nortel.com><480CDE9A.5030304@andybierman.com> <20080421.204041.262826694.mbj@tail-f.com> <4915F014FDD99049A9C3A8C1B832004F029E34AA@IMCSRV2.MITRE.ORG> In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F029E34AA@IMCSRV2.MITRE.ORG> Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Natale, Bob wrote: > I agree also. > > Just two associated points from the broader thread > > - A registry is logically distinct from a repository. The IETF > probably needs IANA to provide a registry for such artifacts > (well-known source for authoritative information about somethings), but > IANA might not want to provide the corresponding (and possibly > distributed) repository service (the location where the somethings can > be gotten). Indeed, as W3C found, no organization should sign-up to > deliver a service (esp. implicitly) w/o considering supply, demand, > administration, cost-recovery, priorities, trade-offs, etc. > > - For IETF *standard* MIBs, I guess, roughly speaking, that the RFC > database was the repository (assuming the necessary extraction > function) and the latest RFC index (RFC n000) was the registry > (assuming inclusion of new RFCs in between indexes n and n+1). > I suppose there is a slippery slope between being a standards archive and becoming part of the application infrastructure. Perhaps a never-ending list of arbitrarily named text files (RFCnnnn) was sufficient in previous decades, but it isn't enough anymore. In order to build a meaningful standards-based CM system, the IETF standards track YANG modules, XSD and DSDL files should be accessible online. If the IETF does not want to take on any more responsibility than a document archive (understandable), then other sites will host the data modules, in an ad-hoc, non-standard manner. Perhaps applications will guess the schemaLocation by trying free databases, ala CDDB. (I bet the extra bandwidth used up by NETCONF/YANG file retrieval is less than the email bandwidth the IETF uses up worrying about NETCONF/YANG file retrieval. ;-) > Cheers, > BobN Andy > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Martin Bjorklund > Sent: Monday, April 21, 2008 2:41 PM > To: ietf@andybierman.com > Cc: netconf@ietf.org > Subject: Re: [Netconf] Netconf Notification: Issues 22: Import > Statements > > Andy Bierman wrote: >> I think Juergen's suggestion of removing the schemaLocation attribute >> is the least worst option. > > I agree. > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 14:07:30 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F170E3A6DB4; Mon, 21 Apr 2008 14:07:29 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B963A67B4 for ; Mon, 21 Apr 2008 14:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T82Z0aJ0gbol for ; Mon, 21 Apr 2008 14:07:25 -0700 (PDT) Received: from smtp121.sbc.mail.sp1.yahoo.com (smtp121.sbc.mail.sp1.yahoo.com [69.147.64.94]) by core3.amsl.com (Postfix) with SMTP id 4080528C1B7 for ; Mon, 21 Apr 2008 14:06:38 -0700 (PDT) Received: (qmail 55060 invoked from network); 21 Apr 2008 21:06:44 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.81.208 with plain) by smtp121.sbc.mail.sp1.yahoo.com with SMTP; 21 Apr 2008 21:06:43 -0000 X-YMail-OSG: V5z0j1wVM1nvtHk8zCAeMKRlMQVWJh4iSA2UnzWpioix1UxtKWO3P291.LmKxmsSulirisP0efa.GP7ypPZ64ywkOSZX4Gh7zYSe5fj41WEMz3Uz5DLfwGQim3s- X-Yahoo-Newman-Property: ymail-3 Message-ID: <480D01E1.9070208@andybierman.com> Date: Mon, 21 Apr 2008 14:06:41 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Natale, Bob" References: <480CD874.6040802@andybierman.com><713043CE8B8E1348AF3C546DBE02C1B41426EE25@zcarhxm2.corp.nortel.com><480CDE9A.5030304@andybierman.com> <20080421.204041.262826694.mbj@tail-f.com> <4915F014FDD99049A9C3A8C1B832004F029E34AA@IMCSRV2.MITRE.ORG> In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F029E34AA@IMCSRV2.MITRE.ORG> Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Natale, Bob wrote: > I agree also. > > Just two associated points from the broader thread > > - A registry is logically distinct from a repository. The IETF > probably needs IANA to provide a registry for such artifacts > (well-known source for authoritative information about somethings), but > IANA might not want to provide the corresponding (and possibly > distributed) repository service (the location where the somethings can > be gotten). Indeed, as W3C found, no organization should sign-up to > deliver a service (esp. implicitly) w/o considering supply, demand, > administration, cost-recovery, priorities, trade-offs, etc. > > - For IETF *standard* MIBs, I guess, roughly speaking, that the RFC > database was the repository (assuming the necessary extraction > function) and the latest RFC index (RFC n000) was the registry > (assuming inclusion of new RFCs in between indexes n and n+1). > I suppose there is a slippery slope between being a standards archive and becoming part of the application infrastructure. Perhaps a never-ending list of arbitrarily named text files (RFCnnnn) was sufficient in previous decades, but it isn't enough anymore. In order to build a meaningful standards-based CM system, the IETF standards track YANG modules, XSD and DSDL files should be accessible online. If the IETF does not want to take on any more responsibility than a document archive (understandable), then other sites will host the data modules, in an ad-hoc, non-standard manner. Perhaps applications will guess the schemaLocation by trying free databases, ala CDDB. (I bet the extra bandwidth used up by NETCONF/YANG file retrieval is less than the email bandwidth the IETF uses up worrying about NETCONF/YANG file retrieval. ;-) > Cheers, > BobN Andy > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Martin Bjorklund > Sent: Monday, April 21, 2008 2:41 PM > To: ietf@andybierman.com > Cc: netconf@ietf.org > Subject: Re: [Netconf] Netconf Notification: Issues 22: Import > Statements > > Andy Bierman wrote: >> I think Juergen's suggestion of removing the schemaLocation attribute >> is the least worst option. > > I agree. > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 15:02:02 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0BD73A6B79; Mon, 21 Apr 2008 15:02:01 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0A393A6DBC for ; Mon, 21 Apr 2008 15:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuxxEqQDenJS for ; Mon, 21 Apr 2008 15:01:59 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 319453A69E5 for ; Mon, 21 Apr 2008 15:01:57 -0700 (PDT) Received: (qmail 48136 invoked from network); 21 Apr 2008 22:02:02 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 21 Apr 2008 22:02:02 -0000 From: "Bert Wijnen - IETF" To: "Sharon Chisholm" , "Andy Bierman" , Date: Tue, 22 Apr 2008 00:02:03 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41426EE25@zcarhxm2.corp.nortel.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I personally would like to keep the URL. But (as document shepherd) I am worried that if we stock to what we currently have in our revision 12 of the document, that we may end up having along fight. As Sharon says, it seems to be a generic issue. I would love it to be solved so that our approach in rev 12 is acceptable. But I dont think we will want to be the guineypig (spelling) on this one and risk a looooong delay in publicationa s RFC. SO I would favor to make the change for now and then continue our fight and if we win, we can do anoteh rev. Bert Wijnen > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > Sharon Chisholm > Verzonden: maandag 21 april 2008 20:17 > Aan: Andy Bierman; netconf@ietf.org > Onderwerp: Re: [Netconf] Netconf Notification: Issues 22: Import > Statements > > > Hi > > To be fair, I should probably provide some more content from > those opposed to URL-based schema locations. Personally, I think > we need them. > > - This is apparently a long standing IETF policy > > - W3C gets a lot of hits > > http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic > > - "At the time of this writing, IANA or IETF does not provide a > registration service for HTTP URLs (something they'd commit to > being stable and pointing to the same file over long term). > > Creating such a service has indeed been proposed -- but do we > want to block this document until that proposal has been accepted?" > > Sharon > > > > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Monday, April 21, 2008 2:10 PM > To: Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org > Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements > > Juergen Schoenwaelder wrote: > > On Mon, Apr 21, 2008 at 12:41:49PM -0400, Sharon Chisholm wrote: > > > >> The proposed resolution would be to continue this discussion for the > >> sake of future specifications, but to make the following > change to this one: > > > > [...] > > > > Does it make sense to store a URN in schemaLocation? Perhaps simply > > dropping the whole attribute is a simpler solution. > > > > I agree that no schemaLocation attribute has as much value as > having one which does not contain a URL. I think automated > retrieval of XSDs via schemaLocation is a feature, not something > that will cause harm to the Internet. > > > From the spec: > http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html #element-import The element information item identifies namespaces used in external references, i.e. those whose =B7QName=B7 identifies them as coming from a different namespace (or none) than the enclosing schema document's targetNamespace. The =B7actual value=B7 of its namespace [attribute] indica= tes that the containing schema document may contain qualified references to schema components in that namespace (via one or more prefixes declared with namespace declarations in the normal way). If that attribute is absent, then the import allows unqualified reference to components with no target namespace. Note that components to be imported need not be in the form of a =B7schema document=B7; the processor is free to access or construct compone= nts using means of its own choosing. The =B7actual value=B7 of the schemaLocation, if present, gives a hint as to where a serialization of a =B7schema document=B7 with declarations and definitions for that namespace (or none) may be found. When no schemaLocation [attribute] is present, the schema author is leaving the identification of that schema to the instance, application or user, via the mechanisms described below in Layer 3: Schema Document Access and Web-interoperability (=A74.3). When a schemaLocation is present, it must contain a single URI reference which the schema author warrants will resolve to a serialization of a =B7schema document=B7 containing the component(s) i= n the ed namespace referred to elsewhere in the containing schema document. > /js > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 15:02:02 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0BD73A6B79; Mon, 21 Apr 2008 15:02:01 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0A393A6DBC for ; Mon, 21 Apr 2008 15:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuxxEqQDenJS for ; Mon, 21 Apr 2008 15:01:59 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 319453A69E5 for ; Mon, 21 Apr 2008 15:01:57 -0700 (PDT) Received: (qmail 48136 invoked from network); 21 Apr 2008 22:02:02 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 21 Apr 2008 22:02:02 -0000 From: "Bert Wijnen - IETF" To: "Sharon Chisholm" , "Andy Bierman" , Date: Tue, 22 Apr 2008 00:02:03 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41426EE25@zcarhxm2.corp.nortel.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I personally would like to keep the URL. But (as document shepherd) I am worried that if we stock to what we currently have in our revision 12 of the document, that we may end up having along fight. As Sharon says, it seems to be a generic issue. I would love it to be solved so that our approach in rev 12 is acceptable. But I dont think we will want to be the guineypig (spelling) on this one and risk a looooong delay in publicationa s RFC. SO I would favor to make the change for now and then continue our fight and if we win, we can do anoteh rev. Bert Wijnen > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > Sharon Chisholm > Verzonden: maandag 21 april 2008 20:17 > Aan: Andy Bierman; netconf@ietf.org > Onderwerp: Re: [Netconf] Netconf Notification: Issues 22: Import > Statements > > > Hi > > To be fair, I should probably provide some more content from > those opposed to URL-based schema locations. Personally, I think > we need them. > > - This is apparently a long standing IETF policy > > - W3C gets a lot of hits > > http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic > > - "At the time of this writing, IANA or IETF does not provide a > registration service for HTTP URLs (something they'd commit to > being stable and pointing to the same file over long term). > > Creating such a service has indeed been proposed -- but do we > want to block this document until that proposal has been accepted?" > > Sharon > > > > -----Original Message----- > From: Andy Bierman [mailto:ietf@andybierman.com] > Sent: Monday, April 21, 2008 2:10 PM > To: Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org > Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements > > Juergen Schoenwaelder wrote: > > On Mon, Apr 21, 2008 at 12:41:49PM -0400, Sharon Chisholm wrote: > > > >> The proposed resolution would be to continue this discussion for the > >> sake of future specifications, but to make the following > change to this one: > > > > [...] > > > > Does it make sense to store a URN in schemaLocation? Perhaps simply > > dropping the whole attribute is a simpler solution. > > > > I agree that no schemaLocation attribute has as much value as > having one which does not contain a URL. I think automated > retrieval of XSDs via schemaLocation is a feature, not something > that will cause harm to the Internet. > > > From the spec: > http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html #element-import The element information item identifies namespaces used in external references, i.e. those whose =B7QName=B7 identifies them as coming from a different namespace (or none) than the enclosing schema document's targetNamespace. The =B7actual value=B7 of its namespace [attribute] indica= tes that the containing schema document may contain qualified references to schema components in that namespace (via one or more prefixes declared with namespace declarations in the normal way). If that attribute is absent, then the import allows unqualified reference to components with no target namespace. Note that components to be imported need not be in the form of a =B7schema document=B7; the processor is free to access or construct compone= nts using means of its own choosing. The =B7actual value=B7 of the schemaLocation, if present, gives a hint as to where a serialization of a =B7schema document=B7 with declarations and definitions for that namespace (or none) may be found. When no schemaLocation [attribute] is present, the schema author is leaving the identification of that schema to the instance, application or user, via the mechanisms described below in Layer 3: Schema Document Access and Web-interoperability (=A74.3). When a schemaLocation is present, it must contain a single URI reference which the schema author warrants will resolve to a serialization of a =B7schema document=B7 containing the component(s) i= n the ed namespace referred to elsewhere in the containing schema document. > /js > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 15:06:34 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A8AA3A6F72; Mon, 21 Apr 2008 15:06:34 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F315F3A686E for ; Mon, 21 Apr 2008 15:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiMRA01-5ZTS for ; Mon, 21 Apr 2008 15:06:28 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 204953A6F74 for ; Mon, 21 Apr 2008 15:06:16 -0700 (PDT) Received: (qmail 50120 invoked from network); 21 Apr 2008 22:06:22 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 21 Apr 2008 22:06:22 -0000 From: "Bert Wijnen - IETF" To: "Phil Shafer" , "Randy Presuhn" Date: Tue, 22 Apr 2008 00:06:24 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200804211931.m3LJVwLZ035874@idle.juniper.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org As I said in my other message, We can keep (and should) fighting... but we should accept (for now) what they (IESG) want and get our document published. If we (hell knows wehn) winn our fight; we can do a quick update to the RFC and include the URLs. Bert Wijnen (speaking as document shepherd) > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > Phil Shafer > Verzonden: maandag 21 april 2008 21:32 > Aan: Randy Presuhn > CC: netconf@ietf.org > Onderwerp: Re: [Netconf] Netconf Notification: Issues 22: Import > Statements > > > "Randy Presuhn" writes: > >As long as the solution is no worse than SNMP, > >and gets the work unstuck, > >in IETF terms we should consider it progress. > > That's too close to haiku to leave it alone: > > No worse than SNMP > The IETF > Should consider it progress > > But seriously, is the IESG refusing to host XSD files in the basis > that another standards organizations that hosts a file referenced > by a zillion web pages gets significant hits from crappy software? > If the number of crappy netconf implementations ever reaches a > number where it can be called significant, we can declare netconf > successful. > > The problem is that this is a bad precedent, meaning the IETF > will likely refuse to host YANG files and other netconf collateral > that applications will need access to. Yes, this can be solved > by yang-central.org, but it sure seems like putting this material > on ietf/iana/ieFrom netconf-bounces@ietf.org Mon Apr 21 15:06:34 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A8AA3A6F72; Mon, 21 Apr 2008 15:06:34 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F315F3A686E for ; Mon, 21 Apr 2008 15:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiMRA01-5ZTS for ; Mon, 21 Apr 2008 15:06:28 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 204953A6F74 for ; Mon, 21 Apr 2008 15:06:16 -0700 (PDT) Received: (qmail 50120 invoked from network); 21 Apr 2008 22:06:22 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 21 Apr 2008 22:06:22 -0000 From: "Bert Wijnen - IETF" To: "Phil Shafer" , "Randy Presuhn" Date: Tue, 22 Apr 2008 00:06:24 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200804211931.m3LJVwLZ035874@idle.juniper.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org As I said in my other message, We can keep (and should) fighting... but we should accept (for now) what they (IESG) want and get our document published. If we (hell knows wehn) winn our fight; we can do a quick update to the RFC and include the URLs. Bert Wijnen (speaking as document shepherd) > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > Phil Shafer > Verzonden: maandag 21 april 2008 21:32 > Aan: Randy Presuhn > CC: netconf@ietf.org > Onderwerp: Re: [Netconf] Netconf Notification: Issues 22: Import > Statements > > > "Randy Presuhn" writes: > >As long as the solution is no worse than SNMP, > >and gets the work unstuck, > >in IETF terms we should consider it progress. > > That's too close to haiku to leave it alone: > > No worse than SNMP > The IETF > Should consider it progress > > But seriously, is the IESG refusing to host XSD files in the basis > that another standards organizations that hosts a file referenced > by a zillion web pages gets significant hits from crappy software? > If the number of crappy netconf implementations ever reaches a > number where it can be called significant, we can declare netconf > successful. > > The problem is that this is a bad precedent, meaning the IETF > will likely refuse to host YANG files and other netconf collateral > that applications will need access to. Yes, this can be solved > by yang-central.org, but it sure seems like putting this material > on ietf/iana/iesg/imumble.org would be better. > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf sg/imumble.org would be better. > > Thanks, > Phil > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 15:31:38 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8EF63A6A39; Mon, 21 Apr 2008 15:31:38 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7EEA3A6A39 for ; Mon, 21 Apr 2008 15:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQPzp9fPzrK1 for ; Mon, 21 Apr 2008 15:31:35 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B61673A69F2 for ; Mon, 21 Apr 2008 15:31:34 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 57770C001E; Tue, 22 Apr 2008 00:31:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id b7OulUN3we6s; Tue, 22 Apr 2008 00:31:30 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC2B5C0015; Tue, 22 Apr 2008 00:31:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 49C7D542C25; Tue, 22 Apr 2008 00:31:29 +0200 (CEST) Date: Tue, 22 Apr 2008 00:31:29 +0200 From: Juergen Schoenwaelder To: "Natale, Bob" Message-ID: <20080421223129.GA9933@elstar.local> Mail-Followup-To: "Natale, Bob" , Phil Shafer , netconf@ietf.org References: <4915F014FDD99049A9C3A8C1B832004F029E34AA@IMCSRV2.MITRE.ORG> <200804211933.m3LJXO39035932@idle.juniper.net> <4915F014FDD99049A9C3A8C1B832004F029E34B5@IMCSRV2.MITRE.ORG> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F029E34B5@IMCSRV2.MITRE.ORG> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Mon, Apr 21, 2008 at 03:42:02PM -0400, Natale, Bob wrote: > Yes, having written tools to work with MIBs embedded in RFCs, I > definitely agree -- we just need to work out explicit repository > arrangements for our more modern artifacts. I fail to see why people like to make a distinction between traditional artifacts (MIB modules) or more modern artifacts such as YANG or XSD modules; the language does not matter. All these artifacts would benefit from a repository. In the past, attempts to create such a repository for "traditional artifacts" never went anywhere. If you go down the official IETF path, you will find yourself quickly confronted with questions such as this one: Will someone (who?, how is she selected) be allowed to fix bugs (what is the definition of a bug?) in an online repository (is it limited to IETF modules or may it contain IANA modules or even vendor modules?) or does the repository keep the version excatly as extracted from an RFC (will a new RFC revision automatically replace things in the repository?) without changes (is white space removal a change?), even if serious bugs (what is the procedure to decide what a serious bug is?) have been detected after publication? The best bet is probably to talk to the tools people; they might be able to create something inofficial that does the job somehow. ;-) To get the document published, drop the schemaLocation attribute and declare success. Bert knows what he is talking about. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 15:31:38 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8EF63A6A39; Mon, 21 Apr 2008 15:31:38 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7EEA3A6A39 for ; Mon, 21 Apr 2008 15:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQPzp9fPzrK1 for ; Mon, 21 Apr 2008 15:31:35 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B61673A69F2 for ; Mon, 21 Apr 2008 15:31:34 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 57770C001E; Tue, 22 Apr 2008 00:31:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id b7OulUN3we6s; Tue, 22 Apr 2008 00:31:30 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC2B5C0015; Tue, 22 Apr 2008 00:31:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 49C7D542C25; Tue, 22 Apr 2008 00:31:29 +0200 (CEST) Date: Tue, 22 Apr 2008 00:31:29 +0200 From: Juergen Schoenwaelder To: "Natale, Bob" Message-ID: <20080421223129.GA9933@elstar.local> Mail-Followup-To: "Natale, Bob" , Phil Shafer , netconf@ietf.org References: <4915F014FDD99049A9C3A8C1B832004F029E34AA@IMCSRV2.MITRE.ORG> <200804211933.m3LJXO39035932@idle.juniper.net> <4915F014FDD99049A9C3A8C1B832004F029E34B5@IMCSRV2.MITRE.ORG> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F029E34B5@IMCSRV2.MITRE.ORG> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Mon, Apr 21, 2008 at 03:42:02PM -0400, Natale, Bob wrote: > Yes, having written tools to work with MIBs embedded in RFCs, I > definitely agree -- we just need to work out explicit repository > arrangements for our more modern artifacts. I fail to see why people like to make a distinction between traditional artifacts (MIB modules) or more modern artifacts such as YANG or XSD modules; the language does not matter. All these artifacts would benefit from a repository. In the past, attempts to create such a repository for "traditional artifacts" never went anywhere. If you go down the official IETF path, you will find yourself quickly confronted with questions such as this one: Will someone (who?, how is she selected) be allowed to fix bugs (what is the definition of a bug?) in an online repository (is it limited to IETF modules or may it contain IANA modules or even vendor modules?) or does the repository keep the version excatly as extracted from an RFC (will a new RFC revision automatically replace things in the repository?) without changes (is white space removal a change?), even if serious bugs (what is the procedure to decide what a serious bug is?) have been detected after publication? The best bet is probably to talk to the tools people; they might be able to create something inofficial that does the job somehow. ;-) To get the document published, drop the schemaLocation attribute and declare success. Bert knows what he is talking about. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 15:58:27 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AEF83A6F8A; Mon, 21 Apr 2008 15:58:27 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B37F33A6CBE for ; Mon, 21 Apr 2008 15:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPyqYeG7xKPG for ; Mon, 21 Apr 2008 15:58:24 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 3350B3A6AB3 for ; Mon, 21 Apr 2008 15:57:10 -0700 (PDT) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id GNt41Z0351HpZEsA700500; Mon, 21 Apr 2008 22:55:39 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id GNxA1Z00F4HwxpC8a00000; Mon, 21 Apr 2008 22:57:16 +0000 X-Authority-Analysis: v=1.0 c=1 a=8nH5FJs8o1cA:10 a=DOMOX0ymGwQA:10 a=I0CVDw5ZAAAA:8 a=48vgC7mUAAAA:8 a=Kx1Q39LoogmOsQ_MjaEA:9 a=dWxWLaGwSv1Ra5pqkAQA:7 a=6jPGW-a6V3rhjfoYGNAbmFz4o_IA:4 a=kkUMZHjH4KkA:10 a=huntNF1cNFcA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Andy Bierman'" , "'Sharon Chisholm'" References: <713043CE8B8E1348AF3C546DBE02C1B41426EB6B@zcarhxm2.corp.nortel.com> <480CCF26.4020607@andybierman.com> Date: Mon, 21 Apr 2008 18:57:10 -0400 Message-ID: <003001c8a403$0914e2c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <480CCF26.4020607@andybierman.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: Acij1bWX7FkNr+VJRhmsCG3c2vD0zgAK7X2A Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > I do not agree with the problem statement. > Is there a demonstrated impact on the ietf.org WEB site > due to 'over-use' of the IANA registries? When the IETF > posts files in the xml-registry/schema directory, > is the expectation that only humans will retrieve > the files, and HTML caches will not be used, causing > repeated retrievals? I do not understand this objection. > > Isn't the point of the IANA registries to have a stable home > for standard-related data which may need to be retrieved > by applications or humans? IANA is responsible for providing standardized numbers fo the Internet. The RFC series is responsible for providing retrievable documents containing IETF-standardized specifications (and other things). I think having IANA provide a registry for schemas, just like it provides a registry for MIB modules makes sense. I don't know that having IANA.org provide storage for the schema themselves is the right answer > > Applications which utilize the schemaLocation attribute for > finding XSDs they do not know about are not dumb. The purpose > of the schemaLocation attribute is to provide a URL associated > with a schema that defines the namespace contents. This field > is not supposed to contain a generic URN. > > > Andy > > > > The proposed resolution would be to continue this discussion for the > > sake of future specifications, but to make the following > change to this > > one: > > > > Replace > > > > > schemaLocation= > > > "http://www.iana.org/assignments/xml-registry/schema/netconf.xsd"/> > > > "urn:ietf:params:xml:ns:netconf:notification:1.0" > > schemaLocation= > > > "http://www.iana.org/assignments/xml-registry/schema/notificat ion.xsd"/> > > > > With (I think) > > > > > schemaLocation= > > "urn:ietf:params:xml:ns:netconf:base:1.0"/> > > > "urn:ietf:params:xml:ns:netconf:notification:1.0" > > schemaLocation= > > "urn:ietf:params:xml:ns:netconf:notification:1.0"/> > > > > Sharon Chisholm > > Nortel > > Ottawa, Ontario > > Canada > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 15:58:27 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AEF83A6F8A; Mon, 21 Apr 2008 15:58:27 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B37F33A6CBE for ; Mon, 21 Apr 2008 15:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPyqYeG7xKPG for ; Mon, 21 Apr 2008 15:58:24 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 3350B3A6AB3 for ; Mon, 21 Apr 2008 15:57:10 -0700 (PDT) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id GNt41Z0351HpZEsA700500; Mon, 21 Apr 2008 22:55:39 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id GNxA1Z00F4HwxpC8a00000; Mon, 21 Apr 2008 22:57:16 +0000 X-Authority-Analysis: v=1.0 c=1 a=8nH5FJs8o1cA:10 a=DOMOX0ymGwQA:10 a=I0CVDw5ZAAAA:8 a=48vgC7mUAAAA:8 a=Kx1Q39LoogmOsQ_MjaEA:9 a=dWxWLaGwSv1Ra5pqkAQA:7 a=6jPGW-a6V3rhjfoYGNAbmFz4o_IA:4 a=kkUMZHjH4KkA:10 a=huntNF1cNFcA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Andy Bierman'" , "'Sharon Chisholm'" References: <713043CE8B8E1348AF3C546DBE02C1B41426EB6B@zcarhxm2.corp.nortel.com> <480CCF26.4020607@andybierman.com> Date: Mon, 21 Apr 2008 18:57:10 -0400 Message-ID: <003001c8a403$0914e2c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <480CCF26.4020607@andybierman.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: Acij1bWX7FkNr+VJRhmsCG3c2vD0zgAK7X2A Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > I do not agree with the problem statement. > Is there a demonstrated impact on the ietf.org WEB site > due to 'over-use' of the IANA registries? When the IETF > posts files in the xml-registry/schema directory, > is the expectation that only humans will retrieve > the files, and HTML caches will not be used, causing > repeated retrievals? I do not understand this objection. > > Isn't the point of the IANA registries to have a stable home > for standard-related data which may need to be retrieved > by applications or humans? IANA is responsible for providing standardized numbers fo the Internet. The RFC series is responsible for providing retrievable documents containing IETF-standardized specifications (and other things). I think having IANA provide a registry for schemas, just like it provides a registry for MIB modules makes sense. I don't know that having IANA.org provide storage for the schema themselves is the right answer > > Applications which utilize the schemaLocation attribute for > finding XSDs they do not know about are not dumb. The purpose > of the schemaLocation attribute is to provide a URL associated > with a schema that defines the namespace contents. This field > is not supposed to contain a generic URN. > > > Andy > > > > The proposed resolution would be to continue this discussion for the > > sake of future specifications, but to make the following > change to this > > one: > > > > Replace > > > > > schemaLocation= > > > "http://www.iana.org/assignments/xml-registry/schema/netconf.xsd"/> > > > "urn:ietf:params:xml:ns:netconf:notification:1.0" > > schemaLocation= > > > "http://www.iana.org/assignments/xml-registry/schema/notificat ion.xsd"/> > > > > With (I think) > > > > > schemaLocation= > > "urn:ietf:params:xml:ns:netconf:base:1.0"/> > > > "urn:ietf:params:xml:ns:netconf:notification:1.0" > > schemaLocation= > > "urn:ietf:params:xml:ns:netconf:notification:1.0"/> > > > > Sharon Chisholm > > Nortel > > Ottawa, Ontario > > Canada > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 16:34:57 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96EE83A6B20; Mon, 21 Apr 2008 16:34:57 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EE493A6B00 for ; Mon, 21 Apr 2008 16:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaH2eDEyaABA for ; Mon, 21 Apr 2008 16:34:55 -0700 (PDT) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id 5D6773A6889 for ; Mon, 21 Apr 2008 16:34:55 -0700 (PDT) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id GMND1Z00J1HpZEsA30D000; Mon, 21 Apr 2008 23:32:11 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id GPap1Z0084HwxpC8a00000; Mon, 21 Apr 2008 23:34:55 +0000 X-Authority-Analysis: v=1.0 c=1 a=8nH5FJs8o1cA:10 a=DOMOX0ymGwQA:10 a=aTP7Mu-gvaPbVAZm2RYA:9 a=numCwc6cSSFAINGXuLEA:7 a=OdLqc1m7AmYogmT3EJ4Qhskq1ukA:4 a=P2TwHfrFO3IA:10 a=kkUMZHjH4KkA:10 a=huntNF1cNFcA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=gJcimI5xSWUA:10 From: "David B Harrington" To: "'Andy Bierman'" , "'Natale, Bob'" References: <480CD874.6040802@andybierman.com><713043CE8B8E1348AF3C546DBE02C1B41426EE25@zcarhxm2.corp.nortel.com><480CDE9A.5030304@andybierman.com> <20080421.204041.262826694.mbj@tail-f.com><4915F014FDD99049A9C3A8C1B832004F029E34AA@IMCSRV2.MITRE.ORG> <480D01E1.9070208@andybierman.com> Date: Mon, 21 Apr 2008 19:34:49 -0400 Message-ID: <003a01c8a408$4b5822a0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <480D01E1.9070208@andybierman.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: Acij87ubg4jZLDhrQ2ahZ8FH2QfeJQAD+wfg Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > I suppose there is a slippery slope between being a standards > archive and > becoming part of the application infrastructure. There is a slippery slope between being a numnbering authority (IANA) and being a standards archive (ala the RFC series) that becomes part of the application infrastructure. > > Perhaps a never-ending list of arbitrarily named text files (RFCnnnn) > was sufficient in previous decades, but it isn't enough anymore. > In order to build a meaningful standards-based CM system, the > IETF standards track YANG modules, XSD and DSDL files should be > accessible online. If the IETF does not want to take on any > more responsibility than a document archive (understandable), > then other sites will host the data modules, in an ad-hoc, > non-standard manner. Perhaps applications will guess the > schemaLocation by trying free databases, ala CDDB. I think it would benefit the IETF community to have rfc-editor.org or ietf.org (not iana.org) host an archive for standard data models, including MIB modules. But there has to be a concern that the normative document (the RFC) and the extracted schema could differ. There are a number of issues that would need to be addressed, as Juergen points out. I suggest this be raised to the IAB, who, if I understand correctly, have the job over overseeing the contracts with the RFC Editor function to meet IETF needs (and I think might also control contracts with the provider of ietf.org servers). > > (I bet the extra bandwidth used up by NETCONF/YANG file retrieval > is less than the email bandwidth the IETF uses up worrying about > NETCONF/YANG file retrieval. ;-) I am pretty sure the bandwidth and storage requirements for IETF-standard netconf schema would be dwarfed by the requirements for bandwidth and storage of emails discussing the size of cookies provided during IETF meetings. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 16:34:57 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96EE83A6B20; Mon, 21 Apr 2008 16:34:57 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EE493A6B00 for ; Mon, 21 Apr 2008 16:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaH2eDEyaABA for ; Mon, 21 Apr 2008 16:34:55 -0700 (PDT) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id 5D6773A6889 for ; Mon, 21 Apr 2008 16:34:55 -0700 (PDT) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id GMND1Z00J1HpZEsA30D000; Mon, 21 Apr 2008 23:32:11 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id GPap1Z0084HwxpC8a00000; Mon, 21 Apr 2008 23:34:55 +0000 X-Authority-Analysis: v=1.0 c=1 a=8nH5FJs8o1cA:10 a=DOMOX0ymGwQA:10 a=aTP7Mu-gvaPbVAZm2RYA:9 a=numCwc6cSSFAINGXuLEA:7 a=OdLqc1m7AmYogmT3EJ4Qhskq1ukA:4 a=P2TwHfrFO3IA:10 a=kkUMZHjH4KkA:10 a=huntNF1cNFcA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=gJcimI5xSWUA:10 From: "David B Harrington" To: "'Andy Bierman'" , "'Natale, Bob'" References: <480CD874.6040802@andybierman.com><713043CE8B8E1348AF3C546DBE02C1B41426EE25@zcarhxm2.corp.nortel.com><480CDE9A.5030304@andybierman.com> <20080421.204041.262826694.mbj@tail-f.com><4915F014FDD99049A9C3A8C1B832004F029E34AA@IMCSRV2.MITRE.ORG> <480D01E1.9070208@andybierman.com> Date: Mon, 21 Apr 2008 19:34:49 -0400 Message-ID: <003a01c8a408$4b5822a0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <480D01E1.9070208@andybierman.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: Acij87ubg4jZLDhrQ2ahZ8FH2QfeJQAD+wfg Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > I suppose there is a slippery slope between being a standards > archive and > becoming part of the application infrastructure. There is a slippery slope between being a numnbering authority (IANA) and being a standards archive (ala the RFC series) that becomes part of the application infrastructure. > > Perhaps a never-ending list of arbitrarily named text files (RFCnnnn) > was sufficient in previous decades, but it isn't enough anymore. > In order to build a meaningful standards-based CM system, the > IETF standards track YANG modules, XSD and DSDL files should be > accessible online. If the IETF does not want to take on any > more responsibility than a document archive (understandable), > then other sites will host the data modules, in an ad-hoc, > non-standard manner. Perhaps applications will guess the > schemaLocation by trying free databases, ala CDDB. I think it would benefit the IETF community to have rfc-editor.org or ietf.org (not iana.org) host an archive for standard data models, including MIB modules. But there has to be a concern that the normative document (the RFC) and the extracted schema could differ. There are a number of issues that would need to be addressed, as Juergen points out. I suggest this be raised to the IAB, who, if I understand correctly, have the job over overseeing the contracts with the RFC Editor function to meet IETF needs (and I think might also control contracts with the provider of ietf.org servers). > > (I bet the extra bandwidth used up by NETCONF/YANG file retrieval > is less than the email bandwidth the IETF uses up worrying about > NETCONF/YANG file retrieval. ;-) I am pretty sure the bandwidth and storage requirements for IETF-standard netconf schema would be dwarfed by the requirements for bandwidth and storage of emails discussing the size of cookies provided during IETF meetings. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 21 20:54:49 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7682B28C36F; Mon, 21 Apr 2008 20:54:49 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F70F28C3F8 for ; Mon, 21 Apr 2008 20:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAGUJy1ga3se for ; Mon, 21 Apr 2008 20:54:45 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 2202328C236 for ; Mon, 21 Apr 2008 20:54:44 -0700 (PDT) Received: (qmail 27304 invoked from network); 22 Apr 2008 03:54:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@207.215.245.10 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 22 Apr 2008 03:54:49 -0000 X-YMail-OSG: A4ktaz4VM1lNaJHRbDqvzAaJXKxLyniF.hyLsRZVzt.abjFhFZDsxeuzNDl73ZYKTMDgylFlOZjUbydODJaeG3nYRbNtjld9uCdD1I1..Zd0_mDb13KlP_qI1ko- X-Yahoo-Newman-Property: ymail-3 Message-ID: <480D6187.7070406@andybierman.com> Date: Mon, 21 Apr 2008 20:54:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: David B Harrington References: <480CD874.6040802@andybierman.com><713043CE8B8E1348AF3C546DBE02C1B41426EE25@zcarhxm2.corp.nortel.com><480CDE9A.5030304@andybierman.com> <20080421.204041.262826694.mbj@tail-f.com><4915F014FDD99049A9C3A8C1B832004F029E34AA@IMCSRV2.MITRE.ORG> <480D01E1.9070208@andybierman.com> <003a01c8a408$4b5822a0$0600a8c0@china.huawei.com> In-Reply-To: <003a01c8a408$4b5822a0$0600a8c0@china.huawei.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org David B Harrington wrote: > > >> I suppose there is a slippery slope between being a standards >> archive and >> becoming part of the application infrastructure. > > There is a slippery slope between being a numnbering authority (IANA) > and being a standards archive (ala the RFC series) that becomes part > of the application infrastructure. > >> Perhaps a never-ending list of arbitrarily named text files > (RFCnnnn) >> was sufficient in previous decades, but it isn't enough anymore. >> In order to build a meaningful standards-based CM system, the >> IETF standards track YANG modules, XSD and DSDL files should be >> accessible online. If the IETF does not want to take on any >> more responsibility than a document archive (understandable), >> then other sites will host the data modules, in an ad-hoc, >> non-standard manner. Perhaps applications will guess the >> schemaLocation by trying free databases, ala CDDB. > > I think it would benefit the IETF community to have rfc-editor.org or > ietf.org (not iana.org) host an archive for standard data models, > including MIB modules. But there haFrom netconf-bounces@ietf.org Mon Apr 21 20:54:49 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7682B28C36F; Mon, 21 Apr 2008 20:54:49 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F70F28C3F8 for ; Mon, 21 Apr 2008 20:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAGUJy1ga3se for ; Mon, 21 Apr 2008 20:54:45 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 2202328C236 for ; Mon, 21 Apr 2008 20:54:44 -0700 (PDT) Received: (qmail 27304 invoked from network); 22 Apr 2008 03:54:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@207.215.245.10 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 22 Apr 2008 03:54:49 -0000 X-YMail-OSG: A4ktaz4VM1lNaJHRbDqvzAaJXKxLyniF.hyLsRZVzt.abjFhFZDsxeuzNDl73ZYKTMDgylFlOZjUbydODJaeG3nYRbNtjld9uCdD1I1..Zd0_mDb13KlP_qI1ko- X-Yahoo-Newman-Property: ymail-3 Message-ID: <480D6187.7070406@andybierman.com> Date: Mon, 21 Apr 2008 20:54:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: David B Harrington References: <480CD874.6040802@andybierman.com><713043CE8B8E1348AF3C546DBE02C1B41426EE25@zcarhxm2.corp.nortel.com><480CDE9A.5030304@andybierman.com> <20080421.204041.262826694.mbj@tail-f.com><4915F014FDD99049A9C3A8C1B832004F029E34AA@IMCSRV2.MITRE.ORG> <480D01E1.9070208@andybierman.com> <003a01c8a408$4b5822a0$0600a8c0@china.huawei.com> In-Reply-To: <003a01c8a408$4b5822a0$0600a8c0@china.huawei.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Notification: Issues 22: Import Statements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org David B Harrington wrote: > > >> I suppose there is a slippery slope between being a standards >> archive and >> becoming part of the application infrastructure. > > There is a slippery slope between being a numnbering authority (IANA) > and being a standards archive (ala the RFC series) that becomes part > of the application infrastructure. > >> Perhaps a never-ending list of arbitrarily named text files > (RFCnnnn) >> was sufficient in previous decades, but it isn't enough anymore. >> In order to build a meaningful standards-based CM system, the >> IETF standards track YANG modules, XSD and DSDL files should be >> accessible online. If the IETF does not want to take on any >> more responsibility than a document archive (understandable), >> then other sites will host the data modules, in an ad-hoc, >> non-standard manner. Perhaps applications will guess the >> schemaLocation by trying free databases, ala CDDB. > > I think it would benefit the IETF community to have rfc-editor.org or > ietf.org (not iana.org) host an archive for standard data models, > including MIB modules. But ths to be a concern that the > normative document (the RFC) and the extracted schema could differ. > There are a number of issues that would need to be addressed, as > Juergen points out. Well, IANA extracts XSDs from RFCs are stores them in the http://www.iana.org/assignments/xml-registry/schema/ directory. I suppose there is some valid reason why IANA needs to maintain these online files, yet not want them to be found via an clause. Whether they differ from the RFC or not, these XSDs are being extracted and stored. Perhaps IANA should stop this practice. You can carry this logic right on through -- it seems pointless for IANA to extract and store any information at all -- people should just hunt through RFCs if they want to find any Internet 'data'. Maybe IANA should never extract any data from any published document, since this is redundant and wastes precious iana.org bandwidth. Andy > > I suggest this be raised to the IAB, who, if I understand correctly, > have the job over overseeing the contracts with the RFC Editor > function to meet IETF needs (and I think might also control contracts > with the provider of ietf.org servers). > >> (I bet the extra bandwidth used up by NETCONF/YANG file retrieval >> is less than the email bandwidth the IETF uses up worrying about >> NETCONF/YANG file retrieval. ;-) > > I am pretty sure the bandwidth and storage requirements for > IETF-standard netconf schema would be dwarfed by the requirements for > bandwidth and storage of emails discussing the size of cookies > provided during IETF meetings. > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ere has to be a concern that the > normative document (the RFC) and the extracted schema could differ. > There are a number of issues that would need to be addressed, as > Juergen points out. Well, IANA extracts XSDs from RFCs are stores them in the http://www.iana.org/assignments/xml-registry/schema/ directory. I suppose there is some valid reason why IANA needs to maintain these online files, yet not want them to be found via an clause. Whether they differ from the RFC or not, these XSDs are being extracted and stored. Perhaps IANA should stop this practice. You can carry this logic right on through -- it seems pointless for IANA to extract and store any information at all -- people should just hunt through RFCs if they want to find any Internet 'data'. Maybe IANA should never extract any data from any published document, since this is redundant and wastes precious iana.org bandwidth. Andy > > I suggest this be raised to the IAB, who, if I understand correctly, > have the job over overseeing the contracts with the RFC Editor > function to meet IETF needs (and I think might also control contracts > with the provider of ietf.org servers). > >> (I bet the extra bandwidth used up by NETCONF/YANG file retrieval >> is less than the email bandwidth the IETF uses up worrying about >> NETCONF/YANG file retrieval. ;-) > > I am pretty sure the bandwidth and storage requirements for > IETF-standard netconf schema would be dwarfed by the requirements for > bandwidth and storage of emails discussing the size of cookies > provided during IETF meetings. > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 22 02:29:51 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D706F28C465; Tue, 22 Apr 2008 02:29:51 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79DD28C45B for ; Tue, 22 Apr 2008 02:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBXgYrTRStYN for ; Tue, 22 Apr 2008 02:29:40 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 74F393A6C36 for ; Tue, 22 Apr 2008 02:28:00 -0700 (PDT) Received: (qmail 63576 invoked from network); 22 Apr 2008 09:28:06 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 22 Apr 2008 09:28:06 -0000 From: "Bert Wijnen - IETF" To: "Andy Bierman" , "David B Harrington" Date: Tue, 22 Apr 2008 11:28:07 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <480D6187.7070406@andybierman.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Cc: netconf@ietf.org Subject: [Netconf] Holding Notifications Document (was: RE: Netconf Notification: Issues 22: Import Statements) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org See... this seems to be the first step in a path of loooooong delay. We have (in about 1 day) shifted our dicussion about our own WG document into a discussion about the generic issue of storing (and giving access) to extracted data from RFCs. PLEASE... if you want to have this generic discussion, then relabel the subject line (so I can ignore it). As document shepherd, I am NOT interested in that type of discussion. If you want the document to be hold up for this, then PLEASE do not discuss this in detail, but just post one short message to the WG list with subject "Holding Notifications Document". If I see consensus forming to do that, then I can hand back my task as "document shepherd" and give the document back to the WG for further year-long discussions about this topic. Bert Wijnen Speaking as document shepherd > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > Andy Bierman > Verzonden: dinsdag 22 april 2008 5:55 > Aan: David B Harrington > CC: netconf@ietf.org > Onderwerp: Re: [Netconf] Netconf Notification: Issues 22: Import > Statements > > > David B Harrington wrote: > > > > > >> I suppose there is a slippery slope between being a standards > >> archive and > >> becoming part of the application infrastructure. > > > > There is a slippery slope between being a numnbering authority (IANA) > > and being a standards archive (ala the RFC series) that becomes part > > of the application infrastruFrom netconf-bounces@ietf.org Tue Apr 22 02:29:51 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D706F28C465; Tue, 22 Apr 2008 02:29:51 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79DD28C45B for ; Tue, 22 Apr 2008 02:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBXgYrTRStYN for ; Tue, 22 Apr 2008 02:29:40 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 74F393A6C36 for ; Tue, 22 Apr 2008 02:28:00 -0700 (PDT) Received: (qmail 63576 invoked from network); 22 Apr 2008 09:28:06 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 22 Apr 2008 09:28:06 -0000 From: "Bert Wijnen - IETF" To: "Andy Bierman" , "David B Harrington" Date: Tue, 22 Apr 2008 11:28:07 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <480D6187.7070406@andybierman.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Cc: netconf@ietf.org Subject: [Netconf] Holding Notifications Document (was: RE: Netconf Notification: Issues 22: Import Statements) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org See... this seems to be the first step in a path of loooooong delay. We have (in about 1 day) shifted our dicussion about our own WG document into a discussion about the generic issue of storing (and giving access) to extracted data from RFCs. PLEASE... if you want to have this generic discussion, then relabel the subject line (so I can ignore it). As document shepherd, I am NOT interested in that type of discussion. If you want the document to be hold up for this, then PLEASE do not discuss this in detail, but just post one short message to the WG list with subject "Holding Notifications Document". If I see consensus forming to do that, then I can hand back my task as "document shepherd" and give the document back to the WG for further year-long discussions about this topic. Bert Wijnen Speaking as document shepherd > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > Andy Bierman > Verzonden: dinsdag 22 april 2008 5:55 > Aan: David B Harrington > CC: netconf@ietf.org > Onderwerp: Re: [Netconf] Netconf Notification: Issues 22: Import > Statements > > > David B Harrington wrote: > > > > > >> I suppose there is a slippery slope between being a standards > >> archive and > >> becoming part of the application infrastructure. > > > > There is a slippery slope between being a numnbering authority (IANA) > > and being a standards archive (ala the RFC series) that becomes part > > of the application infrastructure. > > > >> Perhaps a never-ending list of arbitrarily named text files > > (RFCnnnn) > >> was sufficient in previous decades, but it isn't enough anymore. > >> In order to build a meaningful standards-based CM system, the > >> IETF standards track YANG modules, XSD and DSDL files should be > >> accessible online. If the IETF does not want to take on any > >> more responsibility than a document archive (understandable), > >> then other sites will host the data modules, in an ad-hoc, > >> non-standard manner. Perhaps applications will guess the > >> schemaLocation by trying free databases, ala CDDB. > > > > I think it would benefit the IETF community to have rfc-editor.org or > > ietf.org (not iana.org) host an archive for standard data models, > > including MIB modules. But there has to be a concern that the > > normative document (the RFC) and the extracted schema could differ. > > There are a number of issues that would need to be addressed, as > > Juergen points out. > > > Well, IANA extracts XSDs from RFCs are stores them in the > http://www.iana.org/assignments/xml-registry/schema/ directory. > > I suppose there is some valid reason why IANA needs to maintain > these online files, yet not want them to be found via an > clause. > > Whether they differ from the RFC or not, these XSDs are being extracted > and stored. Perhaps IANA should stop this practice. You can carry > this logic right on through -- it seems pointless for IANA to extract > and store any information at all -- people should just hunt through RFCs > if they want to find any Internet 'data'. Maybe IANA should never extract > any data from any published document, since this is redundant and > wastes precious iana.org bandwidth. > > > > Andy > > > > > I suggest this be raised to the IAB, who, if I understand correctly, > > have the job over overseeing the contracts with the RFC Editor > > function to meet IETF needs (and I think might also control contracts > > with the provider of ietf.org servers). > > > >> (I bet the extra bandwidth used up by NETCONF/YANG file retrieval > >> is less than the email bandwidth the IETF uses up worrying about > >> NETCONF/YANG file retrieval. ;-) > > > > I am pretty sure the bandwidth and storage requirements for > > IETF-standard netconf schema would be dwarfed by the requirements for > > bandwidth and storage of emails discussing the size of cookies > > provided during IETF meetings. > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > dharrington@huawei.com > > > > > > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf cture. > > > >> Perhaps a never-ending list of arbitrarily named text files > > (RFCnnnn) > >> was sufficient in previous decades, but it isn't enough anymore. > >> In order to build a meaningful standards-based CM system, the > >> IETF standards track YANG modules, XSD and DSDL files should be > >> accessible online. If the IETF does not want to take on any > >> more responsibility than a document archive (understandable), > >> then other sites will host the data modules, in an ad-hoc, > >> non-standard manner. Perhaps applications will guess the > >> schemaLocation by trying free databases, ala CDDB. > > > > I think it would benefit the IETF community to have rfc-editor.org or > > ietf.org (not iana.org) host an archive for standard data models, > > including MIB modules. But there has to be a concern that the > > normative document (the RFC) and the extracted schema could differ. > > There are a number of issues that would need to be addressed, as > > Juergen points out. > > > Well, IANA extracts XSDs from RFCs are stores them in the > http://www.iana.org/assignments/xml-registry/schema/ directory. > > I suppose there is some valid reason why IANA needs to maintain > these online files, yet not want them to be found via an > clause. > > Whether they differ from the RFC or not, these XSDs are being extracted > and stored. Perhaps IANA should stop this practice. You can carry > this logic right on through -- it seems pointless for IANA to extract > and store any information at all -- people should just hunt through RFCs > if they want to find any Internet 'data'. Maybe IANA should never extract > any data from any published document, since this is redundant and > wastes precious iana.org bandwidth. > > > > Andy > > > > > I suggest this be raised to the IAB, who, if I understand correctly, > > have the job over overseeing the contracts with the RFC Editor > > function to meet IETF needs (and I think might also control contracts > > with the provider of ietf.org servers). > > > >> (I bet the extra bandwidth used up by NETCONF/YANG file retrieval > >> is less than the email bandwidth the IETF uses up worrying about > >> NETCONF/YANG file retrieval. ;-) > > > > I am pretty sure the bandwidth and storage requirements for > > IETF-standard netconf schema would be dwarfed by the requirements for > > bandwidth and storage of emails discussing the size of cookies > > provided during IETF meetings. > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > dharrington@huawei.com > > > > > > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 22 06:47:51 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31CEE28C48E; Tue, 22 Apr 2008 06:47:51 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70313A68AB for ; Tue, 22 Apr 2008 06:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HciRG7vbdwHb for ; Tue, 22 Apr 2008 06:47:44 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id A926928C496 for ; Tue, 22 Apr 2008 06:46:17 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id Gd4y1Z00Z0EPchoA201H00; Tue, 22 Apr 2008 13:44:42 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id Gdlh1Z00L4HwxpC8M00000; Tue, 22 Apr 2008 13:45:48 +0000 X-Authority-Analysis: v=1.0 c=1 a=P3TxG7Rh1ygA:10 a=eF-_h_emeUgA:10 a=I0CVDw5ZAAAA:8 a=48vgC7mUAAAA:8 a=83Kz4SxKcBi6zSvA9foA:9 a=6aa0ydoOwgvvvOH2hp4A:7 a=ykrgIay9OyH0PtfUC4kq3X3tCRUA:4 a=P2TwHfrFO3IA:10 a=kkUMZHjH4KkA:10 a=huntNF1cNFcA:10 a=jFPUFpGHtmAA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Bert Wijnen - IETF'" , "'Andy Bierman'" References: <480D6187.7070406@andybierman.com> Date: Tue, 22 Apr 2008 09:45:41 -0400 Message-ID: <007101c8a47f$28ff4900$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcikWy6MHlscSAeIT2e+/VhgbxqFpQAIKR+w Cc: netconf@ietf.org Subject: Re: [Netconf] Holding Notifications Document (was: RE: Netconf Notification: Issues 22: Import Statements) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Is this a WGLC on this document? The subject line doesn't say so. The subject line is about the issue of a stable reference to support imports, so I think the discussion of whether we can get a stable archive to reference is part of the issue mentioned in the subject line. I suggest that rather than grouse about it, we should (very quickly) determine whose responsibility it would be to host such an archive, and determine from those responsible whether an archive will be set up. I spoke up because I think expecting IANA to host such a repository is asking the wrong organization to do this. If we want the problem solved, we should talk to the right people. If the goal of the WG is to deliver solutions of good technical quality to help the Internet run better, we might want to try to solve this (mainly) engineering problem to produce a solution that willFrom netconf-bounces@ietf.org Tue Apr 22 06:47:51 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31CEE28C48E; Tue, 22 Apr 2008 06:47:51 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70313A68AB for ; Tue, 22 Apr 2008 06:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HciRG7vbdwHb for ; Tue, 22 Apr 2008 06:47:44 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id A926928C496 for ; Tue, 22 Apr 2008 06:46:17 -0700 (PDT) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id Gd4y1Z00Z0EPchoA201H00; Tue, 22 Apr 2008 13:44:42 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id Gdlh1Z00L4HwxpC8M00000; Tue, 22 Apr 2008 13:45:48 +0000 X-Authority-Analysis: v=1.0 c=1 a=P3TxG7Rh1ygA:10 a=eF-_h_emeUgA:10 a=I0CVDw5ZAAAA:8 a=48vgC7mUAAAA:8 a=83Kz4SxKcBi6zSvA9foA:9 a=6aa0ydoOwgvvvOH2hp4A:7 a=ykrgIay9OyH0PtfUC4kq3X3tCRUA:4 a=P2TwHfrFO3IA:10 a=kkUMZHjH4KkA:10 a=huntNF1cNFcA:10 a=jFPUFpGHtmAA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Bert Wijnen - IETF'" , "'Andy Bierman'" References: <480D6187.7070406@andybierman.com> Date: Tue, 22 Apr 2008 09:45:41 -0400 Message-ID: <007101c8a47f$28ff4900$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcikWy6MHlscSAeIT2e+/VhgbxqFpQAIKR+w Cc: netconf@ietf.org Subject: Re: [Netconf] Holding Notifications Document (was: RE: Netconf Notification: Issues 22: Import Statements) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Is this a WGLC on this document? The subject line doesn't say so. The subject line is about the issue of a stable reference to support imports, so I think the discussion of whether we can get a stable archive to reference is part of the issue mentioned in the subject line. I suggest that rather than grouse about it, we should (very quickly) determine whose responsibility it would be to host such an archive, and determine from those responsible whether an archive will be set up. I spoke up because I think expecting IANA to host such a repository is asking the wrong organization to do this. If we want the problem solved, we should talk to the right people. If the goal of the WG is to deliver solutions of good technical quality to help the Internet run better, we might want to try to solve this (mainly) engineering problem to produce a solution that will impro improve the situation compared to the difficulty of finding MIB modules. Our community probably has the most long-running problem caused by the lack of such a repository, and we should make it clear to those responsible that this is a real problem we need solved. If the goal is to make the document shepherd happy that we make immediate progress, then we probably want to eliminate the schemaLocation and let people hunt around to find the schema wherever google sends them. I have no desire to see a loooong discussion either, but neither do I want to see us produce a poor quality solution to satisfy a petulant document shepherd. I think the solution is somewhere in between. I think we should, to resolve this issue, contact the right people about the real need for such a stable archive in the future, AND, to make document progress, either use a URN or remove the schemaLocation. To deal only with the document is to **not resolve** the issue but to ignore it. dbh > -----Original Message----- > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > Sent: Tuesday, April 22, 2008 5:28 AM > To: Andy Bierman; David B Harrington > Cc: netconf@ietf.org > Subject: Holding Notifications Document (was: RE: [Netconf] > Netconf Notification: Issues 22: Import Statements) > > See... this seems to be the first step in a path of loooooong delay. > We have (in about 1 day) shifted our dicussion about our own > WG document into a discussion about the generic issue of storing > (and giving access) to extracted data from RFCs. > > PLEASE... if you want to have this generic discussion, then > relabel the subject line (so I can ignore it). As document shepherd, > I am NOT interested in that type of discussion. > > If you want the document to be hold up for this, then PLEASE do not > discuss this in detail, but just post one short message to the WG > list with subject "Holding Notifications Document". > > If I see consensus forming to do that, then I can hand back my task > as "document shepherd" and give the document back to the WG for > further year-long discussions about this topic. > > Bert Wijnen > Speaking as document shepherd > > > -----Oorspronkelijk bericht----- > > Van: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org]Namens > > Andy Bierman > > Verzonden: dinsdag 22 april 2008 5:55 > > Aan: David B Harrington > > CC: netconf@ietf.org > > Onderwerp: Re: [Netconf] Netconf Notification: Issues 22: Import > > Statements > > > > > > David B Harrington wrote: > > > > > > > > >> I suppose there is a slippery slope between being a standards > > >> archive and > > >> becoming part of the application infrastructure. > > > > > > There is a slippery slope between being a numnbering > authority (IANA) > > > and being a standards archive (ala the RFC series) that > becomes part > > > of the application infrastructure. > > > > > >> Perhaps a never-ending list of arbitrarily named text files > > > (RFCnnnn) > > >> was sufficient in previous decades, but it isn't enough anymore. > > >> In order to build a meaningful standards-based CM system, the > > >> IETF standards track YANG modules, XSD and DSDL files should be > > >> accessible online. If the IETF does not want to take on any > > >> more responsibility than a document archive (understandable), > > >> then other sites will host the data modules, in an ad-hoc, > > >> non-standard manner. Perhaps applications will guess the > > >> schemaLocation by trying free databases, ala CDDB. > > > > > > I think it would benefit the IETF community to have > rfc-editor.org or > > > ietf.org (not iana.org) host an archive for standard data models, > > > including MIB modules. But there has to be a concern that the > > > normative document (the RFC) and the extracted schema > could differ. > > > There are a number of issues that would need to be addressed, as > > > Juergen points out. > > > > > > Well, IANA extracts XSDs from RFCs are stores them in the > > http://www.iana.org/assignments/xml-registry/schema/ directory. > > > > I suppose there is some valid reason why IANA needs tve the situation compared to the difficulty of finding MIB modules. Our community probably has the most long-running problem caused by the lack of such a repository, and we should make it clear to those responsible that this is a real problem we need solved. If the goal is to make the document shepherd happy that we make immediate progress, then we probably want to eliminate the schemaLocation and let people hunt around to find the schema wherever google sends them. I have no desire to see a loooong discussion either, but neither do I want to see us produce a poor quality solution to satisfy a petulant document shepherd. I think the solution is somewhere in between. I think we should, to resolve this issue, contact the right people about the real need for such a stable archive in the future, AND, to make document progress, either use a URN or remove the schemaLocation. To deal only with the document is to **not resolve** the issue but to ignore it. dbh > -----Original Message----- > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > Sent: Tuesday, April 22, 2008 5:28 AM > To: Andy Bierman; David B Harrington > Cc: netconf@ietf.org > Subject: Holding Notifications Document (was: RE: [Netconf] > Netconf Notification: Issues 22: Import Statements) > > See... this seems to be the first step in a path of loooooong delay. > We have (in about 1 day) shifted our dicussion about our own > WG document into a discussion about the generic issue of storing > (and giving access) to extracted data from RFCs. > > PLEASE... if you want to have this generic discussion, then > relabel the subject line (so I can ignore it). As document shepherd, > I am NOT interested in that type of discussion. > > If you want the document to be hold up for this, then PLEASE do not > discuss this in detail, but just post one short message to the WG > list with subject "Holding Notifications Document". > > If I see consensus forming to do that, then I can hand back my task > as "document shepherd" and give the document back to the WG for > further year-long discussions about this topic. > > Bert Wijnen > Speaking as document shepherd > > > -----Oorspronkelijk bericht----- > > Van: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org]Namens > > Andy Bierman > > Verzonden: dinsdag 22 april 2008 5:55 > > Aan: David B Harrington > > CC: netconf@ietf.org > > Onderwerp: Re: [Netconf] Netconf Notification: Issues 22: Import > > Statements > > > > > > David B Harrington wrote: > > > > > > > > >> I suppose there is a slippery slope between being a standards > > >> archive and > > >> becoming part of the application infrastructure. > > > > > > There is a slippery slope between being a numnbering > authority (IANA) > > > and being a standards archive (ala the RFC series) that > becomes part > > > of the application infrastructure. > > > > > >> Perhaps a never-ending list of arbitrarily named text files > > > (RFCnnnn) > > >> was sufficient in previous decades, but it isn't enough anymore. > > >> In order to build a meaningful standards-based CM system, the > > >> IETF standards track YANG modules, XSD and DSDL files should be > > >> accessible online. If the IETF does not want to take on any > > >> more responsibility than a document archive (understandable), > > >> then other sites will host the data modules, in an ad-hoc, > > >> non-standard manner. Perhaps applications will guess the > > >> schemaLocation by trying free databases, ala CDDB. > > > > > > I think it would benefit the IETF community to have > rfc-editor.org or > > > ietf.org (not iana.org) host an archive for standard data models, > > > including MIB modules. But there has to be a concern that the > > > normative document (the RFC) and the extracted schema > could differ. > > > There are a number of issues that would need to be addressed, as > > > Juergen points out. > > > > > > Well, IANA extracts XSDs from RFCs are stores them in the > > http://www.iana.org/assignments/xml-registry/schema/ directory. > > > > I suppose there is some valid reason why IANA needs to maino maintain > > these online files, yet not want them to be found via an > > clause. > > > > Whether they differ from the RFC or not, these XSDs are > being extracted > > and stored. Perhaps IANA should stop this practice. You can carry > > this logic right on through -- it seems pointless for IANA > to extract > > and store any information at all -- people should just hunt > through RFCs > > if they want to find any Internet 'data'. Maybe IANA > should never extract > > any data from any published document, since this is redundant and > > wastes precious iana.org bandwidth. > > > > > > > > Andy > > > > > > > > I suggest this be raised to the IAB, who, if I understand > correctly, > > > have the job over overseeing the contracts with the RFC Editor > > > function to meet IETF needs (and I think might also > control contracts > > > with the provider of ietf.org servers). > > > > > >> (I bet the extra bandwidth used up by NETCONF/YANG file retrieval > > >> is less than the email bandwidth the IETF uses up worrying about > > >> NETCONF/YANG file retrieval. ;-) > > > > > > I am pretty sure the bandwidth and storage requirements for > > > IETF-standard netconf schema would be dwarfed by the > requirements for > > > bandwidth and storage of emails discussing the size of cookies > > > provided during IETF meetings. > > > > > > David Harrington > > > dbharrington@comcast.net > > > ietfdbh@comcast.net > > > dharrington@huawei.com > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf tain > > these online files, yet not want them to be found via an > > clause. > > > > Whether they differ from the RFC or not, these XSDs are > being extracted > > and stored. Perhaps IANA should stop this practice. You can carry > > this logic right on through -- it seems pointless for IANA > to extract > > and store any information at all -- people should just hunt > through RFCs > > if they want to find any Internet 'data'. Maybe IANA > should never extract > > any data from any published document, since this is redundant and > > wastes precious iana.org bandwidth. > > > > > > > > Andy > > > > > > > > I suggest this be raised to the IAB, who, if I understand > correctly, > > > have the job over overseeing the contracts with the RFC Editor > > > function to meet IETF needs (and I think might also > control contracts > > > with the provider of ietf.org servers). > > > > > >> (I bet the extra bandwidth used up by NETCONF/YANG file retrieval > > >> is less than the email bandwidth the IETF uses up worrying about > > >> NETCONF/YANG file retrieval. ;-) > > > > > > I am pretty sure the bandwidth and storage requirements for > > > IETF-standard netconf schema would be dwarfed by the > requirements for > > > bandwidth and storage of emails discussing the size of cookies > > > provided during IETF meetings. > > > > > > David Harrington > > > dbharrington@comcast.net > > > ietfdbh@comcast.net > > > dharrington@huawei.com > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 22 07:10:23 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D07F3A6D3B; Tue, 22 Apr 2008 07:10:23 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 579553A6DDB for ; Tue, 22 Apr 2008 07:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAxmmxXF6118 for ; Tue, 22 Apr 2008 07:10:18 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id 522473A6CFD for ; Tue, 22 Apr 2008 07:10:18 -0700 (PDT) Received: (qmail 23958 invoked from network); 22 Apr 2008 14:10:24 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@207.215.245.10 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 22 Apr 2008 14:10:22 -0000 X-YMail-OSG: xVKyIj8VM1nA9xpYNd2p6.esScuQbBKtLFG_iG9Y5bsuP0k9gAvyQD_s4H9orTWjHest6zW4JhtqshJlU40vKEKnAGNDBC9pTr7Fc.IMxzwQ1GOr2WGEc8OzGBQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <480DF1CC.1060708@andybierman.com> Date: Tue, 22 Apr 2008 07:10:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: David B Harrington References: <480D6187.7070406@andybierman.com> <007101c8a47f$28ff4900$0600a8c0@china.huawei.com> In-Reply-To: <007101c8a47f$28ff4900$0600a8c0@china.huawei.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Holding Notifications Document X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org David B Harrington wrote: > Hi, > > Is this a WGLC on this document? > The subject line doesn't say so. > The WGLC thread ended already -- remove the schemaLocation attribute and publish seems to be the consensus. All IANA is supposed to do here is maintain a list of URIs assigned to namespaces. A simple text document like for port numbers would be sufficient for this purpose. (Does anyone know if this file exists?) Instead, IANA is extracting XSDs and storing them online, but it does not want applications to know about it. This is neither a registry or a repository. (Let's just keep doing this a few more years and it will become a 'long-standing' tradition that cannot be changed ;-) Andy > The subject line is about the issue of a stable reference to support > imports, so I think the discussion of whether we can get a stable > archive to reference is part of the issue mentioned in the subject > line. I suggest that rather than grouse about it, we should (very > quickly) determine whose responsibility it would be to host such an > archive, and determine from those responsible whether an archive will > be set up. > > I spoke up because I think expecting IANA to host such a repository is > asking the wrong organization to do this. If we want the problem > solved, we should talk to the rightFrom netconf-bounces@ietf.org Tue Apr 22 07:10:23 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D07F3A6D3B; Tue, 22 Apr 2008 07:10:23 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 579553A6DDB for ; Tue, 22 Apr 2008 07:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAxmmxXF6118 for ; Tue, 22 Apr 2008 07:10:18 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id 522473A6CFD for ; Tue, 22 Apr 2008 07:10:18 -0700 (PDT) Received: (qmail 23958 invoked from network); 22 Apr 2008 14:10:24 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@207.215.245.10 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 22 Apr 2008 14:10:22 -0000 X-YMail-OSG: xVKyIj8VM1nA9xpYNd2p6.esScuQbBKtLFG_iG9Y5bsuP0k9gAvyQD_s4H9orTWjHest6zW4JhtqshJlU40vKEKnAGNDBC9pTr7Fc.IMxzwQ1GOr2WGEc8OzGBQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <480DF1CC.1060708@andybierman.com> Date: Tue, 22 Apr 2008 07:10:20 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: David B Harrington References: <480D6187.7070406@andybierman.com> <007101c8a47f$28ff4900$0600a8c0@china.huawei.com> In-Reply-To: <007101c8a47f$28ff4900$0600a8c0@china.huawei.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Holding Notifications Document X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org David B Harrington wrote: > Hi, > > Is this a WGLC on this document? > The subject line doesn't say so. > The WGLC thread ended already -- remove the schemaLocation attribute and publish seems to be the consensus. All IANA is supposed to do here is maintain a list of URIs assigned to namespaces. A simple text document like for port numbers would be sufficient for this purpose. (Does anyone know if this file exists?) Instead, IANA is extracting XSDs and storing them online, but it does not want applications to know about it. This is neither a registry or a repository. (Let's just keep doing this a few more years and it will become a 'long-standing' tradition that cannot be changed ;-) Andy > The subject line is about the issue of a stable reference to support > imports, so I think the discussion of whether we can get a stable > archive to reference is part of the issue mentioned in the subject > line. I suggest that rather than grouse about it, we should (very > quickly) determine whose responsibility it would be to host such an > archive, and determine from those responsible whether an archive will > be set up. > > I spoke up because I think expecting IANA to host such a repository is > asking the wrong organization to do this. If we want the problem > solved, we should talk to the people. > > If the goal of the WG is to deliver solutions of good technical > quality to help the Internet run better, we might want to try to solve > this (mainly) engineering problem to produce a solution that will > improve the situation compared to the difficulty of finding MIB > modules. Our community probably has the most long-running problem > caused by the lack of such a repository, and we should make it clear > to those responsible that this is a real problem we need solved. > > If the goal is to make the document shepherd happy that we make > immediate progress, then we probably want to eliminate the > schemaLocation and let people hunt around to find the schema wherever > google sends them. > > I have no desire to see a loooong discussion either, but neither do I > want to see us produce a poor quality solution to satisfy a petulant > document shepherd. > > I think the solution is somewhere in between. I think we should, to > resolve this issue, contact the right people about the real need for > such a stable archive in the future, AND, to make document progress, > either use a URN or remove the schemaLocation. To deal only with the > document is to **not resolve** the issue but to ignore it. > > > dbh > >> -----Original Message----- >> From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] >> Sent: Tuesday, April 22, 2008 5:28 AM >> To: Andy Bierman; David B Harrington >> Cc: netconf@ietf.org >> Subject: Holding Notifications Document (was: RE: [Netconf] >> Netconf Notification: Issues 22: Import Statements) >> >> See... this seems to be the first step in a path of loooooong delay. >> We have (in about 1 day) shifted our dicussion about our own >> WG document into a discussion about the generic issue of storing >> (and giving access) to extracted data from RFCs. >> >> PLEASE... if you want to have this generic discussion, then >> relabel the subject line (so I can ignore it). As document shepherd, >> I am NOT interested in that type of discussion. >> >> If you want the document to be hold up for this, then PLEASE do not >> discuss this in detail, but just post one short message to the WG >> list with subject "Holding Notifications Document". >> >> If I see consensus forming to do that, then I can hand back my task >> as "document shepherd" and give the document back to the WG for >> further year-long discussions about this topic. >> >> Bert Wijnen >> Speaking as document shepherd >> >>> -----Oorspronkelijk bericht----- >>> Van: netconf-bounces@ietf.org >> [mailto:netconf-bounces@ietf.org]Namens >>> Andy Bierman >>> Verzonden: dinsdag 22 april 2008 5:55 >>> Aan: David B Harrington >>> CC: netconf@ietf.org >>> Onderwerp: Re: [Netconf] Netconf Notification: Issues 22: Import >>> Statements >>> >>> >>> David B Harrington wrote: >>>> >>>>> I suppose there is a slippery slope between being a standards >>>>> archive and >>>>> becoming part of the application infrastructure. >>>> There is a slippery slope between being a numnbering >> authority (IANA) >>>> and being a standards archive (ala the RFC series) that >> becomes part >>>> of the application infrastructure. >>>> >>>>> Perhaps a never-ending list of arbitrarily named text files >>>> (RFCnnnn) >>>>> was sufficient in previous decades, but it isn't enough > anymore. >>>>> In order to build a meaningful standards-based CM system, the >>>>> IETF standards track YANG modules, XSD and DSDL files should be >>>>> accessible online. If the IETF does not want to take on any >>>>> more responsibility than a document archive (understandable), >>>>> then other sites will host the data modules, in an ad-hoc, >>>>> non-standard manner. Perhaps applications will guess the >>>>> schemaLocation by trying free databases, ala CDDB. >>>> I think it would benefit the IETF community to have >> rfc-editor.org or >>>> ietf.org (not iana.org) host an archive for standard data > models, >>>> including MIB modules. But there has to be a concern that the >>>> normative document (the RFC) and the extracted schema >> could differ. >>>> There are a number of issues that wo right people. > > If the goal of the WG is to deliver solutions of good technical > quality to help the Internet run better, we might want to try to solve > this (mainly) engineering problem to produce a solution that will > improve the situation compared to the difficulty of finding MIB > modules. Our community probably has the most long-running problem > caused by the lack of such a repository, and we should make it clear > to those responsible that this is a real problem we need solved. > > If the goal is to make the document shepherd happy that we make > immediate progress, then we probably want to eliminate the > schemaLocation and let people hunt around to find the schema wherever > google sends them. > > I have no desire to see a loooong discussion either, but neither do I > want to see us produce a poor quality solution to satisfy a petulant > document shepherd. > > I think the solution is somewhere in between. I think we should, to > resolve this issue, contact the right people about the real need for > such a stable archive in the future, AND, to make document progress, > either use a URN or remove the schemaLocation. To deal only with the > document is to **not resolve** the issue but to ignore it. > > > dbh > >> -----Original Message----- >> From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] >> Sent: Tuesday, April 22, 2008 5:28 AM >> To: Andy Bierman; David B Harrington >> Cc: netconf@ietf.org >> Subject: Holding Notifications Document (was: RE: [Netconf] >> Netconf Notification: Issues 22: Import Statements) >> >> See... this seems to be the first step in a path of loooooong delay. >> We have (in about 1 day) shifted our dicussion about our own >> WG document into a discussion about the generic issue of storing >> (and giving access) to extracted data from RFCs. >> >> PLEASE... if you want to have this generic discussion, then >> relabel the subject line (so I can ignore it). As document shepherd, >> I am NOT interested in that type of discussion. >> >> If you want the document to be hold up for this, then PLEASE do not >> discuss this in detail, but just post one short message to the WG >> list with subject "Holding Notifications Document". >> >> If I see consensus forming to do that, then I can hand back my task >> as "document shepherd" and give the document back to the WG for >> further year-long discussions about this topic. >> >> Bert Wijnen >> Speaking as document shepherd >> >>> -----Oorspronkelijk bericht----- >>> Van: netconf-bounces@ietf.org >> [mailto:netconf-bounces@ietf.org]Namens >>> Andy Bierman >>> Verzonden: dinsdag 22 april 2008 5:55 >>> Aan: David B Harrington >>> CC: netconf@ietf.org >>> Onderwerp: Re: [Netconf] Netconf Notification: Issues 22: Import >>> Statements >>> >>> >>> David B Harrington wrote: >>>> >>>>> I suppose there is a slippery slope between being a standards >>>>> archive and >>>>> becoming part of the application infrastructure. >>>> There is a slippery slope between being a numnbering >> authority (IANA) >>>> and being a standards archive (ala the RFC series) that >> becomes part >>>> of the application infrastructure. >>>> >>>>> Perhaps a never-ending list of arbitrarily named text files >>>> (RFCnnnn) >>>>> was sufficient in previous decades, but it isn't enough > anymore. >>>>> In order to build a meaningful standards-based CM system, the >>>>> IETF standards track YANG modules, XSD and DSDL files should be >>>>> accessible online. If the IETF does not want to take on any >>>>> more responsibility than a document archive (understandable), >>>>> then other sites will host the data modules, in an ad-hoc, >>>>> non-standard manner. Perhaps applications will guess the >>>>> schemaLocation by trying free databases, ala CDDB. >>>> I think it would benefit the IETF community to have >> rfc-editor.org or >>>> ietf.org (not iana.org) host an archive for standard data > models, >>>> including MIB modules. But there has to be a concern that the >>>> normative document (the RFC) and the extracted schema >> could differ. >>>> There are a number of issues tuld need to be addressed, as >>>> Juergen points out. >>> >>> Well, IANA extracts XSDs from RFCs are stores them in the >>> http://www.iana.org/assignments/xml-registry/schema/ directory. >>> >>> I suppose there is some valid reason why IANA needs to maintain >>> these online files, yet not want them to be found via an >>> clause. >>> >>> Whether they differ from the RFC or not, these XSDs are >> being extracted >>> and stored. Perhaps IANA should stop this practice. You can > carry >>> this logic right on through -- it seems pointless for IANA >> to extract >>> and store any information at all -- people should just hunt >> through RFCs >>> if they want to find any Internet 'data'. Maybe IANA >> should never extract >>> any data from any published document, since this is redundant and >>> wastes precious iana.org bandwidth. >>> >>> >>> >>> Andy >>> >>>> I suggest this be raised to the IAB, who, if I understand >> correctly, >>>> have the job over overseeing the contracts with the RFC Editor >>>> function to meet IETF needs (and I think might also >> control contracts >>>> with the provider of ietf.org servers). >>>> >>>>> (I bet the extra bandwidth used up by NETCONF/YANG file > retrieval >>>>> is less than the email bandwidth the IETF uses up worrying > about >>>>> NETCONF/YANG file retrieval. ;-) >>>> I am pretty sure the bandwidth and storage requirements for >>>> IETF-standard netconf schema would be dwarfed by the >> requirements for >>>> bandwidth and storage of emails discussing the size of cookies >>>> provided during IETF meetings. >>>> >>>> David Harrington >>>> dbharrington@comcast.net >>>> ietfdbh@comcast.net >>>> dharrington@huawei.com >>>> >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >> > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf hat would need to be addressed, as >>>> Juergen points out. >>> >>> Well, IANA extracts XSDs from RFCs are stores them in the >>> http://www.iana.org/assignments/xml-registry/schema/ directory. >>> >>> I suppose there is some valid reason why IANA needs to maintain >>> these online files, yet not want them to be found via an >>> clause. >>> >>> Whether they differ from the RFC or not, these XSDs are >> being extracted >>> and stored. Perhaps IANA should stop this practice. You can > carry >>> this logic right on through -- it seems pointless for IANA >> to extract >>> and store any information at all -- people should just hunt >> through RFCs >>> if they want to find any Internet 'data'. Maybe IANA >> should never extract >>> any data from any published document, since this is redundant and >>> wastes precious iana.org bandwidth. >>> >>> >>> >>> Andy >>> >>>> I suggest this be raised to the IAB, who, if I understand >> correctly, >>>> have the job over overseeing the contracts with the RFC Editor >>>> function to meet IETF needs (and I think might also >> control contracts >>>> with the provider of ietf.org servers). >>>> >>>>> (I bet the extra bandwidth used up by NETCONF/YANG file > retrieval >>>>> is less than the email bandwidth the IETF uses up worrying > about >>>>> NETCONF/YANG file retrieval. ;-) >>>> I am pretty sure the bandwidth and storage requirements for >>>> IETF-standard netconf schema would be dwarfed by the >> requirements for >>>> bandwidth and storage of emails discussing the size of cookies >>>> provided during IETF meetings. >>>> >>>> David Harrington >>>> dbharrington@comcast.net >>>> ietfdbh@comcast.net >>>> dharrington@huawei.com >>>> >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >> > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 22 09:12:00 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D9293A6E62; Tue, 22 Apr 2008 09:12:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9BBB3A6E0D for ; Tue, 22 Apr 2008 09:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNxEye53S-Xz for ; Tue, 22 Apr 2008 09:11:57 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id B81AA3A6E67 for ; Tue, 22 Apr 2008 09:11:57 -0700 (PDT) Received: (qmail 85873 invoked from network); 22 Apr 2008 16:12:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.242.137 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 22 Apr 2008 16:12:02 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <480E0E51.8090001@andybierman.com> Date: Tue, 22 Apr 2008 09:12:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: David B Harrington References: <480D6187.7070406@andybierman.com> <007101c8a47f$28ff4900$0600a8c0@china.huawei.com> In-Reply-To: <007101c8a47f$28ff4900$0600a8c0@china.huawei.com> Cc: netconf@ietf.org Subject: [Netconf] Notification-12 schemaLocation edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, There is an IANA XML Registry: http://www.iana.org/assignments/xml-registry-index.html I looked at all 47 of the XSDs in the IANA XML registry: http://www.iana.org/assignments/xml-registry/schema.html There is a clear practice of using schemaLocation attributes for other XSDs in the registry, which is exactly what the Notifications XSD is doing, except with the wrong kind of URL. First the data: Many XSDs do not have any elements. Most XSDs that have an element, like these, do not have a targetNamespace attribute in the element: http://www.iana.org/assignments/xml-registry/schema/contact-1.0.xsd http://www.iana.org/assignments/xml-registry/schema/dchk1.xsd http://www.iana.org/assignments/xml-registry/schema/domain-1.0.xsd http://www.iana.org/assignments/xml-registry/schema/epp-1.0.xsd http://www.iana.org/assignments/xml-registry/schema/ereg1.xsd http://www.iana.org/assignments/xml-registry/schema/host-1.0.xsd Some (including netconf) have the following import, which is one of the corner-case XSDs that causes lots of WEB traffic: I think best current practice is not to have this import in XSDs anymore, but I'm not sure. Some XSDs, like these, have a targetNamespace attribute in an element: http://www.iana.org/assignments/xml-registry/schema/enum-token-1.0.xsd http://www.iana.org/assignments/xml-registry/schema/e164val-1.0.xsd http://www.iana.org/assignments/xml-registry/schema/e164valex-1.1.xsd http://www.iana.org/assignments/xml-registry/schema/pidf/timed-status.xsd These schemaLocation attributes are all relative URLs for other XSDs in the same directory (a few elements do the same thing). It seems clear that the Notifications XSD should use a relative URL instead of no schemaLocation at all. Here are the edits: -------------------------------------- notification-12, page 18: OLD: NEW: -------------------------------------- notification-12, page 24: OLD: NEW: -------------------------------------- Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 22 09:12:00 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D9293A6E62; Tue, 22 Apr 2008 09:12:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9BBB3A6E0D for ; Tue, 22 Apr 2008 09:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNxEye53S-Xz for ; Tue, 22 Apr 2008 09:11:57 -0700 (PDT) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id B81AA3A6E67 for ; Tue, 22 Apr 2008 09:11:57 -0700 (PDT) Received: (qmail 85873 invoked from network); 22 Apr 2008 16:12:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.126.242.137 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 22 Apr 2008 16:12:02 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <480E0E51.8090001@andybierman.com> Date: Tue, 22 Apr 2008 09:12:01 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: David B Harrington References: <480D6187.7070406@andybierman.com> <007101c8a47f$28ff4900$0600a8c0@china.huawei.com> In-Reply-To: <007101c8a47f$28ff4900$0600a8c0@china.huawei.com> Cc: netconf@ietf.org Subject: [Netconf] Notification-12 schemaLocation edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, There is an IANA XML Registry: http://www.iana.org/assignments/xml-registry-index.html I looked at all 47 of the XSDs in the IANA XML registry: http://www.iana.org/assignments/xml-registry/schema.html There is a clear practice of using schemaLocation attributes for other XSDs in the registry, which is exactly what the Notifications XSD is doing, except with the wrong kind of URL. First the data: Many XSDs do not have any elements. Most XSDs that have an element, like these, do not have a targetNamespace attribute in the element: http://www.iana.org/assignments/xml-registry/schema/contact-1.0.xsd http://www.iana.org/assignments/xml-registry/schema/dchk1.xsd http://www.iana.org/assignments/xml-registry/schema/domain-1.0.xsd http://www.iana.org/assignments/xml-registry/schema/epp-1.0.xsd http://www.iana.org/assignments/xml-registry/schema/ereg1.xsd http://www.iana.org/assignments/xml-registry/schema/host-1.0.xsd Some (including netconf) have the following import, which is one of the corner-case XSDs that causes lots of WEB traffic: I think best current practice is not to have this import in XSDs anymore, but I'm not sure. Some XSDs, like these, have a targetNamespace attribute in an element: http://www.iana.org/assignments/xml-registry/schema/enum-token-1.0.xsd http://www.iana.org/assignments/xml-registry/schema/e164val-1.0.xsd http://www.iana.org/assignments/xml-registry/schema/e164valex-1.1.xsd http://www.iana.org/assignments/xml-registry/schema/pidf/timed-status.xsd These schemaLocation attributes are all relative URLs for other XSDs in the same directory (a few elements do the same thing). It seems clear that the Notifications XSD should use a relative URL instead of no schemaLocation at all. Here are the edits: -------------------------------------- notification-12, page 18: OLD: NEW: -------------------------------------- notification-12, page 24: OLD: NEW: -------------------------------------- Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 22 10:14:05 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2836C3A6D6B; Tue, 22 Apr 2008 10:14:05 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C40828C498 for ; Tue, 22 Apr 2008 10:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzuzFYdoyuVe for ; Tue, 22 Apr 2008 10:14:02 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 260F03A6E42 for ; Tue, 22 Apr 2008 10:14:01 -0700 (PDT) Received: (qmail 57123 invoked from network); 22 Apr 2008 17:14:07 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 22 Apr 2008 17:14:07 -0000 From: "Bert Wijnen - IETF" To: "David B Harrington" , "'Andy Bierman'" Date: Tue, 22 Apr 2008 19:14:09 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <007101c8a47f$28ff4900$0600a8c0@china.huawei.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Cc: netconf@ietf.org Subject: Re: [Netconf] Holding Notifications Document (was: RE: Netconf Notification: Issues 22: Import Statements) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Be my guest and go find the "right people" to setup and maintain such a web site. If you want me to hold the document hostage till that is done, then fine.... I will give in to that. My experience in this space tells me we will be at least one year further (if we ever get it done). At that time, there will be new IESG members, new IAB members, and the doc (since it has been out of sight for a year or more) will get re-scrutinized, and some IESG or IAB member (or one of their directorate members (of whom we have plenty these days) will find another issue that needs to be resolved... and on and on and on... I don't think it is my task as document shepherd to try and entertain all sorts of (in my view minor) issues that will delay the document forever. I agree that being able to IMPORT is goodness. But if we loose that (like all current schema definitions in IETF do not have it), is that making the document fatally flawed? I don't think so. So let us go ahead and accept the comment from IESG/IANA and get the docuemnt approved. Those who have the enery to go fight for a repository that can be referenced/used in an IMPORT Statement can then go and fight that battle. I might even participate... but I prefer not to hold up the document. At the other hand... we'll do whatever seems to be consensus of the WG. Untill I see more than a few people speak up, I do not see a reason to start this long process, beginning with a WGLC type action. Bert Wijnen > -----Oorspronkelijk bericht----- > Van: David B Harrington [mailto:dbharrington@comcast.net] > Verzonden: dinsdag 22 april 2008 15:46 > Aan: 'Bert Wijnen - IETF'; 'Andy Bierman' > CC: netconf@ietf.org > Onderwerp: RE: Holding Notifications Document (was: RE: [Netconf] > Netconf Notification: Issues 22: Import Statements) > > > Hi, > > Is this a WGLC on this document? > The subject line doesn't say so. > > The subject line is about the issue of a stable reference to support > imports, so I think the discussion of whether we can get a stable > archive to reference is part of the issue mentioned in the subject > line. I suggest that rather than grouse about it, we should (very > quickly) determine whose responsibility it would be to host such an > archive, and determine from those responsible whether an archive will > be set up. > > I spoke up because I think expecting IANA to host such a repository is > asking the wrong organization to do this. If we want the problem > solved, we should talk to the right people. > > If the goal of the WG is to deliver solutions of good technical > quality to help the Internet run better, we might want to try to solve > this (mainly) engineering problem to produce a solution that will > improve the situation compared to the difficulty of finding MIB > modules. Our community probably has the most long-running problem > caused by the lack of such a repository, and we should make it clear > to those responsible that this is a real problem we need solved. > > If the goal is to make the document shepherd happy that we make > immediate progress, then we probably want to eliminate the > schemaLocation and let people hunt around to find the schema wherever > google sends them. > > I have no desire to see a loooong discussion either, but neither do I > want to see us produce a poor quality solution to satisfy a petulant > document shepherd. > > I think the solution is somewhere in between. I think we should, to > resolve this issue, contact the right people about the real need for > such a stable archive in the future, AND, to make document progress, > either use a URN or remove the schemaLocation. To deal only with the > document is to **not resolve** the issue but to ignore it. > > > dbh > > > -----Original Message----- > > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > > Sent: Tuesday, April 22, 2008 5:28 AM > > To: Andy Bierman; David B Harrington > > Cc: netconf@ietf.org > > Subject: Holding Notifications Document (was: RE: [Netconf] > > Netconf Notification: Issues 22: Import Statements) > > > > See... this seems to be the first step in a path of loooooong delay. > > We have (in about 1 day) shifted our dicussion about our own > > WG document into a discussion about the generic issue of storing > > (and giving access) to extracted data from RFCs. > > > > PLEASE... if you want to have this generic discussion, then > > relabel the subject line (so I can ignore it). As document shepherd, > > I am NOT interested in that type of discussion. > > > > If you want the document to be hold up for this, then PLEASE do not > > discuss this in detail, but just post one short message to the WG > > list with subject "Holding Notifications Document". > > > > If I see consensus forming to do that, then I can hand back my task > > as "document shepherd" and give the document back to the WG for > > further year-long discussions about this topic. > > > > Bert Wijnen > > Speaking as document shepherd > > > > > -----Oorspronkelijk bericht----- > > > Van: netconf-bounces@ietf.org > > [mailto:netconf-bounces@ietf.org]Namens > > > Andy Bierman > > > Verzonden: dinsdag 22 april 2008 5:55 > > > Aan: David B Harrington > > > CC: netconf@ietf.org > > > Onderwerp: Re: [Netconf] Netconf Notification: Issues 22: Import > > > Statements > > > > > > > > > David B Harrington wrote: > > > > > > > > > > > >> I suppose there is a slippery slope between being a standards > > > >> archive and > > > >> becoming part of the application infrastructure. > > > > > > > > There is a slippery slope between being a numnbering > > authority (IANA) > > > > and being a standards archive (ala the RFC series) that > > becomes part > > > > of the application infrastructure. > > > > > > > >> Perhaps a never-ending list of arbitrarily named text files > > > > (RFCnnnn) > > > >> was sufficient in previous decades, but it isn't enough > anymore. > > > >> In order to build a meaningful standards-based CM system, the > > > >> IETF standards track YANG modules, XSD and DSDL files should be > > > >> accessible online. If the IETF does not want to take on any > > > >> more responsibility than a document archive (understandable), > > > >> then other sites will host the data modules, in an ad-hoc, > > > >> non-standard manner. Perhaps applications will guess the > > > >> schemaLocation by trying free databases, ala CDDB. > > > > > > > > I think it would benefit the IETF community to have > > rfc-editor.org or > > > > ietf.org (not iana.org) host an archive for standard data > models, > > > > including MIB modules. But there has to be a concern that the > > > > normative document (the RFC) and the extracted schema > > could differ. > > > > There are a number of issues that would need to be addressed, as > > > > Juergen points out. > > > > > > > > > Well, IANA extracts XSDs from RFCs are stores them in the > > > http://www.iana.org/assignments/xml-registry/schema/ directory. > > > > > > I suppose there is some valid reason why IANA needs to maintain > > > these online files, yet not want them to be found via an > > > clause. > > > > > > Whether they differ from the RFC or not, these XSDs are > > being extracted > > > and stored. Perhaps IANA should stop this practice. You can > carry > > > this logic right on through -- it seems pointless for IANA > > to extract > > > and store any information at all -- people should just hunt > > through RFCs > > > if they want to find any Internet 'data'. Maybe IANA > > should never extract > > > any data from any published document, since this is redundant and > > > wastes precious iana.org bandwidth. > > > > > > > > > > > > Andy > > > > > > > > > > > I suggest this be raised to the IAB, who, if I understand > > correctly, > > > > have the job over overseeing the contracts with the RFC Editor > > > > function to meet IETF needs (and I think might also > > control contracts > > > > with the provider of ietf.org servers). > > > > > > > >> (I bet the extra bandwidth used up by NETCONF/YANG file > retrieval > > > >> is less than the email bandwidth the IETF uses up worrying > about > > > >> NETCONF/YANG file retrieval. ;-) > > > > > > > > I am pretty sure the bandwidth and storage requirements for > > > > IETF-standard netconf schema would be dwarfed by the > > requirements for > > > > bandwidth and storage of emails discussing the size of cookies > > > > provided during IETF meetings. > > > > > > > > David Harrington > > > > dbharrington@comcast.net > > > > ietfdbh@comcast.net > > > > dharrington@huawei.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 22 10:14:05 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2836C3A6D6B; Tue, 22 Apr 2008 10:14:05 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C40828C498 for ; Tue, 22 Apr 2008 10:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzuzFYdoyuVe for ; Tue, 22 Apr 2008 10:14:02 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 260F03A6E42 for ; Tue, 22 Apr 2008 10:14:01 -0700 (PDT) Received: (qmail 57123 invoked from network); 22 Apr 2008 17:14:07 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 22 Apr 2008 17:14:07 -0000 From: "Bert Wijnen - IETF" To: "David B Harrington" , "'Andy Bierman'" Date: Tue, 22 Apr 2008 19:14:09 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <007101c8a47f$28ff4900$0600a8c0@china.huawei.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Cc: netconf@ietf.org Subject: Re: [Netconf] Holding Notifications Document (was: RE: Netconf Notification: Issues 22: Import Statements) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Be my guest and go find the "right people" to setup and maintain such a web site. If you want me to hold the document hostage till that is done, then fine.... I will give in to that. My experience in this space tells me we will be at least one year further (if we ever get it done). At that time, there will be new IESG members, new IAB members, and the doc (since it has been out of sight for a year or more) will get re-scrutinized, and some IESG or IAB member (or one of their directorate members (of whom we have plenty these days) will find another issue that needs to be resolved... and on and on and on... I don't think it is my task as document shepherd to try and entertain all sorts of (in my view minor) issues that will delay the document forever. I agree that being able to IMPORT is goodness. But if we loose that (like all current schema definitions in IETF do not have it), is that making the document fatally flawed? I don't think so. So let us go ahead and accept the comment from IESG/IANA and get the docuemnt approved. Those who have the enery to go fight for a repository that can be referenced/used in an IMPORT Statement can then go and fight that battle. I might even participate... but I prefer not to hold up the document. At the other hand... we'll do whatever seems to be consensus of the WG. Untill I see more than a few people speak up, I do not see a reason to start this long process, beginning with a WGLC type action. Bert Wijnen > -----Oorspronkelijk bericht----- > Van: David B Harrington [mailto:dbharrington@comcast.net] > Verzonden: dinsdag 22 april 2008 15:46 > Aan: 'Bert Wijnen - IETF'; 'Andy Bierman' > CC: netconf@ietf.org > Onderwerp: RE: Holding Notifications Document (was: RE: [Netconf] > Netconf Notification: Issues 22: Import Statements) > > > Hi, > > Is this a WGLC on this document? > The subject line doesn't say so. > > The subject line is about the issue of a stable reference to support > imports, so I think the discussion of whether we can get a stable > archive to reference is part of the issue mentioned in the subject > line. I suggest that rather than grouse about it, we should (very > quickly) determine whose responsibility it would be to host such an > archive, and determine from those responsible whether an archive will > be set up. > > I spoke up because I think expecting IANA to host such a repository is > asking the wrong organization to do this. If we want the problem > solved, we should talk to the right people. > > If the goal of the WG is to deliver solutions of good technical > quality to help the Internet run better, we might want to try to solve > this (mainly) engineering problem to produce a solution that will > improve the situation compared to the difficulty of finding MIB > modules. Our community probably has the most long-running problem > caused by the lack of such a repository, and we should make it clear > to those responsible that this is a real problem we need solved. > > If the goal is to make the document shepherd happy that we make > immediate progress, then we probably want to eliminate the > schemaLocation and let people hunt around to find the schema wherever > google sends them. > > I have no desire to see a loooong discussion either, but neither do I > want to see us produce a poor quality solution to satisfy a petulant > document shepherd. > > I think the solution is somewhere in between. I think we should, to > resolve this issue, contact the right people about the real need for > such a stable archive in the future, AND, to make document progress, > either use a URN or remove the schemaLocation. To deal only with the > document is to **not resolve** the issue but to ignore it. > > > dbh > > > -----Original Message----- > > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > > Sent: Tuesday, April 22, 2008 5:28 AM > > To: Andy Bierman; David B Harrington > > Cc: netconf@ietf.org > > Subject: Holding Notifications Document (was: RE: [Netconf] > > Netconf Notification: Issues 22: Import Statements) > > > > See... this seems to be the first step in a path of loooooong delay. > > We have (in about 1 day) shifted our dicussion about our own > > WG document into a discussion about the generic issue of storing > > (and giving access) to extracted data from RFCs. > > > > PLEASE... if you want to have this generic discussion, then > > relabel the subject line (so I can ignore it). As document shepherd, > > I am NOT interested in that type of discussion. > > > > If you want the document to be hold up for this, then PLEASE do not > > discuss this in detail, but just post one short message to the WG > > list with subject "Holding Notifications Document". > > > > If I see consensus forming to do that, then I can hand back my task > > as "document shepherd" and give the document back to the WG for > > further year-long discussions about this topic. > > > > Bert Wijnen > > Speaking as document shepherd > > > > > -----Oorspronkelijk bericht----- > > > Van: netconf-bounces@ietf.org > > [mailto:netconf-bounces@ietf.org]Namens > > > Andy Bierman > > > Verzonden: dinsdag 22 april 2008 5:55 > > > Aan: David B Harrington > > > CC: netconf@ietf.org > > > Onderwerp: Re: [Netconf] Netconf Notification: Issues 22: Import > > > Statements > > > > > > > > > David B Harrington wrote: > > > > > > > > > > > >> I suppose there is a slippery slope between being a standards > > > >> archive and > > > >> becoming part of the application infrastructure. > > > > > > > > There is a slippery slope between being a numnbering > > authority (IANA) > > > > and being a standards archive (ala the RFC series) that > > becomes part > > > > of the application infrastructure. > > > > > > > >> Perhaps a never-ending list of arbitrarily named text files > > > > (RFCnnnn) > > > >> was sufficient in previous decades, but it isn't enough > anymore. > > > >> In order to build a meaningful standards-based CM system, the > > > >> IETF standards track YANG modules, XSD and DSDL files should be > > > >> accessible online. If the IETF does not want to take on any > > > >> more responsibility than a document archive (understandable), > > > >> then other sites will host the data modules, in an ad-hoc, > > > >> non-standard manner. Perhaps applications will guess the > > > >> schemaLocation by trying free databases, ala CDDB. > > > > > > > > I think it would benefit the IETF community to have > > rfc-editor.org or > > > > ietf.org (not iana.org) host an archive for standard data > models, > > > > including MIB modules. But there has to be a concern that the > > > > normative document (the RFC) and the extracted schema > > could differ. > > > > There are a number of issues that would need to be addressed, as > > > > Juergen points out. > > > > > > > > > Well, IANA extracts XSDs from RFCs are stores them in the > > > http://www.iana.org/assignments/xml-registry/schema/ directory. > > > > > > I suppose there is some valid reason why IANA needs to maintain > > > these online files, yet not want them to be found via an > > > clause. > > > > > > Whether they differ from the RFC or not, these XSDs are > > being extracted > > > and stored. Perhaps IANA should stop this practice. You can > carry > > > this logic right on through -- it seems pointless for IANA > > to extract > > > and store any information at all -- people should just hunt > > through RFCs > > > if they want to find any Internet 'data'. Maybe IANA > > should never extract > > > any data from any published document, since this is redundant and > > > wastes precious iana.org bandwidth. > > > > > > > > > > > > Andy > > > > > > > > > > > I suggest this be raised to the IAB, who, if I understand > > correctly, > > > > have the job over overseeing the contracts with the RFC Editor > > > > function to meet IETF needs (and I think might also > > control contracts > > > > with the provider of ietf.org servers). > > > > > > > >> (I bet the extra bandwidth used up by NETCONF/YANG file > retrieval > > > >> is less than the email bandwidth the IETF uses up worrying > about > > > >> NETCONF/YANG file retrieval. ;-) > > > > > > > > I am pretty sure the bandwidth and storage requirements for > > > > IETF-standard netconf schema would be dwarfed by the > > requirements for > > > > bandwidth and storage of emails discussing the size of cookies > > > > provided during IETF meetings. > > > > > > > > David Harrington > > > > dbharrington@comcast.net > > > > ietfdbh@comcast.net > > > > dharrington@huawei.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 22 10:18:16 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4093028C4C1; Tue, 22 Apr 2008 10:18:16 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 456F128C4BA for ; Tue, 22 Apr 2008 10:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IER7pPyrGHHL for ; Tue, 22 Apr 2008 10:18:07 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 79E3828C4CE for ; Tue, 22 Apr 2008 10:16:24 -0700 (PDT) Received: (qmail 59981 invoked from network); 22 Apr 2008 17:15:55 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 22 Apr 2008 17:15:55 -0000 From: "Bert Wijnen - IETF" To: "Andy Bierman" , "David B Harrington" Date: Tue, 22 Apr 2008 19:15:57 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <480E0E51.8090001@andybierman.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Cc: netconf@ietf.org Subject: Re: [Netconf] Notification-12 schemaLocation edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Yep... and I believe this is what the IESG wants us to do based on the DISCUSS we have seen. Bert Wijnen > -----Oorspronkelijk bericht----- > Van: Andy Bierman [mailto:ietf@andybierman.com] > Verzonden: dinsdag 22 april 2008 18:12 > Aan: David B Harrington > CC: 'Bert Wijnen - IETF'; netconf@ietf.org > Onderwerp: Notification-12 schemaLocation edits > > > Hi, > > There is an IANA XML Registry: > http://www.iana.org/assignments/xml-registry-index.html > > I looked at all 47 of the XSDs in the IANA XML registry: > http://www.iana.org/assignments/xml-registry/schema.html > > There is a clear practice of using schemaLocation attributes > for other XSDs in the registry, which is exactly what > the Notifications XSD is doing, except with the wrong > kind of URL. > > First the data: > > Many XSDs do not have any elements. > > Most XSDs that have an element, like these, do not > have a targetNamespace attribute in the element: > > http://www.iana.org/assignments/xml-registry/schema/contact-1.0.xsd > http://www.iana.org/assignments/xml-registry/schema/dchk1.xsd > http://www.iana.org/assignments/xml-registry/schema/domain-1.0.xsd > http://www.iana.org/assignments/xml-registry/schema/epp-1.0.xsd > http://www.iana.org/assignments/xml-registry/schema/ereg1.xsd > http://www.iana.org/assignments/xml-registry/schema/host-1.0.xsd > > Some (including netconf) have the following import, which is one > of the corner-case XSDs that causes lots of WEB traffic: > > schemaLocation="http://www.w3.org/2001/03/xml.xsd" /> > > I think best current practice is not to have this import in XSDs > anymore, but I'm not sure. > > Some XSDs, like these, have a targetNamespace attribute > in an element: > > http://www.iana.org/assignments/xml-registry/schema/enum-token-1.0.xsd > http://www.iana.org/assignments/xml-registry/schema/e164val-1.0.xsd > http://www.iana.org/assignments/xml-registry/schema/e164valex-1.1.xsd > http://www.iana.org/assignments/xml-registry/schema/pidf/timed-status.xsd These schemaLocation attributes are all relative URLs for other XSDs in the same directory (a few elements do the same thing). It seems clear that the Notifications XSD should use a relative URL instead of no schemaLocation at all. Here are the edits: -------------------------------------- notification-12, page 18: OLD: NEW: -------------------------------------- notification-12, page 24: OLD: NEW: -------------------------------------- Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 22 10:18:16 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4093028C4C1; Tue, 22 Apr 2008 10:18:16 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 456F128C4BA for ; Tue, 22 Apr 2008 10:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IER7pPyrGHHL for ; Tue, 22 Apr 2008 10:18:07 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 79E3828C4CE for ; Tue, 22 Apr 2008 10:16:24 -0700 (PDT) Received: (qmail 59981 invoked from network); 22 Apr 2008 17:15:55 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 22 Apr 2008 17:15:55 -0000 From: "Bert Wijnen - IETF" To: "Andy Bierman" , "David B Harrington" Date: Tue, 22 Apr 2008 19:15:57 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <480E0E51.8090001@andybierman.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Importance: Normal Cc: netconf@ietf.org Subject: Re: [Netconf] Notification-12 schemaLocation edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Yep... and I believe this is what the IESG wants us to do based on the DISCUSS we have seen. Bert Wijnen > -----Oorspronkelijk bericht----- > Van: Andy Bierman [mailto:ietf@andybierman.com] > Verzonden: dinsdag 22 april 2008 18:12 > Aan: David B Harrington > CC: 'Bert Wijnen - IETF'; netconf@ietf.org > Onderwerp: Notification-12 schemaLocation edits > > > Hi, > > There is an IANA XML Registry: > http://www.iana.org/assignments/xml-registry-index.html > > I looked at all 47 of the XSDs in the IANA XML registry: > http://www.iana.org/assignments/xml-registry/schema.html > > There is a clear practice of using schemaLocation attributes > for other XSDs in the registry, which is exactly what > the Notifications XSD is doing, except with the wrong > kind of URL. > > First the data: > > Many XSDs do not have any elements. > > Most XSDs that have an element, like these, do not > have a targetNamespace attribute in the element: > > http://www.iana.org/assignments/xml-registry/schema/contact-1.0.xsd > http://www.iana.org/assignments/xml-registry/schema/dchk1.xsd > http://www.iana.org/assignments/xml-registry/schema/domain-1.0.xsd > http://www.iana.org/assignments/xml-registry/schema/epp-1.0.xsd > http://www.iana.org/assignments/xml-registry/schema/ereg1.xsd > http://www.iana.org/assignments/xml-registry/schema/host-1.0.xsd > > Some (including netconf) have the following import, which is one > of the corner-case XSDs that causes lots of WEB traffic: > > schemaLocation="http://www.w3.org/2001/03/xml.xsd" /> > > I think best current practice is not to have this import in XSDs > anymore, but I'm not sure. > > Some XSDs, like these, have a targetNamespace attribute > in an element: > > http://www.iana.org/assignments/xml-registry/schema/enum-token-1.0.xsd > http://www.iana.org/assignments/xml-registry/schema/e164val-1.0.xsd > http://www.iana.org/assignments/xml-registry/schema/e164valex-1.1.xsd > http://www.iana.org/assignments/xml-registry/schema/pidf/timed-status.xsd These schemaLocation attributes are all relative URLs for other XSDs in the same directory (a few elements do the same thing). It seems clear that the Notifications XSD should use a relative URL instead of no schemaLocation at all. Here are the edits: -------------------------------------- notification-12, page 18: OLD: NEW: -------------------------------------- notification-12, page 24: OLD: NEW: -------------------------------------- Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 22 14:39:45 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623403A6D6A; Tue, 22 Apr 2008 14:39:45 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97C9C3A6E5E for ; Tue, 22 Apr 2008 14:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.622 X-Spam-Level: X-Spam-Status: No, score=-0.622 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z06CCur+nSfK for ; Tue, 22 Apr 2008 14:39:42 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id 2AACE3A6D6A for ; Tue, 22 Apr 2008 14:39:42 -0700 (PDT) Received: (qmail 79590 invoked from network); 22 Apr 2008 21:39:48 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.98.29 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 22 Apr 2008 21:39:46 -0000 X-YMail-OSG: 8YnHZ0IVM1lAHrHr.09VSccLKj9uqxxQB4ukvXn2NzSuWsGGOpHsbB7ifbwa6gSesSaTebMcepQscbUyq4vY4niQXCRgccBf3m.inghxaPtuvYw_qn8ArXsqLZk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <480E5B21.1040403@andybierman.com> Date: Tue, 22 Apr 2008 14:39:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Bert Wijnen - IETF References: In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] Holding Notifications Document (was: RE: Netconf Notification: Issues 22: Import Statements) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Bert Wijnen - IETF wrote: > Be my guest and go find the "right people" to setup and maintain > such a web site. If you want me to hold the document hostage till > that is done, then fine.... I will give in to that. > I don't think the IETF needs to spend any cycles on this. The IESG-accepted approach of just listing the filename in the schemaLocation is good enough. Andy > My experience in this space tells me we will be at least one year > further (if we ever get it done). > At that time, there will be new IESG members, new IAB members, and > the doc (since it has been out of sight for a year or more) will > get re-scrutinized, and some IESG or IAB member (or one of their > directorate members (of whom we have plenty these days) will find > another issue that needs to be resolved... and on and on and on... > > I don't think it is my task as document shepherd to try and entertain > all sorts of (in my view minor) issues that will delay the document > forever. I agree that being able to IMPORT is goodness. But if we > loose that (like all current schema definitions in IETF do not > have it), is that making the document fatally flawed? I don't think > so. So let us go ahead and accept the comment from IESG/IANA and > get the docuemnt approved. > > Those who have the enery to go fight for From netconf-bounces@ietf.org Tue Apr 22 14:39:45 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623403A6D6A; Tue, 22 Apr 2008 14:39:45 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97C9C3A6E5E for ; Tue, 22 Apr 2008 14:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.622 X-Spam-Level: X-Spam-Status: No, score=-0.622 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z06CCur+nSfK for ; Tue, 22 Apr 2008 14:39:42 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id 2AACE3A6D6A for ; Tue, 22 Apr 2008 14:39:42 -0700 (PDT) Received: (qmail 79590 invoked from network); 22 Apr 2008 21:39:48 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.127.98.29 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 22 Apr 2008 21:39:46 -0000 X-YMail-OSG: 8YnHZ0IVM1lAHrHr.09VSccLKj9uqxxQB4ukvXn2NzSuWsGGOpHsbB7ifbwa6gSesSaTebMcepQscbUyq4vY4niQXCRgccBf3m.inghxaPtuvYw_qn8ArXsqLZk- X-Yahoo-Newman-Property: ymail-3 Message-ID: <480E5B21.1040403@andybierman.com> Date: Tue, 22 Apr 2008 14:39:45 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Bert Wijnen - IETF References: In-Reply-To: Cc: netconf@ietf.org Subject: Re: [Netconf] Holding Notifications Document (was: RE: Netconf Notification: Issues 22: Import Statements) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Bert Wijnen - IETF wrote: > Be my guest and go find the "right people" to setup and maintain > such a web site. If you want me to hold the document hostage till > that is done, then fine.... I will give in to that. > I don't think the IETF needs to spend any cycles on this. The IESG-accepted approach of just listing the filename in the schemaLocation is good enough. Andy > My experience in this space tells me we will be at least one year > further (if we ever get it done). > At that time, there will be new IESG members, new IAB members, and > the doc (since it has been out of sight for a year or more) will > get re-scrutinized, and some IESG or IAB member (or one of their > directorate members (of whom we have plenty these days) will find > another issue that needs to be resolved... and on and on and on... > > I don't think it is my task as document shepherd to try and entertain > all sorts of (in my view minor) issues that will delay the document > forever. I agree that being able to IMPORT is goodness. But if we > loose that (like all current schema definitions in IETF do not > have it), is that making the document fatally flawed? I don't think > so. So let us go ahead and accept the comment from IESG/IANA and > get the docuemnt approved. > > Those who have the enery to go figha repository that can be > referenced/used in an IMPORT Statement can then go and fight that > battle. I might even participate... but I prefer not to hold up the > document. > > At the other hand... we'll do whatever seems to be consensus of the > WG. Untill I see more than a few people speak up, I do not see a > reason to start this long process, beginning with a WGLC type > action. > > Bert Wijnen > >> -----Oorspronkelijk bericht----- >> Van: David B Harrington [mailto:dbharrington@comcast.net] >> Verzonden: dinsdag 22 april 2008 15:46 >> Aan: 'Bert Wijnen - IETF'; 'Andy Bierman' >> CC: netconf@ietf.org >> Onderwerp: RE: Holding Notifications Document (was: RE: [Netconf] >> Netconf Notification: Issues 22: Import Statements) >> >> >> Hi, >> >> Is this a WGLC on this document? >> The subject line doesn't say so. >> >> The subject line is about the issue of a stable reference to support >> imports, so I think the discussion of whether we can get a stable >> archive to reference is part of the issue mentioned in the subject >> line. I suggest that rather than grouse about it, we should (very >> quickly) determine whose responsibility it would be to host such an >> archive, and determine from those responsible whether an archive will >> be set up. >> >> I spoke up because I think expecting IANA to host such a repository is >> asking the wrong organization to do this. If we want the problem >> solved, we should talk to the right people. >> >> If the goal of the WG is to deliver solutions of good technical >> quality to help the Internet run better, we might want to try to solve >> this (mainly) engineering problem to produce a solution that will >> improve the situation compared to the difficulty of finding MIB >> modules. Our community probably has the most long-running problem >> caused by the lack of such a repository, and we should make it clear >> to those responsible that this is a real problem we need solved. >> >> If the goal is to make the document shepherd happy that we make >> immediate progress, then we probably want to eliminate the >> schemaLocation and let people hunt around to find the schema wherever >> google sends them. >> >> I have no desire to see a loooong discussion either, but neither do I >> want to see us produce a poor quality solution to satisfy a petulant >> document shepherd. >> >> I think the solution is somewhere in between. I think we should, to >> resolve this issue, contact the right people about the real need for >> such a stable archive in the future, AND, to make document progress, >> either use a URN or remove the schemaLocation. To deal only with the >> document is to **not resolve** the issue but to ignore it. >> >> >> dbh >> >>> -----Original Message----- >>> From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] >>> Sent: Tuesday, April 22, 2008 5:28 AM >>> To: Andy Bierman; David B Harrington >>> Cc: netconf@ietf.org >>> Subject: Holding Notifications Document (was: RE: [Netconf] >>> Netconf Notification: Issues 22: Import Statements) >>> >>> See... this seems to be the first step in a path of loooooong delay. >>> We have (in about 1 day) shifted our dicussion about our own >>> WG document into a discussion about the generic issue of storing >>> (and giving access) to extracted data from RFCs. >>> >>> PLEASE... if you want to have this generic discussion, then >>> relabel the subject line (so I can ignore it). As document shepherd, >>> I am NOT interested in that type of discussion. >>> >>> If you want the document to be hold up for this, then PLEASE do not >>> discuss this in detail, but just post one short message to the WG >>> list with subject "Holding Notifications Document". >>> >>> If I see consensus forming to do that, then I can hand back my task >>> as "document shepherd" and give the document back to the WG for >>> further year-long discussions about this topic. >>> >>> Bert Wijnen >>> Speaking as document shepherd >>> >>>> -----Oorspronkelijk bericht----- >>>> Van: netconf-bounces@ietf.org >>> [mailto:netconf-bounces@ietf.org]Namens >>>> Andy Bierman >>>> Vert for a repository that can be > referenced/used in an IMPORT Statement can then go and fight that > battle. I might even participate... but I prefer not to hold up the > document. > > At the other hand... we'll do whatever seems to be consensus of the > WG. Untill I see more than a few people speak up, I do not see a > reason to start this long process, beginning with a WGLC type > action. > > Bert Wijnen > >> -----Oorspronkelijk bericht----- >> Van: David B Harrington [mailto:dbharrington@comcast.net] >> Verzonden: dinsdag 22 april 2008 15:46 >> Aan: 'Bert Wijnen - IETF'; 'Andy Bierman' >> CC: netconf@ietf.org >> Onderwerp: RE: Holding Notifications Document (was: RE: [Netconf] >> Netconf Notification: Issues 22: Import Statements) >> >> >> Hi, >> >> Is this a WGLC on this document? >> The subject line doesn't say so. >> >> The subject line is about the issue of a stable reference to support >> imports, so I think the discussion of whether we can get a stable >> archive to reference is part of the issue mentioned in the subject >> line. I suggest that rather than grouse about it, we should (very >> quickly) determine whose responsibility it would be to host such an >> archive, and determine from those responsible whether an archive will >> be set up. >> >> I spoke up because I think expecting IANA to host such a repository is >> asking the wrong organization to do this. If we want the problem >> solved, we should talk to the right people. >> >> If the goal of the WG is to deliver solutions of good technical >> quality to help the Internet run better, we might want to try to solve >> this (mainly) engineering problem to produce a solution that will >> improve the situation compared to the difficulty of finding MIB >> modules. Our community probably has the most long-running problem >> caused by the lack of such a repository, and we should make it clear >> to those responsible that this is a real problem we need solved. >> >> If the goal is to make the document shepherd happy that we make >> immediate progress, then we probably want to eliminate the >> schemaLocation and let people hunt around to find the schema wherever >> google sends them. >> >> I have no desire to see a loooong discussion either, but neither do I >> want to see us produce a poor quality solution to satisfy a petulant >> document shepherd. >> >> I think the solution is somewhere in between. I think we should, to >> resolve this issue, contact the right people about the real need for >> such a stable archive in the future, AND, to make document progress, >> either use a URN or remove the schemaLocation. To deal only with the >> document is to **not resolve** the issue but to ignore it. >> >> >> dbh >> >>> -----Original Message----- >>> From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] >>> Sent: Tuesday, April 22, 2008 5:28 AM >>> To: Andy Bierman; David B Harrington >>> Cc: netconf@ietf.org >>> Subject: Holding Notifications Document (was: RE: [Netconf] >>> Netconf Notification: Issues 22: Import Statements) >>> >>> See... this seems to be the first step in a path of loooooong delay. >>> We have (in about 1 day) shifted our dicussion about our own >>> WG document into a discussion about the generic issue of storing >>> (and giving access) to extracted data from RFCs. >>> >>> PLEASE... if you want to have this generic discussion, then >>> relabel the subject line (so I can ignore it). As document shepherd, >>> I am NOT interested in that type of discussion. >>> >>> If you want the document to be hold up for this, then PLEASE do not >>> discuss this in detail, but just post one short message to the WG >>> list with subject "Holding Notifications Document". >>> >>> If I see consensus forming to do that, then I can hand back my task >>> as "document shepherd" and give the document back to the WG for >>> further year-long discussions about this topic. >>> >>> Bert Wijnen >>> Speaking as document shepherd >>> >>>> -----Oorspronkelijk bericht----- >>>> Van: netconf-bounces@ietf.org >>> [mailto:netconf-bounces@ietf.org]Namens >>>> Andy Bierman >>zonden: dinsdag 22 april 2008 5:55 >>>> Aan: David B Harrington >>>> CC: netconf@ietf.org >>>> Onderwerp: Re: [Netconf] Netconf Notification: Issues 22: Import >>>> Statements >>>> >>>> >>>> David B Harrington wrote: >>>>> >>>>>> I suppose there is a slippery slope between being a standards >>>>>> archive and >>>>>> becoming part of the application infrastructure. >>>>> There is a slippery slope between being a numnbering >>> authority (IANA) >>>>> and being a standards archive (ala the RFC series) that >>> becomes part >>>>> of the application infrastructure. >>>>> >>>>>> Perhaps a never-ending list of arbitrarily named text files >>>>> (RFCnnnn) >>>>>> was sufficient in previous decades, but it isn't enough >> anymore. >>>>>> In order to build a meaningful standards-based CM system, the >>>>>> IETF standards track YANG modules, XSD and DSDL files should be >>>>>> accessible online. If the IETF does not want to take on any >>>>>> more responsibility than a document archive (understandable), >>>>>> then other sites will host the data modules, in an ad-hoc, >>>>>> non-standard manner. Perhaps applications will guess the >>>>>> schemaLocation by trying free databases, ala CDDB. >>>>> I think it would benefit the IETF community to have >>> rfc-editor.org or >>>>> ietf.org (not iana.org) host an archive for standard data >> models, >>>>> including MIB modules. But there has to be a concern that the >>>>> normative document (the RFC) and the extracted schema >>> could differ. >>>>> There are a number of issues that would need to be addressed, as >>>>> Juergen points out. >>>> >>>> Well, IANA extracts XSDs from RFCs are stores them in the >>>> http://www.iana.org/assignments/xml-registry/schema/ directory. >>>> >>>> I suppose there is some valid reason why IANA needs to maintain >>>> these online files, yet not want them to be found via an >>>> clause. >>>> >>>> Whether they differ from the RFC or not, these XSDs are >>> being extracted >>>> and stored. Perhaps IANA should stop this practice. You can >> carry >>>> this logic right on through -- it seems pointless for IANA >>> to extract >>>> and store any information at all -- people should just hunt >>> through RFCs >>>> if they want to find any Internet 'data'. Maybe IANA >>> should never extract >>>> any data from any published document, since this is redundant and >>>> wastes precious iana.org bandwidth. >>>> >>>> >>>> >>>> Andy >>>> >>>>> I suggest this be raised to the IAB, who, if I understand >>> correctly, >>>>> have the job over overseeing the contracts with the RFC Editor >>>>> function to meet IETF needs (and I think might also >>> control contracts >>>>> with the provider of ietf.org servers). >>>>> >>>>>> (I bet the extra bandwidth used up by NETCONF/YANG file >> retrieval >>>>>> is less than the email bandwidth the IETF uses up worrying >> about >>>>>> NETCONF/YANG file retrieval. ;-) >>>>> I am pretty sure the bandwidth and storage requirements for >>>>> IETF-standard netconf schema would be dwarfed by the >>> requirements for >>>>> bandwidth and storage of emails discussing the size of cookies >>>>> provided during IETF meetings. >>>>> >>>>> David Harrington >>>>> dbharrington@comcast.net >>>>> ietfdbh@comcast.net >>>>> dharrington@huawei.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>>> >>> >> >> > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf >> Verzonden: dinsdag 22 april 2008 5:55 >>>> Aan: David B Harrington >>>> CC: netconf@ietf.org >>>> Onderwerp: Re: [Netconf] Netconf Notification: Issues 22: Import >>>> Statements >>>> >>>> >>>> David B Harrington wrote: >>>>> >>>>>> I suppose there is a slippery slope between being a standards >>>>>> archive and >>>>>> becoming part of the application infrastructure. >>>>> There is a slippery slope between being a numnbering >>> authority (IANA) >>>>> and being a standards archive (ala the RFC series) that >>> becomes part >>>>> of the application infrastructure. >>>>> >>>>>> Perhaps a never-ending list of arbitrarily named text files >>>>> (RFCnnnn) >>>>>> was sufficient in previous decades, but it isn't enough >> anymore. >>>>>> In order to build a meaningful standards-based CM system, the >>>>>> IETF standards track YANG modules, XSD and DSDL files should be >>>>>> accessible online. If the IETF does not want to take on any >>>>>> more responsibility than a document archive (understandable), >>>>>> then other sites will host the data modules, in an ad-hoc, >>>>>> non-standard manner. Perhaps applications will guess the >>>>>> schemaLocation by trying free databases, ala CDDB. >>>>> I think it would benefit the IETF community to have >>> rfc-editor.org or >>>>> ietf.org (not iana.org) host an archive for standard data >> models, >>>>> including MIB modules. But there has to be a concern that the >>>>> normative document (the RFC) and the extracted schema >>> could differ. >>>>> There are a number of issues that would need to be addressed, as >>>>> Juergen points out. >>>> >>>> Well, IANA extracts XSDs from RFCs are stores them in the >>>> http://www.iana.org/assignments/xml-registry/schema/ directory. >>>> >>>> I suppose there is some valid reason why IANA needs to maintain >>>> these online files, yet not want them to be found via an >>>> clause. >>>> >>>> Whether they differ from the RFC or not, these XSDs are >>> being extracted >>>> and stored. Perhaps IANA should stop this practice. You can >> carry >>>> this logic right on through -- it seems pointless for IANA >>> to extract >>>> and store any information at all -- people should just hunt >>> through RFCs >>>> if they want to find any Internet 'data'. Maybe IANA >>> should never extract >>>> any data from any published document, since this is redundant and >>>> wastes precious iana.org bandwidth. >>>> >>>> >>>> >>>> Andy >>>> >>>>> I suggest this be raised to the IAB, who, if I understand >>> correctly, >>>>> have the job over overseeing the contracts with the RFC Editor >>>>> function to meet IETF needs (and I think might also >>> control contracts >>>>> with the provider of ietf.org servers). >>>>> >>>>>> (I bet the extra bandwidth used up by NETCONF/YANG file >> retrieval >>>>>> is less than the email bandwidth the IETF uses up worrying >> about >>>>>> NETCONF/YANG file retrieval. ;-) >>>>> I am pretty sure the bandwidth and storage requirements for >>>>> IETF-standard netconf schema would be dwarfed by the >>> requirements for >>>>> bandwidth and storage of emails discussing the size of cookies >>>>> provided during IETF meetings. >>>>> >>>>> David Harrington >>>>> dbharrington@comcast.net >>>>> ietfdbh@comcast.net >>>>> dharrington@huawei.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>>> >>> >> >> > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 23 11:42:32 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B7D3A6BA5; Wed, 23 Apr 2008 11:42:32 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEDC33A6DF3 for ; Wed, 23 Apr 2008 11:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79im6WmkFb7p for ; Wed, 23 Apr 2008 11:42:22 -0700 (PDT) Received: from zrtps0kp.us.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 8E7D83A6D88 for ; Wed, 23 Apr 2008 11:41:15 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3NIfIj12609 for ; Wed, 23 Apr 2008 18:41:18 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Apr 2008 14:41:02 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Notifications: Proposed Edits to Resolve Discuss Issues Thread-Index: AcilcZR/jISHmqM8QyGNyxNHmQZSAA== From: "Sharon Chisholm" To: Subject: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org 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 netconf-bounces@ietf.org Wed Apr 23 11:42:32 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B7D3A6BA5; Wed, 23 Apr 2008 11:42:32 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEDC33A6DF3 for ; Wed, 23 Apr 2008 11:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79im6WmkFb7p for ; Wed, 23 Apr 2008 11:42:22 -0700 (PDT) Received: from zrtps0kp.us.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 8E7D83A6D88 for ; Wed, 23 Apr 2008 11:41:15 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3NIfIj12609 for ; Wed, 23 Apr 2008 18:41:18 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Apr 2008 14:41:02 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Notifications: Proposed Edits to Resolve Discuss Issues Thread-Index: AcilcZR/jISHmqM8QyGNyxNHmQZSAA== From: "Sharon Chisholm" To: Subject: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org 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 operations. With The NETCONF server will then accept 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 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 has been specified, 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 notification is sent to indicate that all of the replay notifications have been sent. When a has been specified, 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 notification is sent to indicate that all of the replay notifications have been sent. With A 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 and 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 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 operation can be considered like a deferred , and the content that different users can access may vary. This different access is reflected in the that different users are able to subscribe to. M. Replace With 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 operations. With The NETCONF server will then accept 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 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 has been specified, 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 notification is sent to indicate that all of the replay notifications have been sent. When a has been specified, 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 notification is sent to indicate that all of the replay notifications have been sent. With A 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 and 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 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 operation can be considered like a deferred , and the content that different users can access may vary. This different access is reflected in the that different users are able to subscribe to. M. Replace With Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailst Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 23 12:05:12 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B48243A6ABC; Wed, 23 Apr 2008 12:05:11 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E4E73A6DAD for ; Wed, 23 Apr 2008 12:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rF9IwWP2pR-w for ; Wed, 23 Apr 2008 12:05:02 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 3B94C3A6F63 for ; Wed, 23 Apr 2008 12:04:09 -0700 (PDT) Received: (qmail 67898 invoked from network); 23 Apr 2008 19:04:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.125.157.124 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 23 Apr 2008 19:04:13 -0000 X-YMail-OSG: SLqlwLkVM1l.W46weQYoC_yi5apM8ZDrWjF9F8bPLZYlijWq3lwC7S0n6K7HtiOLaqg.XZHYrrN8HhDQdK9y0UtUH7P9K4fIvzazgA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <480F882B.5090700@andybierman.com> Date: Wed, 23 Apr 2008 12:04:11 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > 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. > This list looks fine, except M should list 3 imports (missing the 1 in the 2nd XSD). Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 23 12:05:12 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B48243A6ABC; Wed, 23 Apr 2008 12:05:11 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E4E73A6DAD for ; Wed, 23 Apr 2008 12:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rF9IwWP2pR-w for ; Wed, 23 Apr 2008 12:05:02 -0700 (PDT) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 3B94C3A6F63 for ; Wed, 23 Apr 2008 12:04:09 -0700 (PDT) Received: (qmail 67898 invoked from network); 23 Apr 2008 19:04:14 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.125.157.124 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 23 Apr 2008 19:04:13 -0000 X-YMail-OSG: SLqlwLkVM1l.W46weQYoC_yi5apM8ZDrWjF9F8bPLZYlijWq3lwC7S0n6K7HtiOLaqg.XZHYrrN8HhDQdK9y0UtUH7P9K4fIvzazgA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <480F882B.5090700@andybierman.com> Date: Wed, 23 Apr 2008 12:04:11 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Sharon Chisholm wrote: > 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. > This list looks fine, except M should list 3 imports (missing the 1 in the 2nd XSD). Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 23 12:48:26 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 405053A6F7D; Wed, 23 Apr 2008 12:48:26 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1733A6F4D for ; Wed, 23 Apr 2008 12:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVWf0-fLmO5G for ; Wed, 23 Apr 2008 12:48:24 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 8037A28C3CC for ; Wed, 23 Apr 2008 12:47:07 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 973941B80C4; Wed, 23 Apr 2008 21:47:10 +0200 (CEST) Date: Wed, 23 Apr 2008 21:46:39 +0200 (CEST) Message-Id: <20080423.214639.161115586.mbj@tail-f.com> To: schishol@nortel.com From: Martin Bjorklund In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, "Sharon Chisholm" wrote: > 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. 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 23 12:48:26 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 405053A6F7D; Wed, 23 Apr 2008 12:48:26 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1733A6F4D for ; Wed, 23 Apr 2008 12:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVWf0-fLmO5G for ; Wed, 23 Apr 2008 12:48:24 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 8037A28C3CC for ; Wed, 23 Apr 2008 12:47:07 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id 973941B80C4; Wed, 23 Apr 2008 21:47:10 +0200 (CEST) Date: Wed, 23 Apr 2008 21:46:39 +0200 (CEST) Message-Id: <20080423.214639.161115586.mbj@tail-f.com> To: schishol@nortel.com From: Martin Bjorklund In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, "Sharon Chisholm" wrote: > 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. 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 23 20:04:04 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E5B13A69BA; Wed, 23 Apr 2008 20:04:04 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 914B23A67D2 for ; Wed, 23 Apr 2008 20:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koEMMjsujeCn for ; Wed, 23 Apr 2008 20:04:01 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id A8E153A69EA for ; Wed, 23 Apr 2008 20:04:01 -0700 (PDT) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id HBLU1Z0040S2fkCA10Pw00; Thu, 24 Apr 2008 03:04:07 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id HF3x1Z00E4HwxpC8V00000; Thu, 24 Apr 2008 03:04:03 +0000 X-Authority-Analysis: v=1.0 c=1 a=HFp184_-JLwA:10 a=R8LCDrCiFMwA:10 a=wZLlmP97EEt8S-VrMY0A:9 a=zpw8c_b8BNfFTvbSFw8A:7 a=vKeHxN3KcW9zWYGxZ_FGpIGC6v8A:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Sharon Chisholm'" , References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> Date: Wed, 23 Apr 2008 23:03:57 -0400 Message-ID: <019501c8a5b7$d76c0d00$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcilcZR/jISHmqM8QyGNyxNHmQZSAAARDK6g Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > D. In Section 7: > >> that it is viewed only by authorized users. If a user does not > have > >> permission to view content via other NETCONF operations, it must > not > >> 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 or a configuration? you might want to change "it" to "he/she", or "the user" > G. In section 3.3.2 > Replace > A notification is sent to indicate that all of the > replay notifications have been sent. > With > A notification is sent to indicate that all of the > replay notifications have been sent and must not be sent for any > other reason. Is the replay cache session-specific? Could another session request a replay of the same information? > 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. I don't understand this new sentence. I would hope the illustration would not preclude an implementation; that would seem counter-productive. > 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. This is still part of the design, right? Is this specified clearly someplace? David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 23 20:04:04 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E5B13A69BA; Wed, 23 Apr 2008 20:04:04 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 914B23A67D2 for ; Wed, 23 Apr 2008 20:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koEMMjsujeCn for ; Wed, 23 Apr 2008 20:04:01 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id A8E153A69EA for ; Wed, 23 Apr 2008 20:04:01 -0700 (PDT) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id HBLU1Z0040S2fkCA10Pw00; Thu, 24 Apr 2008 03:04:07 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id HF3x1Z00E4HwxpC8V00000; Thu, 24 Apr 2008 03:04:03 +0000 X-Authority-Analysis: v=1.0 c=1 a=HFp184_-JLwA:10 a=R8LCDrCiFMwA:10 a=wZLlmP97EEt8S-VrMY0A:9 a=zpw8c_b8BNfFTvbSFw8A:7 a=vKeHxN3KcW9zWYGxZ_FGpIGC6v8A:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Sharon Chisholm'" , References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> Date: Wed, 23 Apr 2008 23:03:57 -0400 Message-ID: <019501c8a5b7$d76c0d00$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcilcZR/jISHmqM8QyGNyxNHmQZSAAARDK6g Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > D. In Section 7: > >> that it is viewed only by authorized users. If a user does not > have > >> permission to view content via other NETCONF operations, it must > not > >> 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 or a configuration? you might want to change "it" to "he/she", or "the user" > G. In section 3.3.2 > Replace > A notification is sent to indicate that all of the > replay notifications have been sent. > With > A notification is sent to indicate that all of the > replay notifications have been sent and must not be sent for any > other reason. Is the replay cache session-specific? Could another session request a replay of the same information? > 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. I don't understand this new sentence. I would hope the illustration would not preclude an implementation; that would seem counter-productive. > 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. This is still part of the design, right? Is this specified clearly someplace? David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 23 20:10:39 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB5653A69EA; Wed, 23 Apr 2008 20:10:39 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E6F03A69EA for ; Wed, 23 Apr 2008 20:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qreAyyPF4lOK for ; Wed, 23 Apr 2008 20:10:36 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 38BF83A69BD for ; Wed, 23 Apr 2008 20:10:36 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id HExU1Z0071GXsucA901T00; Thu, 24 Apr 2008 03:10:32 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id HFAP1Z00J4HwxpC8T00000; Thu, 24 Apr 2008 03:10:29 +0000 X-Authority-Analysis: v=1.0 c=1 a=HFp184_-JLwA:10 a=R8LCDrCiFMwA:10 a=f95TZ2Pi5pUFFvOb6s4A:9 a=ji3-GaIu3EZlYCnPi0MA:7 a=koAd42zcAbZa2BR3sqlFuusTqToA:4 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'David B Harrington'" , "'Sharon Chisholm'" , References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> Date: Wed, 23 Apr 2008 23:10:23 -0400 Message-ID: <019601c8a5b8$bd8b7d20$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcilcZR/jISHmqM8QyGNyxNHmQZSAAARDK6gAACUNcA= Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, a little bit further thought on this one: > > D. In Section 7: > > >> that it is viewed only by authorized users. If a user does not > > have > > >> permission to view content via other NETCONF > operations, it must > > not > > >> 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 or 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 netconf-bounces@ietf.org Wed Apr 23 20:10:39 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB5653A69EA; Wed, 23 Apr 2008 20:10:39 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E6F03A69EA for ; Wed, 23 Apr 2008 20:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qreAyyPF4lOK for ; Wed, 23 Apr 2008 20:10:36 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 38BF83A69BD for ; Wed, 23 Apr 2008 20:10:36 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id HExU1Z0071GXsucA901T00; Thu, 24 Apr 2008 03:10:32 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id HFAP1Z00J4HwxpC8T00000; Thu, 24 Apr 2008 03:10:29 +0000 X-Authority-Analysis: v=1.0 c=1 a=HFp184_-JLwA:10 a=R8LCDrCiFMwA:10 a=f95TZ2Pi5pUFFvOb6s4A:9 a=ji3-GaIu3EZlYCnPi0MA:7 a=koAd42zcAbZa2BR3sqlFuusTqToA:4 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'David B Harrington'" , "'Sharon Chisholm'" , References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> Date: Wed, 23 Apr 2008 23:10:23 -0400 Message-ID: <019601c8a5b8$bd8b7d20$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcilcZR/jISHmqM8QyGNyxNHmQZSAAARDK6gAACUNcA= Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, a little bit further thought on this one: > > D. In Section 7: > > >> that it is viewed only by authorized users. If a user does not > > have > > >> permission to view content via other NETCONF > operations, it must > > not > > >> 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 or 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@ietf.org f.org https://www.ietf.org/mailman/listinfo/netconf https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Apr 24 05:04:21 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55C13A6C1B; Thu, 24 Apr 2008 05:04:21 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 345BC3A6C2D for ; Thu, 24 Apr 2008 05:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zv1nndHVPq7L for ; Thu, 24 Apr 2008 05:04:15 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 249D13A6C0C for ; Thu, 24 Apr 2008 05:04:15 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m3OC3QI03966; Thu, 24 Apr 2008 12:03:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Apr 2008 08:04:16 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41435DDFA@zcarhxm2.corp.nortel.com> In-Reply-To: <20080423.214639.161115586.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues Thread-Index: AcilettIQcgvlvaFTpi3m/1bLD/6bQAiEsCQ References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> <20080423.214639.161115586.mbj@tail-f.com> From: "Sharon Chisholm" To: "Martin Bjorklund" Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org 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:mbj@tail-f.com] Sent: Wednesday, April 23, 2008 3:47 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues Hi, "Sharon Chisholm" wrote: > 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. 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Apr 24 05:04:21 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55C13A6C1B; Thu, 24 Apr 2008 05:04:21 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 345BC3A6C2D for ; Thu, 24 Apr 2008 05:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zv1nndHVPq7L for ; Thu, 24 Apr 2008 05:04:15 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 249D13A6C0C for ; Thu, 24 Apr 2008 05:04:15 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m3OC3QI03966; Thu, 24 Apr 2008 12:03:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Apr 2008 08:04:16 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41435DDFA@zcarhxm2.corp.nortel.com> In-Reply-To: <20080423.214639.161115586.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues Thread-Index: AcilettIQcgvlvaFTpi3m/1bLD/6bQAiEsCQ References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> <20080423.214639.161115586.mbj@tail-f.com> From: "Sharon Chisholm" To: "Martin Bjorklund" Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org 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:mbj@tail-f.com] Sent: Wednesday, April 23, 2008 3:47 PM To: Chisholm, Sharon (CAR:ZZ00) Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues Hi, "Sharon Chisholm" wrote: > 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. 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Apr 24 05:15:39 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D0133A6C32; Thu, 24 Apr 2008 05:15:39 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FF1028C0E4 for ; Thu, 24 Apr 2008 05:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjzYlImHXDOu for ; Thu, 24 Apr 2008 05:15:37 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 65F1C3A6C32 for ; Thu, 24 Apr 2008 05:15:37 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D099C000B; Thu, 24 Apr 2008 14:15:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YvMmIYN4-l8Z; Thu, 24 Apr 2008 14:15:37 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 32405C0002; Thu, 24 Apr 2008 14:15:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1EC50546A06; Thu, 24 Apr 2008 14:15:36 +0200 (CEST) Date: Thu, 24 Apr 2008 14:15:36 +0200 From: Juergen Schoenwaelder To: Sharon Chisholm Message-ID: <20080424121536.GA16507@elstar.local> Mail-Followup-To: Sharon Chisholm , Martin Bjorklund , netconf@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> <20080423.214639.161115586.mbj@tail-f.com> <713043CE8B8E1348AF3C546DBE02C1B41435DDFA@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41435DDFA@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Thu, Apr 24, 2008 at 08:04:16AM -0400, Sharon Chisholm wrote: > 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. 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 netconf-bounces@ietf.org Thu Apr 24 05:15:39 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D0133A6C32; Thu, 24 Apr 2008 05:15:39 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FF1028C0E4 for ; Thu, 24 Apr 2008 05:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjzYlImHXDOu for ; Thu, 24 Apr 2008 05:15:37 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 65F1C3A6C32 for ; Thu, 24 Apr 2008 05:15:37 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D099C000B; Thu, 24 Apr 2008 14:15:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YvMmIYN4-l8Z; Thu, 24 Apr 2008 14:15:37 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 32405C0002; Thu, 24 Apr 2008 14:15:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1EC50546A06; Thu, 24 Apr 2008 14:15:36 +0200 (CEST) Date: Thu, 24 Apr 2008 14:15:36 +0200 From: Juergen Schoenwaelder To: Sharon Chisholm Message-ID: <20080424121536.GA16507@elstar.local> Mail-Followup-To: Sharon Chisholm , Martin Bjorklund , netconf@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> <20080423.214639.161115586.mbj@tail-f.com> <713043CE8B8E1348AF3C546DBE02C1B41435DDFA@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41435DDFA@zcarhxm2.corp.nortel.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Thu, Apr 24, 2008 at 08:04:16AM -0400, Sharon Chisholm wrote: > 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. 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 _______________________________________________ Netconf mailing list Netconf@ietf.org 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Apr 24 06:35:40 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21C1E3A6AE9; Thu, 24 Apr 2008 06:35:40 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CABE93A67A2 for ; Thu, 24 Apr 2008 06:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DS8BSfhfHpCw for ; Thu, 24 Apr 2008 06:35:37 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 08D5B3A6CA7 for ; Thu, 24 Apr 2008 06:35:31 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Thu, 24 Apr 2008 06:35:35 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Apr 2008 06:35:02 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m3ODYwD64390; Thu, 24 Apr 2008 06:35:02 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m3ODXHFI056605; Thu, 24 Apr 2008 13:33:22 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200804241333.m3ODXHFI056605@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-reply-to: <20080424121536.GA16507@elstar.local> Date: Thu, 24 Apr 2008 09:33:17 -0400 From: Phil Shafer X-OriginalArrivalTime: 24 Apr 2008 13:35:02.0246 (UTC) FILETIME=[FF90D060:01C8A60F] Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder writes: >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 other hand a >timezone is not know, then a timezone it MUST NOT be included. 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Apr 24 06:35:40 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21C1E3A6AE9; Thu, 24 Apr 2008 06:35:40 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CABE93A67A2 for ; Thu, 24 Apr 2008 06:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DS8BSfhfHpCw for ; Thu, 24 Apr 2008 06:35:37 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 08D5B3A6CA7 for ; Thu, 24 Apr 2008 06:35:31 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Thu, 24 Apr 2008 06:35:35 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Apr 2008 06:35:02 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m3ODYwD64390; Thu, 24 Apr 2008 06:35:02 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m3ODXHFI056605; Thu, 24 Apr 2008 13:33:22 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200804241333.m3ODXHFI056605@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-reply-to: <20080424121536.GA16507@elstar.local> Date: Thu, 24 Apr 2008 09:33:17 -0400 From: Phil Shafer X-OriginalArrivalTime: 24 Apr 2008 13:35:02.0246 (UTC) FILETIME=[FF90D060:01C8A60F] Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder writes: >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 other hand a >timezone is not know, then a timezone it MUST NOT be included. 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Apr 24 08:55:15 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FDB128C219; Thu, 24 Apr 2008 08:55:15 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D063D28C211 for ; Thu, 24 Apr 2008 08:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2DiZMOhfFBy for ; Thu, 24 Apr 2008 08:55:13 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id A2C493A6C6E for ; Thu, 24 Apr 2008 08:55:12 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 47C3E1B81EB; Thu, 24 Apr 2008 17:55:17 +0200 (CEST) Message-ID: <4810AD65.7090708@tail-f.com> Date: Thu, 24 Apr 2008 17:55:17 +0200 From: Per Hedeland User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: Phil Shafer References: <200804241333.m3ODXHFI056605@idle.juniper.net> In-Reply-To: <200804241333.m3ODXHFI056605@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On 2008-04-24 15:33, Phil Shafer wrote: > Juergen Schoenwaelder writes: >> 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 other hand a >> timezone is not know, then a timezone it MUST NOT be included. > > 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. 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 netconf-bounces@ietf.org Thu Apr 24 08:55:15 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FDB128C219; Thu, 24 Apr 2008 08:55:15 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D063D28C211 for ; Thu, 24 Apr 2008 08:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2DiZMOhfFBy for ; Thu, 24 Apr 2008 08:55:13 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id A2C493A6C6E for ; Thu, 24 Apr 2008 08:55:12 -0700 (PDT) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 47C3E1B81EB; Thu, 24 Apr 2008 17:55:17 +0200 (CEST) Message-ID: <4810AD65.7090708@tail-f.com> Date: Thu, 24 Apr 2008 17:55:17 +0200 From: Per Hedeland User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: Phil Shafer References: <200804241333.m3ODXHFI056605@idle.juniper.net> In-Reply-To: <200804241333.m3ODXHFI056605@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On 2008-04-24 15:33, Phil Shafer wrote: > Juergen Schoenwaelder writes: >> 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 other hand a >> timezone is not know, then a timezone it MUST NOT be included. > > 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. 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Apr 24 10:13:43 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F3023A6A8C; Thu, 24 Apr 2008 10:13:43 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFBF63A6A8C for ; Thu, 24 Apr 2008 10:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.138 X-Spam-Level: X-Spam-Status: No, score=-6.138 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_05=-1.11, FM_ASCII_ART_SPACINGc=0.833, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTLPAlBvULch for ; Thu, 24 Apr 2008 10:13:36 -0700 (PDT) Received: from zrtps0kn.us.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 7B5F63A69E4 for ; Thu, 24 Apr 2008 10:13:35 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3OHDXD26857 for ; Thu, 24 Apr 2008 17:13:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8A62E.7F0483AA" Date: Thu, 24 Apr 2008 13:13:20 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4143A2275@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues Thread-Index: AcilcZR/jISHmqM8QyGNyxNHmQZSAAAvM0SQ References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A62E.7F0483AA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi Attached is the promised draft update. Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Chisholm, Sharon (CAR:ZZ00) Sent: Wednesday, April 23, 2008 2:41 PM To: netconf@ietf.org Subject: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues 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] IntFrom netconf-bounces@ietf.org Thu Apr 24 10:13:43 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F3023A6A8C; Thu, 24 Apr 2008 10:13:43 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFBF63A6A8C for ; Thu, 24 Apr 2008 10:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.138 X-Spam-Level: X-Spam-Status: No, score=-6.138 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_05=-1.11, FM_ASCII_ART_SPACINGc=0.833, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTLPAlBvULch for ; Thu, 24 Apr 2008 10:13:36 -0700 (PDT) Received: from zrtps0kn.us.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 7B5F63A69E4 for ; Thu, 24 Apr 2008 10:13:35 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3OHDXD26857 for ; Thu, 24 Apr 2008 17:13:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8A62E.7F0483AA" Date: Thu, 24 Apr 2008 13:13:20 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4143A2275@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues Thread-Index: AcilcZR/jISHmqM8QyGNyxNHmQZSAAAvM0SQ References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A62E.7F0483AA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi Attached is the promised draft update. Sharon -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Chisholm, Sharon (CAR:ZZ00) Sent: Wednesday, April 23, 2008 2:41 PM To: netconf@ietf.org Subject: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues 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] ernational 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).=20 Implementations must support time zones. C. In Section 3.6.1=20 >> parameter. A Filter only exist as a parameter to the subscription. > s/exist/exists/ D. In Section 7:=20 >> that it is viewed only by authorized users. If a user does not have >> 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=20 The NETCONF server will then accept operations. With The NETCONF server will then accept 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 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 has been specified, notification is the last notification sent on the subscription before it terminates and the NETCONF session returns to being a normal NETCONF session.=20 With A notification is sent to indicate that all of the replay notifications have been sent. When a has been specified, notification is the last notification sent on the subscription before it terminates and the NETCONF session returns to being a normal NETCONF session.=20 G. In section 3.3.2 Replace A notification is sent to indicate that all of the replay notifications have been sent. With A 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 and 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.=20 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 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 operation can be considered like a deferred , and the content that different users can 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).=20 Implementations must support time zones. C. In Section 3.6.1=20 >> parameter. A Filter only exist as a parameter to the subscription. > s/exist/exists/ D. In Section 7:=20 >> that it is viewed only by authorized users. If a user does not have >> 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=20 The NETCONF server will then accept operations. With The NETCONF server will then accept 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 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 has been specified, notification is the last notification sent on the subscription before it terminates and the NETCONF session returns to being a normal NETCONF session.=20 With A notification is sent to indicate that all of the replay notifications have been sent. When a has been specified, notification is the last notification sent on the subscription before it terminates and the NETCONF session returns to being a normal NETCONF session.=20 G. In section 3.3.2 Replace A notification is sent to indicate that all of the replay notifications have been sent. With A 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 and 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.=20 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 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 operation can be considered like a deferred , and the content that different useraccess may vary. This different access is reflected in the that different users are able to subscribe to.=20 M. Replace With Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------_=_NextPart_001_01C8A62E.7F0483AA Content-Type: text/html; name="pre_13_rfcdiff.pyht.htm" Content-Transfer-Encoding: base64 Content-Description: pre_13_rfcdiff.pyht.htm Content-Disposition: attachment; filename="pre_13_rfcdiff.pyht.htm" CjxodG1sPjxoZWFkPjx0aXRsZT53ZGlmZiBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9u LTEyLnR4dCBuZXRjb25mX2V2ZW50LnR4dDwvdGl0bGU+PC9oZWFkPjxib2R5Pgo8cHJlPgoKTmV0 d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFMuIENoaXNob2xtCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIE5vcnRlbApJbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBU cmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEguIFRyZXZpbm8KRXhwaXJlczogPHN0 cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5BdWd1c3QgMjgsPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25n Pjxmb250IGNvbG9yPSdncmVlbic+T2N0b2JlciAyNiw8L2ZvbnQ+PC9zdHJvbmc+IDIwMDggICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNjbwogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHN0cmlrZT48Zm9udCBj b2xvcj0ncmVkJz5GZWJydWFyeSAyNSw8L2ZvbnQ+PC9zdHJpa2U+CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c3Ryb25nPjxmb250IGNv bG9yPSdncmVlbic+QXByaWwgMjQsPC9mb250Pjwvc3Ryb25nPiAyMDA4CgogICAgICAgICAgICAg ICAgICAgICAgTkVUQ09ORiBFdmVudCBOb3RpZmljYXRpb25zCiAgICAgICAgICAgICAgICAgPHN0 cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5kcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLTEy LnR4dDwvZm9udD48L3N0cmlrZT4KICAgICAgICAgICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9y PSdncmVlbic+ZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi0xMy50eHQ8L2ZvbnQ+PC9z dHJvbmc+CgpTdGF0dXMgb2YgdGhpcyBNZW1vCgogICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJu ZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkKICAgYXBwbGljYWJsZSBw YXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMgYXdhcmUKICAg aGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9yIHNo ZSBiZWNvbWVzCiAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGgg U2VjdGlvbiA2IG9mIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1 bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBp dHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQKICAgb3RoZXIgZ3Jv dXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtCiAg IERyYWZ0cy4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZv ciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk LCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMg aW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRl cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgog ICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQK ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LgoKICAgVGhlIGxp c3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBh dAogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLgoKICAgVGhpcyBJbnRlcm5ldC1E cmFmdCB3aWxsIGV4cGlyZSBvbiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPkF1Z3VzdCAyOCw8 L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5PY3RvYmVyIDI2LDwv Zm9udD48L3N0cm9uZz4gMjAwOC4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoQykg VGhlIElFVEYgVHJ1c3QgKDIwMDgpLgoKQWJzdHJhYs can access may vary. This different access is reflected in the that different users are able to subscribe to.=20 M. Replace With Sharon Chisholm Nortel Ottawa, Ontario Canada _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------_=_NextPart_001_01C8A62E.7F0483AA Content-Type: text/html; name="pre_13_rfcdiff.pyht.htm" Content-Transfer-Encoding: base64 Content-Description: pre_13_rfcdiff.pyht.htm Content-Disposition: attachment; filename="pre_13_rfcdiff.pyht.htm" CjxodG1sPjxoZWFkPjx0aXRsZT53ZGlmZiBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9u LTEyLnR4dCBuZXRjb25mX2V2ZW50LnR4dDwvdGl0bGU+PC9oZWFkPjxib2R5Pgo8cHJlPgoKTmV0 d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFMuIENoaXNob2xtCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIE5vcnRlbApJbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBU cmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEguIFRyZXZpbm8KRXhwaXJlczogPHN0 cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5BdWd1c3QgMjgsPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25n Pjxmb250IGNvbG9yPSdncmVlbic+T2N0b2JlciAyNiw8L2ZvbnQ+PC9zdHJvbmc+IDIwMDggICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNjbwogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHN0cmlrZT48Zm9udCBj b2xvcj0ncmVkJz5GZWJydWFyeSAyNSw8L2ZvbnQ+PC9zdHJpa2U+CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c3Ryb25nPjxmb250IGNv bG9yPSdncmVlbic+QXByaWwgMjQsPC9mb250Pjwvc3Ryb25nPiAyMDA4CgogICAgICAgICAgICAg ICAgICAgICAgTkVUQ09ORiBFdmVudCBOb3RpZmljYXRpb25zCiAgICAgICAgICAgICAgICAgPHN0 cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5kcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLTEy LnR4dDwvZm9udD48L3N0cmlrZT4KICAgICAgICAgICAgICAgICA8c3Ryb25nPjxmb250IGNvbG9y PSdncmVlbic+ZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi0xMy50eHQ8L2ZvbnQ+PC9z dHJvbmc+CgpTdGF0dXMgb2YgdGhpcyBNZW1vCgogICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJu ZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkKICAgYXBwbGljYWJsZSBw YXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMgYXdhcmUKICAg aGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9yIHNo ZSBiZWNvbWVzCiAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGgg U2VjdGlvbiA2IG9mIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1 bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBp dHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQKICAgb3RoZXIgZ3Jv dXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtCiAg IERyYWZ0cy4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZv ciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2Vk LCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMg aW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRl cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgog ICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQK ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LgoKICAgVGhlIGxp c3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBh dAogICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLgoKICAgVGhpcyBJbnRlcm5ldC1E cmFmdCB3aWxsIGV4cGlyZSBvbiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPkF1Z3VzdCAyOCw8 L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5PY3RvYmVyIDI2LDwv Zm9udD48L3N0cm9uZz4gMjAwOC4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoQykg VGhlIElFVEYgVHJ1c3QgKDIwMDgpLgoKQWJ3QKCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5l cyBtZWNoYW5pc21zIHRoYXQgcHJvdmlkZSBhbiBhc3luY2hyb25vdXMgbWVzc2FnZQogICBub3Rp ZmljYXRpb24gZGVsaXZlcnkgc2VydmljZSBmb3IgdGhlIE5FVENPTkYgcHJvdG9jb2wuICBUaGlz IGlzIGFuCiAgIG9wdGlvbmFsIGNhcGFiaWxpdHkgYnVpbHQgb24gdG9wIG9mIHRoZSBiYXNlIE5F VENPTkYgZGVmaW5pdGlvbi4KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBjYXBhYmlsaXRp ZXMgYW5kIG9wZXJhdGlvbnMgbmVjZXNzYXJ5IHRvCiAgIHN1cHBvcnQgdGhpcyBzZXJ2aWNlLgoK VGFibGUgb2YgQ29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNAogICAgIDEuMS4gIERlZmluaXRpb24g b2YgVGVybXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQKICAgICAx LjIuICBNb3RpdmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICA1CiAgICAgMS4zLiAgRXZlbnQgTm90aWZpY2F0aW9ucyBpbiBORVRDT05GIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNgogICAyLiAgTm90aWZpY2F0aW9uLVJlbGF0ZWQgT3Bl cmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcKICAgICAyLjEuICBTdWJz Y3JpYmluZyB0byBSZWNlaXZlIEV2ZW50IE5vdGlmaWNhdGlvbnMgLiAuIC4gLiAuIC4gLiAuICA3 CiAgICAgICAyLjEuMS4gICZsdDtjcmVhdGUtc3Vic2NyaXB0aW9uJmd0OyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgNwogICAgIDIuMi4gIFNlbmRpbmcgRXZlbnQgTm90aWZpY2F0 aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTAKICAgICAgIDIuMi4xLiAgJmx0 O25vdGlmaWNhdGlvbiZndDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDEwCiAgICAgMi4zLiAgVGVybWluYXRpbmcgdGhlIFN1YnNjcmlwdGlvbiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAxMAogICAzLiAgU3VwcG9ydGluZyBDb25jZXB0cyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTEKICAgICAzLjEuICBDYXBhYmlsaXRp ZXMgRXhjaGFuZ2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAgICAg ICAzLjEuMS4gIENhcGFiaWxpdHkgSWRlbnRpZmllciAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAxMQogICAgICAgMy4xLjIuICBDYXBhYmlsaXR5IEV4YW1wbGUgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTEKICAgICAzLjIuICBFdmVudCBTdHJlYW1zICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAgICAgICAzLjIuMS4g IEV2ZW50IFN0cmVhbSBEZWZpbml0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx MwogICAgICAgMy4yLjIuICBFdmVudCBTdHJlYW0gQ29udGVudCBGb3JtYXQgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTMKICAgICAgIDMuMi4zLiAgRGVmYXVsdCBFdmVudCBTdHJlYW0gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzCiAgICAgICAzLjIuNC4gIEV2ZW50IFN0 cmVhbSBTb3VyY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMwogICAgICAg My4yLjUuICBFdmVudCBTdHJlYW0gRGlzY292ZXJ5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTMKICAgICAzLjMuICBOb3RpZmljYXRpb24gUmVwbGF5ICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2CiAgICAgICAzLjMuMS4gIE92ZXJ2aWV3IC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNgogICAgICAgMy4zLjIuICBD cmVhdGluZyBhIFN1YnNjcmlwdGlvbiB3aXRoIFJlcGxheSAgLiAuIC4gLiAuIC4gLiAuIC4gMTcK ICAgICAzLjQuICBOb3RpZmljYXRpb24gTWFuYWdlbWVudCBTY2hlbWEgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDE3CiAgICAgMy41LiAgU3Vic2NyaXB0aW9ucyBEYXRhIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMQogICAgIDMuNi4gIEZpbHRlciBNZWNoYW5p Y3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjEKICAgICAgIDMu Ni4xLiAgRmlsdGVyaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDIxCiAgICAgMy43LiAgTWVzc2FnZSBGbG93IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAyMQogICA0LiAgWE1MIFNjaGVtYSBmb3IgRXZlbnQgTm90aWZp Y2F0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjQKICAgNS4gIEZpbHRlcmluZyBF eGFtcGxlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI4CiAg ICAgNS4xLiAgU3VidHJlZSBGaWx0ZXJpbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjMyPC9mb250Pjwvc3RyaWtlPiA8 c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+MzE8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgNS4yLiAg WFBBVEggZmlsdGVycyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjMzPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm b250IGNvbG9yPSdncmVlbic+MzI8L2ZvbnQ+PC9zdHJvbmc+CiAgIDYuICBJbnRlcmxlYXZlIENh cGFiaWxpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtl Pjxmb250IGNvbG9yPSdyZWQnPjM1PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9y PSdncmVlbic+MzQ8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgNi4xLiAgRGVzY3JpcHRpb24gIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNv bG9yPSdyZWQnPjM1PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+ MzQ8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgNi4yLiAgRGVwZW5kZW5jaWVzIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQn PjM1PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+MzQ8L2ZvbnQ+ PC9zdHJvbmc+CiAgICAgNi4zLiAgQ2FwYWJpbGl0eSBJZGVudGlmaWVyICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjM1PC9mb250 Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+MzQ8L2ZvbnQ+PC9zdHJvbmc+ CiAgICAgNi40LiAgTmV3IE9wZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjM1PC9mb250Pjwvc3RyaWtl PiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+MzQ8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgNi41 LiAgTW9kaWZpY2F0aW9ucyB0byBFeGlzdGluZyBPcGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjM1PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25n Pjxmb250IGNvbG9yPSdncmVlbic+MzQ8L2ZvbnQ+PC9zdHJvbmc+CiAgIDcuICBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3Ry aWtlPjxmb250IGNvbG9yPSdyZWQnPjM2PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNv bG9yPSdncmVlbic+MzU8L2ZvbnQ+PC9zdHJvbmc+CiAgIDguICBJQU5BIENvbnNpZGVyYXRpb25z ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzNwogICA5LiAgQWNr bm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMzgKICAgMTAuIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDM5CiAgIEFwcGVuZGl4IEEuICBDaGFuZ2UgTG9nICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0MAogICAgIEEuMS4gIFZlcnNpb24g LTA4ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDAKICAg ICBBLjIuICBWZXJzaW9uIC0wOSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDQyCiAgICAgQS4zLiAgVmVyc2lvbiAtMTAgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0NAogICAgIEEuNC4gIFZlcnNpb24gLTExICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDQKICAgICBBLjUuICA8 c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPlZlc3Jpb248L2ZvbnQ+PC9zdHJpa2U+ICA8c3Ryb25n Pjxmb250IGNvbG9yPSdncmVlbic+VmVyc2lvbjwvZm9udD48L3N0cm9uZz4gLTEyICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDUKICAgICA8c3Ryb25nPjxm b250IGNvbG9yPSdncmVlbic+QS42LiAgVmVyc2lvbiAtMTMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0NTwvZm9udD48L3N0cm9uZz4KICAgQXV0aG9ycycg QWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+NDY8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZv bnQgY29sb3I9J2dyZWVuJz40ODwvZm9udD48L3N0cm9uZz4KICAgSW50ZWxsZWN0dWFsIFByb3Bl cnR5IGFuZCBDb3B5cmlnaHQgU3RhdGVtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIDxzdHJpa2U+ PGZvbnQgY29sb3I9J3JlZCc+NDc8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9 J2dyZWVuJz40OTwvZm9udD48L3N0cm9uZz4KCjEuICBJbnRyb2R1Y3Rpb24KCiAgIFtORVRDT05G XSBjYW4gYmUgY29uY2VwdHVhbGx5IHBhcnRpdGlvbmVkIGludG8gZm91ciBsYXllcnM6CgogICAg ICAgIExheWVyICAgICAgICAgICAgICAgICAgICAgICAgICAgIEV4YW1wbGUKICAgICstLS0tLS0t LS0tLS0tKyAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t KwogICAgfCAgIENvbnRlbnQgICB8ICAgICAgfCAgICAgQ29uZmlndXJhdGlvbiBkYXRhICAgICAg ICAgICAgICAgICAgICB8CiAgICArLS0tLS0tLS0tLS0tLSsgICAgICArLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgfAogICAgKy0tLS0tLS0tLS0tLS0rICAgICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICB8IE9wZXJhdGlvbnMgIHwgICAgICB8 ICZsdDtnZXQtY29uZmlnJmd0OywgJmx0O2VkaXQtY29uZmlnJmd0OyAmbHQ7bm90aWZpY2F0aW9u Jmd0O3wKICAgICstLS0tLS0tLS0tLS0tKyAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAgICArLS0tLS0tLS0tLS0tLSsgICAgICArLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rICAgICAgIHwKICAgIHwgICAgIFJQQyAgICAgfCAg ICAgIHwgICAgJmx0O3JwYyZndDssICZsdDtycGMtcmVwbHkmZ3Q7ICAgICAgIHwgICAgICAgfAog ICAgKy0tLS0tLS0tLS0tLS0rICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0zdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5l cyBtZWNoYW5pc21zIHRoYXQgcHJvdmlkZSBhbiBhc3luY2hyb25vdXMgbWVzc2FnZQogICBub3Rp ZmljYXRpb24gZGVsaXZlcnkgc2VydmljZSBmb3IgdGhlIE5FVENPTkYgcHJvdG9jb2wuICBUaGlz IGlzIGFuCiAgIG9wdGlvbmFsIGNhcGFiaWxpdHkgYnVpbHQgb24gdG9wIG9mIHRoZSBiYXNlIE5F VENPTkYgZGVmaW5pdGlvbi4KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBjYXBhYmlsaXRp ZXMgYW5kIG9wZXJhdGlvbnMgbmVjZXNzYXJ5IHRvCiAgIHN1cHBvcnQgdGhpcyBzZXJ2aWNlLgoK VGFibGUgb2YgQ29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNAogICAgIDEuMS4gIERlZmluaXRpb24g b2YgVGVybXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQKICAgICAx LjIuICBNb3RpdmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICA1CiAgICAgMS4zLiAgRXZlbnQgTm90aWZpY2F0aW9ucyBpbiBORVRDT05GIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNgogICAyLiAgTm90aWZpY2F0aW9uLVJlbGF0ZWQgT3Bl cmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcKICAgICAyLjEuICBTdWJz Y3JpYmluZyB0byBSZWNlaXZlIEV2ZW50IE5vdGlmaWNhdGlvbnMgLiAuIC4gLiAuIC4gLiAuICA3 CiAgICAgICAyLjEuMS4gICZsdDtjcmVhdGUtc3Vic2NyaXB0aW9uJmd0OyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgNwogICAgIDIuMi4gIFNlbmRpbmcgRXZlbnQgTm90aWZpY2F0 aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTAKICAgICAgIDIuMi4xLiAgJmx0 O25vdGlmaWNhdGlvbiZndDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDEwCiAgICAgMi4zLiAgVGVybWluYXRpbmcgdGhlIFN1YnNjcmlwdGlvbiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAxMAogICAzLiAgU3VwcG9ydGluZyBDb25jZXB0cyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTEKICAgICAzLjEuICBDYXBhYmlsaXRp ZXMgRXhjaGFuZ2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAgICAg ICAzLjEuMS4gIENhcGFiaWxpdHkgSWRlbnRpZmllciAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAxMQogICAgICAgMy4xLjIuICBDYXBhYmlsaXR5IEV4YW1wbGUgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTEKICAgICAzLjIuICBFdmVudCBTdHJlYW1zICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAgICAgICAzLjIuMS4g IEV2ZW50IFN0cmVhbSBEZWZpbml0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx MwogICAgICAgMy4yLjIuICBFdmVudCBTdHJlYW0gQ29udGVudCBGb3JtYXQgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTMKICAgICAgIDMuMi4zLiAgRGVmYXVsdCBFdmVudCBTdHJlYW0gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzCiAgICAgICAzLjIuNC4gIEV2ZW50IFN0 cmVhbSBTb3VyY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMwogICAgICAg My4yLjUuICBFdmVudCBTdHJlYW0gRGlzY292ZXJ5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTMKICAgICAzLjMuICBOb3RpZmljYXRpb24gUmVwbGF5ICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2CiAgICAgICAzLjMuMS4gIE92ZXJ2aWV3IC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNgogICAgICAgMy4zLjIuICBD cmVhdGluZyBhIFN1YnNjcmlwdGlvbiB3aXRoIFJlcGxheSAgLiAuIC4gLiAuIC4gLiAuIC4gMTcK ICAgICAzLjQuICBOb3RpZmljYXRpb24gTWFuYWdlbWVudCBTY2hlbWEgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDE3CiAgICAgMy41LiAgU3Vic2NyaXB0aW9ucyBEYXRhIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMQogICAgIDMuNi4gIEZpbHRlciBNZWNoYW5p Y3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjEKICAgICAgIDMu Ni4xLiAgRmlsdGVyaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDIxCiAgICAgMy43LiAgTWVzc2FnZSBGbG93IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAyMQogICA0LiAgWE1MIFNjaGVtYSBmb3IgRXZlbnQgTm90aWZp Y2F0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjQKICAgNS4gIEZpbHRlcmluZyBF eGFtcGxlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI4CiAg ICAgNS4xLiAgU3VidHJlZSBGaWx0ZXJpbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjMyPC9mb250Pjwvc3RyaWtlPiA8 c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+MzE8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgNS4yLiAg WFBBVEggZmlsdGVycyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjMzPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm b250IGNvbG9yPSdncmVlbic+MzI8L2ZvbnQ+PC9zdHJvbmc+CiAgIDYuICBJbnRlcmxlYXZlIENh cGFiaWxpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtl Pjxmb250IGNvbG9yPSdyZWQnPjM1PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9y PSdncmVlbic+MzQ8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgNi4xLitKyAg ICAgICB8CiAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgIHwKICAgICstLS0tLS0tLS0tLS0tKyAgICAgICstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgfCAgVHJhbnNwb3J0ICB8ICAgICAgfCAg IEJFRVAsIFNTSCwgU1NMLCBjb25zb2xlICAgICAgICAgICAgICAgICB8CiAgICB8ICBQcm90b2Nv bCAgIHwgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgICstLS0tLS0tLS0tLS0tKyAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKwoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDEK CiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBtZWNoYW5pc21zIHdoaWNoIHByb3ZpZGUgYW4gYXN5 bmNocm9ub3VzCiAgIG1lc3NhZ2Ugbm90aWZpY2F0aW9uIGRlbGl2ZXJ5IHNlcnZpY2UgZm9yIHRo ZSBbTkVUQ09ORl0gcHJvdG9jb2wuCiAgIFRoaXMgaXMgYW4gb3B0aW9uYWwgY2FwYWJpbGl0eSBi dWlsdCBvbiB0b3Agb2YgdGhlIGJhc2UgTkVUQ09ORgogICBkZWZpbml0aW9uLiAgVGhpcyBtZW1v IGRlZmluZXMgdGhlIGNhcGFiaWxpdGllcyBhbmQgb3BlcmF0aW9ucwogICBuZWNlc3NhcnkgdG8g c3VwcG9ydCB0aGlzIHNlcnZpY2UuCgoxLjEuICBEZWZpbml0aW9uIG9mIFRlcm1zCgogICBUaGUg a2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxM IE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBh bmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBh cyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLgoKICAgRWxlbWVudDogIEFuIFtYTUxdIEVsZW1lbnQu CgogICBTdWJzY3JpcHRpb246ICBBbiBhZ3JlZW1lbnQgYW5kIG1ldGhvZCB0byByZWNlaXZlIGV2 ZW50IG5vdGlmaWNhdGlvbnMKICAgICAgb3ZlciBhIE5FVENPTkYgc2Vzc2lvbi4gIEEgY29uY2Vw dCByZWxhdGVkIHRvIHRoZSBkZWxpdmVyeSBvZgogICAgICBub3RpZmljYXRpb25zIChpZiB0aGVy ZSBhcmUgYW55IHRvIHNlbmQpIGludm9sdmluZyBkZXN0aW5hdGlvbiBhbmQKICAgICAgc2VsZWN0 aW9uIG9mIG5vdGlmaWNhdGlvbnMuICBJdCBpcyBib3VuZCB0byB0aGUgbGlmZXRpbWUgb2YgYQog ICAgICBzZXNzaW9uLgoKICAgT3BlcmF0aW9uOiAgVGhpcyB0ZXJtIGlzIHVzZWQgdG8gcmVmZXIg dG8gTkVUQ09ORiBwcm90b2NvbCBvcGVyYXRpb25zCiAgICAgIFtORVRDT05GXS4gIFdpdGhpbiB0 aGlzIGRvY3VtZW50LCBvcGVyYXRpb24gcmVmZXJzIHRvIE5FVENPTkYKICAgICAgcHJvdG9jb2wg b3BlcmF0aW9ucyBkZWZpbmVkIGluIHN1cHBvcnQgb2YgTkVUQ09ORiBub3RpZmljYXRpb25zLgoK ICAgRXZlbnQ6ICBBbiBldmVudCBpcyBzb21ldGhpbmcgdGhhdCBoYXBwZW5zIHdoaWNoIG1heSBi ZSBvZiBpbnRlcmVzdCAtCiAgICAgIGEgY29uZmlndXJhdGlvbiBjaGFuZ2UsIGEgZmF1bHQsIGEg Y2hhbmdlIGluIHN0YXR1cywgY3Jvc3NpbmcgYQogICAgICB0aHJlc2hvbGQsIG9yIGFuIGV4dGVy bmFsIGlucHV0IHRvIHRoZSBzeXN0ZW0sIGZvciBleGFtcGxlLiAgT2Z0ZW4KICAgICAgdGhpcyBy ZXN1bHRzIGluIGFuIGFzeW5jaHJvbm91cyBtZXNzYWdlLCBzb21ldGltZXMgcmVmZXJyZWQgdG8g YXMKICAgICAgYSBub3RpZmljYXRpb24gb3IgZXZlbnQgbm90aWZpY2F0aW9uLCBiZWluZyBzZW50 IHRvIGludGVyZXN0ZWQKICAgICAgcGFydGllcyB0byBub3RpZnkgdGhlbSB0aGF0IHRoaXMgZXZl bnQgaGFzIG9jY3VycmVkLgoKICAgUmVwbGF5OiAgVGhlIGFiaWxpdHkgdG8gc2VuZC9yZS1zZW5k IHByZXZpb3VzbHkgbG9nZ2VkIG5vdGlmaWNhdGlvbnMKICAgICAgdXBvbiByZXF1ZXN0LiAgVGhl c2Ugbm90aWZpY2F0aW9ucyBhcmUgc2VudCBhc3luY2hyb25vdXNseS4gIFRoaXMKICAgICAgZmVh dHVyZSBpcyBpbXBsZW1lbnRlZCBieSB0aGUgTkVUQ09ORiBzZXJ2ZXIgYW5kIGludm9rZWQgYnkg dGhlCiAgICAgIE5FVENPTkYgY2xpZW50LgoKICAgU3RyZWFtOiAgQW4gZXZlbnQgc3RyZWFtIGlz IGEgc2V0IG9mIGV2ZW50IG5vdGlmaWNhdGlvbnMgbWF0Y2hpbmcKICAgICAgc29tZSBmb3J3YXJk aW5nIGNyaXRlcmlhIGFuZCBhdmFpbGFibGUgdG8gTkVUQ09ORiBjbGllbnRzIGZvcgogICAgICBz dWJzY3JpcHRpb24uCgogICBGaWx0ZXI6ICBBIHBhcmFtZXRlciB0aGF0IGluZGljYXRlcyB3aGlj aCBzdWJzZXQgb2YgYWxsIHBvc3NpYmxlCiAgICAgIGV2ZW50cyBhcmUgb2YgaW50ZXJlc3QuICBB IGZpbHRlciBpcyBkZWZpbmVkIGFzIG9uZSBvciBtb3JlIGZpbHRlcgogICAgICBlbGVtZW50IFtO RVRDT05GXSwgd2hpY2ggZWFjaCBpZGVudGlmaWVzIGEgcG9ydGlvbiBvZiB0aGUgb3ZlcmFsbAog ICAgICBmaWx0ZXIuCgoxLjIuICBNb3RpdmF0aW9uCgogICBUaGUgbW90aXZhdGlvbiBmb3IgdGhp cyB3b3JrIGlzIHRvIGVuYWJsZSB0aGUgc2VuZGluZyBvZiBhc3luY2hyb25vdXMKICAgbWVzc2Fn ZXMgdGhhdCBhcmUgY29uc2lzdGVudCB3aXRoIHRoZSBkYXRhIG1vZGVsIChjb250ZW50KSBhbmQK ICAgc2VjdXJpdHkgbW9kZWwgdXNlZCB3aXRoaW4gYSBORVRDT05GIGltcGxlbWVudGF0aW9uLgoK ICAgVGhlIHNjb3BlIG9mIHRoZSB3b3JrIGFpbXMgbWVldGluZyB0aGUgZm9sbG93aW5nIG9wZXJh dGlvbmFsIG5lZWRzOgoKICAgbyAgSW5pdGlhbCByZWxlYXNlIHNob3VsZCBlbnN1cmUgaXQgc3Vw cG9ydHMgbm90aWZpY2F0aW9ucyBpbiBzdXBwb3J0CiAgICAgIG9mIGNvbmZpZ3VyYXRpb24gb3Bl cmF0aW9ucy4KCiAgIG8gIEl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byB1c2UgdGhlIHNhbWUgZGF0 YSBtb2RlbCBmb3Igbm90aWZpY2F0aW9ucwogICAgICBhcyBmb3IgY29uZmlndXJhdGlvbiBvcGVy YXRpb25zLAgRGVzY3JpcHRpb24gIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNv bG9yPSdyZWQnPjM1PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+ MzQ8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgNi4yLiAgRGVwZW5kZW5jaWVzIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQn PjM1PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+MzQ8L2ZvbnQ+ PC9zdHJvbmc+CiAgICAgNi4zLiAgQ2FwYWJpbGl0eSBJZGVudGlmaWVyICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjM1PC9mb250 Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+MzQ8L2ZvbnQ+PC9zdHJvbmc+ CiAgICAgNi40LiAgTmV3IE9wZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjM1PC9mb250Pjwvc3RyaWtl PiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+MzQ8L2ZvbnQ+PC9zdHJvbmc+CiAgICAgNi41 LiAgTW9kaWZpY2F0aW9ucyB0byBFeGlzdGluZyBPcGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPjM1PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25n Pjxmb250IGNvbG9yPSdncmVlbic+MzQ8L2ZvbnQ+PC9zdHJvbmc+CiAgIDcuICBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA8c3Ry aWtlPjxmb250IGNvbG9yPSdyZWQnPjM2PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNv bG9yPSdncmVlbic+MzU8L2ZvbnQ+PC9zdHJvbmc+CiAgIDguICBJQU5BIENvbnNpZGVyYXRpb25z ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzNwogICA5LiAgQWNr bm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMzgKICAgMTAuIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDM5CiAgIEFwcGVuZGl4IEEuICBDaGFuZ2UgTG9nICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0MAogICAgIEEuMS4gIFZlcnNpb24g LTA4ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDAKICAg ICBBLjIuICBWZXJzaW9uIC0wOSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDQyCiAgICAgQS4zLiAgVmVyc2lvbiAtMTAgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0NAogICAgIEEuNC4gIFZlcnNpb24gLTExICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDQKICAgICBBLjUuICA8 c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPlZlc3Jpb248L2ZvbnQ+PC9zdHJpa2U+ICA8c3Ryb25n Pjxmb250IGNvbG9yPSdncmVlbic+VmVyc2lvbjwvZm9udD48L3N0cm9uZz4gLTEyICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNDUKICAgICA8c3Ryb25nPjxm b250IGNvbG9yPSdncmVlbic+QS42LiAgVmVyc2lvbiAtMTMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0NTwvZm9udD48L3N0cm9uZz4KICAgQXV0aG9ycycg QWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+NDY8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZv bnQgY29sb3I9J2dyZWVuJz40ODwvZm9udD48L3N0cm9uZz4KICAgSW50ZWxsZWN0dWFsIFByb3Bl cnR5IGFuZCBDb3B5cmlnaHQgU3RhdGVtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIDxzdHJpa2U+ PGZvbnQgY29sb3I9J3JlZCc+NDc8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9 J2dyZWVuJz40OTwvZm9udD48L3N0cm9uZz4KCjEuICBJbnRyb2R1Y3Rpb24KCiAgIFtORVRDT05G XSBjYW4gYmUgY29uY2VwdHVhbGx5IHBhcnRpdGlvbmVkIGludG8gZm91ciBsYXllcnM6CgogICAg ICAgIExheWVyICAgICAgICAgICAgICAgICAgICAgICAgICAgIEV4YW1wbGUKICAgICstLS0tLS0t LS0tLS0tKyAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t KwogICAgfCAgIENvbnRlbnQgICB8ICAgICAgfCAgICAgQ29uZmlndXJhdGlvbiBkYXRhICAgICAg ICAgICAgICAgICAgICB8CiAgICArLS0tLS0tLS0tLS0tLSsgICAgICArLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgfAogICAgKy0tLS0tLS0tLS0tLS0rICAgICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAgICB8IE9wZXJhdGlvbnMgIHwgICAgICB8 ICZsdDtnZXQtY29uZmlnJmd0OywgJmx0O2VkaXQtY29uZmlnJmd0OyAmbHQ7bm90aWZpY2F0aW9u Jmd0O3wKICAgICstLS0tLS0tLS0tLS0tKyAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICB8CiAgICArLS0tLS0tLS0tLS0tLSsgICAgICArLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rICAgICAgIHwKICAgIHwgICAgIFJQQyAgICAgfCAg ICAgIHwgICAgJmx0O3JwYyZndDssICZsdDtycGMtcmVwbHkmZ3Q7ICAgICAgIHwgICAgICAgfAog ICAgKy0tLS0tLS0tLS0tLS0rICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLgoKICAgbyAgU29sdXRpb24gc2hvdWxkIHN1cHBvcnQgYSByZWFzb25hYmxlIG1lc3Nh Z2Ugc2l6ZSBsaW1pdCAoaS5lLiwgbm90CiAgICAgIHRvbyBzaG9ydCkKCiAgIG8gIFRoZSBub3Rp ZmljYXRpb25zIHNob3VsZCBiZSBjYXJyaWVkIG92ZXIgYSBjb25uZWN0aW9uLW9yaWVudGVkCiAg ICAgIGRlbGl2ZXJ5IG1lY2hhbmlzbS4KCiAgIG8gIEEgc3Vic2NyaXB0aW9uIG1lY2hhbmlzbSBm b3Igbm90aWZpY2F0aW9ucyBzaG91bGQgYmUgcHJvdmlkZWQuCiAgICAgIFRoaXMgdGFrZXMgaW50 byBhY2NvdW50IHRoYXQgYSBORVRDT05GIHNlcnZlciBkb2VzIG5vdCBzZW5kCiAgICAgIG5vdGlm aWNhdGlvbnMgYmVmb3JlIGJlaW5nIGFza2VkIHRvIGRvIHNvIGFuZCB0aGF0IGl0IGlzIHRoZQog ICAgICBORVRDT05GIGNsaWVudCB3aG8gaW5pdGlhdGVzIHRoZSBmbG93IG9mIG5vdGlmaWNhdGlv bnMuCgogICBvICBBIGZpbHRlcmluZyBtZWNoYW5pc20gZm9yIHNlbmRpbmcgbm90aWZpY2F0aW9u cyBzaG91bGQgYmUgcHV0IGluCiAgICAgIHBsYWNlIHdpdGhpbiB0aGUgTkVUQ09ORiBzZXJ2ZXIu CgogICBvICBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIGEgbm90aWZpY2F0aW9uIHNob3Vs ZCBiZSBzdWZmaWNpZW50CiAgICAgIHNvIHRoYXQgaXQgY2FuIGJlIGFuYWx5emVkIGluZGVwZW5k ZW50IG9mIHRoZSB0cmFuc3BvcnQgbWVjaGFuaXNtLgogICAgICBJbiBvdGhlciB3b3JkcyB0aGUg ZGF0YSBjb250ZW50IGZ1bGx5IGRlc2NyaWJlcyBhIG5vdGlmaWNhdGlvbjsKICAgICAgcHJvdG9j b2wgaW5mb3JtYXRpb24gaXMgbm90IG5lZWRlZCB0byB1bmRlcnN0YW5kIGEgbm90aWZpY2F0aW9u LgoKICAgbyAgVGhlIHNlcnZlciBzaG91bGQgaGF2ZSB0aGUgY2FwYWJpbGl0eSB0byByZXBsYXkg bG9jYWxseSBsb2dnZWQKICAgICAgbm90aWZpY2F0aW9ucy4KCjEuMy4gIEV2ZW50IE5vdGlmaWNh dGlvbnMgaW4gTkVUQ09ORgoKICAgVGhpcyBtZW1vIGRlZmluZXMgYSBtZWNoYW5pc20gd2hlcmVi eSB0aGUgTkVUQ09ORiBjbGllbnQgaW5kaWNhdGVzCiAgIGludGVyZXN0IGluIHJlY2VpdmluZyBl dmVudCBub3RpZmljYXRpb25zIGZyb20gYSBORVRDT05GIHNlcnZlciBieQogICBjcmVhdGluZyBh IHN1YnNjcmlwdGlvbiB0byByZWNlaXZlIGV2ZW50IG5vdGlmaWNhdGlvbnMuICBUaGUgTkVUQ09O RgogICBzZXJ2ZXIgcmVwbGllcyB0byBpbmRpY2F0ZSB3aGV0aGVyIHRoZSBzdWJzY3JpcHRpb24g cmVxdWVzdCB3YXMKICAgc3VjY2Vzc2Z1bCBhbmQsIGlmIGl0IHdhcyBzdWNjZXNzZnVsLCBiZWdp bnMgc2VuZGluZyB0aGUgZXZlbnQKICAgbm90aWZpY2F0aW9ucyB0byB0aGUgTkVUQ09ORiBjbGll bnQgYXMgdGhlIGV2ZW50cyBvY2N1ciB3aXRoaW4gdGhlCiAgIHN5c3RlbS4gIFRoZXNlIGV2ZW50 IG5vdGlmaWNhdGlvbnMgd2lsbCBjb250aW51ZSB0byBiZSBzZW50IHVudGlsCiAgIGVpdGhlciB0 aGUgTkVUQ09ORiBzZXNzaW9uIGlzIHRlcm1pbmF0ZWQgb3IgdGhlIHN1YnNjcmlwdGlvbgogICB0 ZXJtaW5hdGVzIGZvciBzb21lIG90aGVyIHJlYXNvbi4gIFRoZSBldmVudCBub3RpZmljYXRpb24K ICAgc3Vic2NyaXB0aW9uIGFsbG93cyBhIG51bWJlciBvZiBvcHRpb25zIHRvIGVuYWJsZSB0aGUg TkVUQ09ORiBjbGllbnQKICAgdG8gc3BlY2lmeSB3aGljaCBldmVudHMgYXJlIG9mIGludGVyZXN0 LiAgVGhlc2UgYXJlIHNwZWNpZmllZCB3aGVuCiAgIHRoZSBzdWJzY3JpcHRpb24gaXMgY3JlYXRl ZC4gIE5vdGUgdGhhdCBhIHN1YnNjcmlwdGlvbiBjYW5ub3QgYmUKICAgbW9kaWZpZWQgb25jZSBj cmVhdGVkLgoKICAgVGhlIE5FVENPTkYgc2VydmVyIE1VU1QgYWNjZXB0IGFuZCBwcm9jZXNzIHRo ZSAmbHQ7Y2xvc2Utc2Vzc2lvbiZndDsKICAgb3BlcmF0aW9uLCBldmVuIHdoaWxlIHRoZSBub3Rp ZmljYXRpb24gc3Vic2NyaXB0aW9uIGlzIGFjdGl2ZS4gIFRoZQogICBORVRDT05GIHNlcnZlciBN QVkgYWNjZXB0IGFuZCBwcm9jZXNzIG90aGVyIGNvbW1hbmRzLCBvdGhlcndpc2UgdGhleQogICB3 aWxsIGJlIHJlamVjdGVkIGFuZCB0aGUgc2VydmVyIE1VU1Qgc2VuZCBhICdyZXNvdXJjZS1kZW5p ZWQnIGVycm9yLgogICBBIE5FVENPTkYgc2VydmVyIGFkdmVydGlzZXMgc3VwcG9ydCBvZiB0aGUg YWJpbGl0eSB0byBwcm9jZXNzIG90aGVyCiAgIGNvbW1hbmRzIHZpYSB0aGUgaW50ZXJsZWF2ZSBj YXBhYmlsaXR5LgoKMi4gIE5vdGlmaWNhdGlvbi1SZWxhdGVkIE9wZXJhdGlvbnMKCjIuMS4gIFN1 YnNjcmliaW5nIHRvIFJlY2VpdmUgRXZlbnQgTm90aWZpY2F0aW9ucwoKICAgVGhlIGV2ZW50IG5v dGlmaWNhdGlvbiBzdWJzY3JpcHRpb24gaXMgaW5pdGlhdGVkIGJ5IHRoZSBORVRDT05GCiAgIGNs aWVudCBhbmQgcmVzcG9uZGVkIHRvIGJ5IHRoZSBORVRDT05GIHNlcnZlci4gIEEgc3Vic2NyaXB0 aW9uIGlzCiAgIGJvdW5kIHRvIGEgc2luZ2xlIHN0cmVhbSBmb3IgdGhlIGxpZmV0aW1lIG9mIHRo ZSBzdWJzY3JpcHRpb24uICBXaGVuCiAgIHRoZSBldmVudCBub3RpZmljYXRpb24gc3Vic2NyaXB0 aW9uIGlzIGNyZWF0ZWQsIHRoZSBldmVudHMgb2YKICAgaW50ZXJlc3QgYXJlIHNwZWNpZmllZC4K CiAgIENvbnRlbnQgZm9yIGFuIGV2ZW50IG5vdGlmaWNhdGlvbiBzdWJzY3JpcHRpb24gY2FuIGJl IHNlbGVjdGVkIGJ5CiAgIGFwcGx5aW5nIHVzZXItc3BlY2lmaWVkIGZpbHRlcnMuCgoyLjEuMS4g ICZsdDtjcmVhdGUtc3Vic2NyaXB0aW9uJmd0OwoKICAgRGVzY3JpcHRpb246CgogICAgICBUaGlz IG9wZXJhdGlvbiBpbml0aWF0ZXMgYW4gZXZlbnQgbm90aWZpY2F0aW9uIHN1YnNjcmlwdGlvbiB3 aGljaAogICAgICB3aWxsIHNlbmQgYXN5bmNocm9ub3VzIGV2ZW50IG5vdGlmaWNhdGlvbnMgdG8g dGhlIGluaXRpYXRvciBvZiB0aGUKICAgICAgY29tbWFuZCB1bnRpbCB0aGUgc3Vic2NyaXB0aW9u IHRlcm1pbmF0ZXMuCgogICBQYXJhbWV0ZXJzOgoKICAgICAgU3RyZWFtOgoKICAgICAgICAgQW4g b3B0aW9uYWwgcGFyYW1ldGVyS0tLS0tKyAg ICAgICB8CiAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgIHwKICAgICstLS0tLS0tLS0tLS0tKyAgICAgICstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICAgfCAgVHJhbnNwb3J0ICB8ICAgICAgfCAg IEJFRVAsIFNTSCwgU1NMLCBjb25zb2xlICAgICAgICAgICAgICAgICB8CiAgICB8ICBQcm90b2Nv bCAgIHwgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgICstLS0tLS0tLS0tLS0tKyAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tKwoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDEK CiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBtZWNoYW5pc21zIHdoaWNoIHByb3ZpZGUgYW4gYXN5 bmNocm9ub3VzCiAgIG1lc3NhZ2Ugbm90aWZpY2F0aW9uIGRlbGl2ZXJ5IHNlcnZpY2UgZm9yIHRo ZSBbTkVUQ09ORl0gcHJvdG9jb2wuCiAgIFRoaXMgaXMgYW4gb3B0aW9uYWwgY2FwYWJpbGl0eSBi dWlsdCBvbiB0b3Agb2YgdGhlIGJhc2UgTkVUQ09ORgogICBkZWZpbml0aW9uLiAgVGhpcyBtZW1v IGRlZmluZXMgdGhlIGNhcGFiaWxpdGllcyBhbmQgb3BlcmF0aW9ucwogICBuZWNlc3NhcnkgdG8g c3VwcG9ydCB0aGlzIHNlcnZpY2UuCgoxLjEuICBEZWZpbml0aW9uIG9mIFRlcm1zCgogICBUaGUg a2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxM IE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBh bmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBh cyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLgoKICAgRWxlbWVudDogIEFuIFtYTUxdIEVsZW1lbnQu CgogICBTdWJzY3JpcHRpb246ICBBbiBhZ3JlZW1lbnQgYW5kIG1ldGhvZCB0byByZWNlaXZlIGV2 ZW50IG5vdGlmaWNhdGlvbnMKICAgICAgb3ZlciBhIE5FVENPTkYgc2Vzc2lvbi4gIEEgY29uY2Vw dCByZWxhdGVkIHRvIHRoZSBkZWxpdmVyeSBvZgogICAgICBub3RpZmljYXRpb25zIChpZiB0aGVy ZSBhcmUgYW55IHRvIHNlbmQpIGludm9sdmluZyBkZXN0aW5hdGlvbiBhbmQKICAgICAgc2VsZWN0 aW9uIG9mIG5vdGlmaWNhdGlvbnMuICBJdCBpcyBib3VuZCB0byB0aGUgbGlmZXRpbWUgb2YgYQog ICAgICBzZXNzaW9uLgoKICAgT3BlcmF0aW9uOiAgVGhpcyB0ZXJtIGlzIHVzZWQgdG8gcmVmZXIg dG8gTkVUQ09ORiBwcm90b2NvbCBvcGVyYXRpb25zCiAgICAgIFtORVRDT05GXS4gIFdpdGhpbiB0 aGlzIGRvY3VtZW50LCBvcGVyYXRpb24gcmVmZXJzIHRvIE5FVENPTkYKICAgICAgcHJvdG9jb2wg b3BlcmF0aW9ucyBkZWZpbmVkIGluIHN1cHBvcnQgb2YgTkVUQ09ORiBub3RpZmljYXRpb25zLgoK ICAgRXZlbnQ6ICBBbiBldmVudCBpcyBzb21ldGhpbmcgdGhhdCBoYXBwZW5zIHdoaWNoIG1heSBi ZSBvZiBpbnRlcmVzdCAtCiAgICAgIGEgY29uZmlndXJhdGlvbiBjaGFuZ2UsIGEgZmF1bHQsIGEg Y2hhbmdlIGluIHN0YXR1cywgY3Jvc3NpbmcgYQogICAgICB0aHJlc2hvbGQsIG9yIGFuIGV4dGVy bmFsIGlucHV0IHRvIHRoZSBzeXN0ZW0sIGZvciBleGFtcGxlLiAgT2Z0ZW4KICAgICAgdGhpcyBy ZXN1bHRzIGluIGFuIGFzeW5jaHJvbm91cyBtZXNzYWdlLCBzb21ldGltZXMgcmVmZXJyZWQgdG8g YXMKICAgICAgYSBub3RpZmljYXRpb24gb3IgZXZlbnQgbm90aWZpY2F0aW9uLCBiZWluZyBzZW50 IHRvIGludGVyZXN0ZWQKICAgICAgcGFydGllcyB0byBub3RpZnkgdGhlbSB0aGF0IHRoaXMgZXZl bnQgaGFzIG9jY3VycmVkLgoKICAgUmVwbGF5OiAgVGhlIGFiaWxpdHkgdG8gc2VuZC9yZS1zZW5k IHByZXZpb3VzbHkgbG9nZ2VkIG5vdGlmaWNhdGlvbnMKICAgICAgdXBvbiByZXF1ZXN0LiAgVGhl c2Ugbm90aWZpY2F0aW9ucyBhcmUgc2VudCBhc3luY2hyb25vdXNseS4gIFRoaXMKICAgICAgZmVh dHVyZSBpcyBpbXBsZW1lbnRlZCBieSB0aGUgTkVUQ09ORiBzZXJ2ZXIgYW5kIGludm9rZWQgYnkg dGhlCiAgICAgIE5FVENPTkYgY2xpZW50LgoKICAgU3RyZWFtOiAgQW4gZXZlbnQgc3RyZWFtIGlz IGEgc2V0IG9mIGV2ZW50IG5vdGlmaWNhdGlvbnMgbWF0Y2hpbmcKICAgICAgc29tZSBmb3J3YXJk aW5nIGNyaXRlcmlhIGFuZCBhdmFpbGFibGUgdG8gTkVUQ09ORiBjbGllbnRzIGZvcgogICAgICBz dWJzY3JpcHRpb24uCgogICBGaWx0ZXI6ICBBIHBhcmFtZXRlciB0aGF0IGluZGljYXRlcyB3aGlj aCBzdWJzZXQgb2YgYWxsIHBvc3NpYmxlCiAgICAgIGV2ZW50cyBhcmUgb2YgaW50ZXJlc3QuICBB IGZpbHRlciBpcyBkZWZpbmVkIGFzIG9uZSBvciBtb3JlIGZpbHRlcgogICAgICBlbGVtZW50IFtO RVRDT05GXSwgd2hpY2ggZWFjaCBpZGVudGlmaWVzIGEgcG9ydGlvbiBvZiB0aGUgb3ZlcmFsbAog ICAgICBmaWx0ZXIuCgoxLjIuICBNb3RpdmF0aW9uCgogICBUaGUgbW90aXZhdGlvbiBmb3IgdGhp cyB3b3JrIGlzIHRvIGVuYWJsZSB0aGUgc2VuZGluZyBvZiBhc3luY2hyb25vdXMKICAgbWVzc2Fn ZXMgdGhhdCBhcmUgY29uc2lzdGVudCB3aXRoIHRoZSBkYXRhIG1vZGVsIChjb250ZW50KSBhbmQK ICAgc2VjdXJpdHkgbW9kZWwgdXNlZCB3aXRoaW4gYSBORVRDT05GIGltcGxlbWVudGF0aW9uLgoK ICAgVGhlIHNjb3BlIG9mIHRoZSB3b3JrIGFpbXMgbWVldGluZyB0aGUgZm9sbG93aW5nIG9wZXJh dGlvbmFsIG5lZWRzOgoKICAgbyAgSW5pdGlhbCByZWxlYXNlIHNob3VsZCBlbnN1cmUgaXQgc3Vw cG9ydHMgbm90aWZpY2F0aW9ucyBpbiBzdXBwb3J0CiAgICAgIG9mIGNvbmZpZ3VyYXRpb24gb3Bl cmF0aW9ucy4KCiAgIG8gIEl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byB1c2UgdGhlIHNhbWUgZGF0 YSBtb2RlbCBmb3Igbm90aWZpY2F0aW9ucwogICAgICBhcyBmb3IgY29uZmlndXJhdGlvbiBvcGVy YXRLCAmbHQ7c3RyZWFtJmd0OywgdGhhdCBpbmRpY2F0ZXMgd2hpY2gg c3RyZWFtIG9mCiAgICAgICAgIGV2ZW50cyBpcyBvZiBpbnRlcmVzdC4gIElmIG5vdCBwcmVzZW50 LCBldmVudHMgaW4gdGhlIGRlZmF1bHQKICAgICAgICAgTkVUQ09ORiBzdHJlYW0gd2lsbCBiZSBz ZW50LgoKICAgICAgRmlsdGVyOgoKICAgICAgICAgQW4gb3B0aW9uYWwgcGFyYW1ldGVyLCAmbHQ7 ZmlsdGVyJmd0OywgdGhhdCBpbmRpY2F0ZXMgd2hpY2ggc3Vic2V0IG9mCiAgICAgICAgIGFsbCBw b3NzaWJsZSBldmVudHMgaXMgb2YgaW50ZXJlc3QuICBUaGUgZm9ybWF0IG9mIHRoaXMKICAgICAg ICAgcGFyYW1ldGVyIGlzIHRoZSBzYW1lIGFzIHRoYXQgb2YgdGhlIGZpbHRlciBwYXJhbWV0ZXIg aW4gdGhlCiAgICAgICAgIE5FVENPTkYgcHJvdG9jb2wgb3BlcmF0aW9ucy4gIElmIG5vdCBwcmVz ZW50LCBhbGwgZXZlbnRzIG5vdAogICAgICAgICBwcmVjbHVkZWQgYnkgb3RoZXIgcGFyYW1ldGVy cyB3aWxsIGJlIHNlbnQuICBTZWUgc2VjdGlvbiAzLjYKICAgICAgICAgZm9yIG1vcmUgaW5mb3Jt YXRpb24gb24gZmlsdGVycy4KCiAgICAgIFN0YXJ0IFRpbWU6CgogICAgICAgICBBIHBhcmFtZXRl ciwgJmx0O3N0YXJ0VGltZSZndDssIHVzZWQgdG8gdHJpZ2dlciB0aGUgcmVwbGF5IGZlYXR1cmUK ICAgICAgICAgYW5kIGluZGljYXRlIHRoYXQgdGhlIHJlcGxheSBzaG91bGQgc3RhcnQgYXQgdGhl IHRpbWUKICAgICAgICAgc3BlY2lmaWVkLiAgSWYgJmx0O3N0YXJ0VGltZSZndDsgaXMgbm90IHBy ZXNlbnQsIHRoaXMgaXMgbm90IGEgcmVwbGF5CiAgICAgICAgIHN1YnNjcmlwdGlvbi4gIEl0IGlz IG5vdCB2YWxpZCB0byBzcGVjaWZ5IHN0YXJ0IHRpbWVzIHRoYXQgYXJlCiAgICAgICAgIGxhdGVy IHRoYW4gdGhlIGN1cnJlbnQgdGltZS4gIElmIHRoZSAmbHQ7c3RhcnRUaW1lJmd0OyBzcGVjaWZp ZWQgaXMKICAgICAgICAgZWFybGllciB0aGFuIHRoZSBsb2cgY2FuIHN1cHBvcnQsIHRoZSByZXBs YXkgd2lsbCBiZWdpbiB3aXRoCiAgICAgICAgIHRoZSBlYXJsaWVzdCBhdmFpbGFibGUgbm90aWZp Y2F0aW9uLiAgVGhpcyBwYXJhbWV0ZXIgaXMgb2YgdHlwZQogICAgICAgICA8c3RyaWtlPjxmb250 IGNvbG9yPSdyZWQnPmRhdGVUaW1lLjwvZm9udD48L3N0cmlrZT4KICAgICAgICAgPHN0cm9uZz48 Zm9udCBjb2xvcj0nZ3JlZW4nPmRhdGVUaW1lIGFuZCBjb21wbGlhbnQgdG8gW1JGQzMzMzldIGFu ZCBbSVNPLjg2MDEuMTk4OF0uCgogICAgICAgICBJbXBsZW1lbnRhdGlvbnMgbXVzdCBzdXBwb3J0 IHRpbWUgem9uZXMuPC9mb250Pjwvc3Ryb25nPgoKICAgICAgU3RvcCBUaW1lOgoKICAgICAgICAg QW4gb3B0aW9uYWwgcGFyYW1ldGVyLCAmbHQ7c3RvcFRpbWUmZ3Q7LCB1c2VkIHdpdGggdGhlIG9w dGlvbmFsCiAgICAgICAgIHJlcGxheSBmZWF0dXJlIHRvIGluZGljYXRlIHRoZSBuZXdlc3Qgbm90 aWZpY2F0aW9ucyBvZgogICAgICAgICBpbnRlcmVzdC4gIElmIHN0b3AgdGltZSBpcyBub3QgcHJl c2VudCwgdGhlIG5vdGlmaWNhdGlvbnMgd2lsbAogICAgICAgICBjb250aW51ZSB1bnRpbCB0aGUg c3Vic2NyaXB0aW9uIGlzIHRlcm1pbmF0ZWQuICBNdXN0IGJlIHVzZWQKICAgICAgICAgd2l0aCBh bmQgYmUgbGF0ZXIgdGhhbiAmbHQ7c3RhcnRUaW1lJmd0Oy4gIFZhbHVlcyBvZiAmbHQ7c3RvcFRp bWUmZ3Q7IGluCiAgICAgICAgIHRoZSBmdXR1cmUgYXJlIHZhbGlkLiAgVGhpcyBwYXJhbWV0ZXIg aXMgb2YgdHlwZSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPmRhdGVUaW1lLjwvZm9udD48L3N0 cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPmRhdGVUaW1lIGFuZAogICAgICAgICBj b21wbGlhbnQgdG8gW1JGQzMzMzldIGFuZCBbSVNPLjg2MDEuMTk4OF0uICBJbXBsZW1lbnRhdGlv bnMKICAgICAgICAgbXVzdCBzdXBwb3J0IHRpbWUgem9uZXMuPC9mb250Pjwvc3Ryb25nPgoKICAg UG9zaXRpdmUgUmVzcG9uc2U6CgogICAgICBJZiB0aGUgTkVUQ09ORiBzZXJ2ZXIgY2FuIHNhdGlz ZnkgdGhlIHJlcXVlc3QsIHRoZSBzZXJ2ZXIgc2VuZHMgYW4KICAgICAgJmx0O29rJmd0OyBlbGVt ZW50LgoKICAgTmVnYXRpdmUgUmVzcG9uc2U6CgogICAgICBBbiAmbHQ7cnBjLWVycm9yJmd0OyBl bGVtZW50IGlzIGluY2x1ZGVkIHdpdGhpbiB0aGUgJmx0O3JwYy1yZXBseSZndDsgaWYgdGhlCiAg ICAgIHJlcXVlc3QgY2Fubm90IGJlIGNvbXBsZXRlZCBmb3IgYW55IHJlYXNvbi4gIFN1YnNjcmlw dGlvbiByZXF1ZXN0cwogICAgICB3aWxsIGZhaWwgaWYgYSBmaWx0ZXIgd2l0aCBpbnZhbGlkIHN5 bnRheCBpcyBwcm92aWRlZCBvciBpZiB0aGUKICAgICAgbmFtZSBvZiBhIG5vbi1leGlzdGVudCBz dHJlYW0gaXMgcHJvdmlkZWQuCgogICAgICBJZiBhICZsdDtzdG9wVGltZSZndDsgaXMgc3BlY2lm aWVkIGluIGEgcmVxdWVzdCB3aXRob3V0IGhhdmluZyBzcGVjaWZpZWQKICAgICAgYSAmbHQ7c3Rh cnRUaW1lJmd0OywgdGhlIGZvbGxvd2luZyBlcnJvciBpcyByZXR1cm5lZDoKCiAgICAgICAgIFRh ZzogbWlzc2luZy1lbGVtZW50CgogICAgICAgICBFcnJvci10eXBlOiBwcm90b2NvbAoKICAgICAg ICAgU2V2ZXJpdHk6IGVycm9yCgogICAgICAgICBFcnJvci1pbmZvOiAmbHQ7YmFkLWVsZW1lbnQm Z3Q7OiBzdGFydFRpbWUKCiAgICAgICAgIERlc2NyaXB0aW9uOiBBbiBleHBlY3RlZCBlbGVtZW50 IGlzIG1pc3NpbmcuCgogICAgICBJZiB0aGUgb3B0aW9uYWwgcmVwbGF5IGZlYXR1cmUgaXMgcmVx dWVzdGVkIGJ1dCBpdCBpcyBub3QKICAgICAgc3VwcG9ydGVkIGJ5IHRoZSBORVRDT05GIHNlcnZl ciwgdGhlIGZvbGxvd2luZyBlcnJvciBpcyByZXR1cm5lZDoKCiAgICAgICAgIFRhZzogb3BlcmF0 aW9uLWZhaWxlZAoKICAgICAgICAgRXJyb3ItdHlwZTogcHJvdG9jb2wKICAgICAgICAgU2V2ZXJp dHk6IGVycm9yCgogICAgICAgICBFcnJvci1pbmZvOiBub25lCgogICAgICAgICBEZXNjcmlwdGlv bjogUmVxdWVzdCBjb3VsZCBub3QgYmUgY29tcGxpb25zLgoKICAgbyAgU29sdXRpb24gc2hvdWxkIHN1cHBvcnQgYSByZWFzb25hYmxlIG1lc3Nh Z2Ugc2l6ZSBsaW1pdCAoaS5lLiwgbm90CiAgICAgIHRvbyBzaG9ydCkKCiAgIG8gIFRoZSBub3Rp ZmljYXRpb25zIHNob3VsZCBiZSBjYXJyaWVkIG92ZXIgYSBjb25uZWN0aW9uLW9yaWVudGVkCiAg ICAgIGRlbGl2ZXJ5IG1lY2hhbmlzbS4KCiAgIG8gIEEgc3Vic2NyaXB0aW9uIG1lY2hhbmlzbSBm b3Igbm90aWZpY2F0aW9ucyBzaG91bGQgYmUgcHJvdmlkZWQuCiAgICAgIFRoaXMgdGFrZXMgaW50 byBhY2NvdW50IHRoYXQgYSBORVRDT05GIHNlcnZlciBkb2VzIG5vdCBzZW5kCiAgICAgIG5vdGlm aWNhdGlvbnMgYmVmb3JlIGJlaW5nIGFza2VkIHRvIGRvIHNvIGFuZCB0aGF0IGl0IGlzIHRoZQog ICAgICBORVRDT05GIGNsaWVudCB3aG8gaW5pdGlhdGVzIHRoZSBmbG93IG9mIG5vdGlmaWNhdGlv bnMuCgogICBvICBBIGZpbHRlcmluZyBtZWNoYW5pc20gZm9yIHNlbmRpbmcgbm90aWZpY2F0aW9u cyBzaG91bGQgYmUgcHV0IGluCiAgICAgIHBsYWNlIHdpdGhpbiB0aGUgTkVUQ09ORiBzZXJ2ZXIu CgogICBvICBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIGEgbm90aWZpY2F0aW9uIHNob3Vs ZCBiZSBzdWZmaWNpZW50CiAgICAgIHNvIHRoYXQgaXQgY2FuIGJlIGFuYWx5emVkIGluZGVwZW5k ZW50IG9mIHRoZSB0cmFuc3BvcnQgbWVjaGFuaXNtLgogICAgICBJbiBvdGhlciB3b3JkcyB0aGUg ZGF0YSBjb250ZW50IGZ1bGx5IGRlc2NyaWJlcyBhIG5vdGlmaWNhdGlvbjsKICAgICAgcHJvdG9j b2wgaW5mb3JtYXRpb24gaXMgbm90IG5lZWRlZCB0byB1bmRlcnN0YW5kIGEgbm90aWZpY2F0aW9u LgoKICAgbyAgVGhlIHNlcnZlciBzaG91bGQgaGF2ZSB0aGUgY2FwYWJpbGl0eSB0byByZXBsYXkg bG9jYWxseSBsb2dnZWQKICAgICAgbm90aWZpY2F0aW9ucy4KCjEuMy4gIEV2ZW50IE5vdGlmaWNh dGlvbnMgaW4gTkVUQ09ORgoKICAgVGhpcyBtZW1vIGRlZmluZXMgYSBtZWNoYW5pc20gd2hlcmVi eSB0aGUgTkVUQ09ORiBjbGllbnQgaW5kaWNhdGVzCiAgIGludGVyZXN0IGluIHJlY2VpdmluZyBl dmVudCBub3RpZmljYXRpb25zIGZyb20gYSBORVRDT05GIHNlcnZlciBieQogICBjcmVhdGluZyBh IHN1YnNjcmlwdGlvbiB0byByZWNlaXZlIGV2ZW50IG5vdGlmaWNhdGlvbnMuICBUaGUgTkVUQ09O RgogICBzZXJ2ZXIgcmVwbGllcyB0byBpbmRpY2F0ZSB3aGV0aGVyIHRoZSBzdWJzY3JpcHRpb24g cmVxdWVzdCB3YXMKICAgc3VjY2Vzc2Z1bCBhbmQsIGlmIGl0IHdhcyBzdWNjZXNzZnVsLCBiZWdp bnMgc2VuZGluZyB0aGUgZXZlbnQKICAgbm90aWZpY2F0aW9ucyB0byB0aGUgTkVUQ09ORiBjbGll bnQgYXMgdGhlIGV2ZW50cyBvY2N1ciB3aXRoaW4gdGhlCiAgIHN5c3RlbS4gIFRoZXNlIGV2ZW50 IG5vdGlmaWNhdGlvbnMgd2lsbCBjb250aW51ZSB0byBiZSBzZW50IHVudGlsCiAgIGVpdGhlciB0 aGUgTkVUQ09ORiBzZXNzaW9uIGlzIHRlcm1pbmF0ZWQgb3IgdGhlIHN1YnNjcmlwdGlvbgogICB0 ZXJtaW5hdGVzIGZvciBzb21lIG90aGVyIHJlYXNvbi4gIFRoZSBldmVudCBub3RpZmljYXRpb24K ICAgc3Vic2NyaXB0aW9uIGFsbG93cyBhIG51bWJlciBvZiBvcHRpb25zIHRvIGVuYWJsZSB0aGUg TkVUQ09ORiBjbGllbnQKICAgdG8gc3BlY2lmeSB3aGljaCBldmVudHMgYXJlIG9mIGludGVyZXN0 LiAgVGhlc2UgYXJlIHNwZWNpZmllZCB3aGVuCiAgIHRoZSBzdWJzY3JpcHRpb24gaXMgY3JlYXRl ZC4gIE5vdGUgdGhhdCBhIHN1YnNjcmlwdGlvbiBjYW5ub3QgYmUKICAgbW9kaWZpZWQgb25jZSBj cmVhdGVkLgoKICAgVGhlIE5FVENPTkYgc2VydmVyIE1VU1QgYWNjZXB0IGFuZCBwcm9jZXNzIHRo ZSAmbHQ7Y2xvc2Utc2Vzc2lvbiZndDsKICAgb3BlcmF0aW9uLCBldmVuIHdoaWxlIHRoZSBub3Rp ZmljYXRpb24gc3Vic2NyaXB0aW9uIGlzIGFjdGl2ZS4gIFRoZQogICBORVRDT05GIHNlcnZlciBN QVkgYWNjZXB0IGFuZCBwcm9jZXNzIG90aGVyIGNvbW1hbmRzLCBvdGhlcndpc2UgdGhleQogICB3 aWxsIGJlIHJlamVjdGVkIGFuZCB0aGUgc2VydmVyIE1VU1Qgc2VuZCBhICdyZXNvdXJjZS1kZW5p ZWQnIGVycm9yLgogICBBIE5FVENPTkYgc2VydmVyIGFkdmVydGlzZXMgc3VwcG9ydCBvZiB0aGUg YWJpbGl0eSB0byBwcm9jZXNzIG90aGVyCiAgIGNvbW1hbmRzIHZpYSB0aGUgaW50ZXJsZWF2ZSBj YXBhYmlsaXR5LgoKMi4gIE5vdGlmaWNhdGlvbi1SZWxhdGVkIE9wZXJhdGlvbnMKCjIuMS4gIFN1 YnNjcmliaW5nIHRvIFJlY2VpdmUgRXZlbnQgTm90aWZpY2F0aW9ucwoKICAgVGhlIGV2ZW50IG5v dGlmaWNhdGlvbiBzdWJzY3JpcHRpb24gaXMgaW5pdGlhdGVkIGJ5IHRoZSBORVRDT05GCiAgIGNs aWVudCBhbmQgcmVzcG9uZGVkIHRvIGJ5IHRoZSBORVRDT05GIHNlcnZlci4gIEEgc3Vic2NyaXB0 aW9uIGlzCiAgIGJvdW5kIHRvIGEgc2luZ2xlIHN0cmVhbSBmb3IgdGhlIGxpZmV0aW1lIG9mIHRo ZSBzdWJzY3JpcHRpb24uICBXaGVuCiAgIHRoZSBldmVudCBub3RpZmljYXRpb24gc3Vic2NyaXB0 aW9uIGlzIGNyZWF0ZWQsIHRoZSBldmVudHMgb2YKICAgaW50ZXJlc3QgYXJlIHNwZWNpZmllZC4K CiAgIENvbnRlbnQgZm9yIGFuIGV2ZW50IG5vdGlmaWNhdGlvbiBzdWJzY3JpcHRpb24gY2FuIGJl IHNlbGVjdGVkIGJ5CiAgIGFwcGx5aW5nIHVzZXItc3BlY2lmaWVkIGZpbHRlcnMuCgoyLjEuMS4g ICZsdDtjcmVhdGUtc3Vic2NyaXB0aW9uJmd0OwoKICAgRGVzY3JpcHRpb246CgogICAgICBUaGlz IG9wZXJhdGlvbiBpbml0aWF0ZXMgYW4gZXZlbnQgbm90aWZpY2F0aW9uIHN1YnNjcmlwdGlvbiB3 aGljaAogICAgICB3aWxsIHNlbmQgYXN5bmNocm9ub3VzIGV2ZW50IG5vdGlmaWNhdGlvbnMgdG8g dGhlIGluaXRpYXRvciBvZiB0aGUKICAgICAgY29tbWFuZCB1bnRpbCB0aGUgc3Vic2NyaXB0aW9u IHRlcm1pbmF0ZXMuCgogICBQYXJhbWV0ZXJzOgoKICAgICAgU3RyZWFtOgoKICAgICAgICAgQW4g b3B0aW9uYWwgcGFyYWldGVkIGJlY2F1c2UgdGhlCiAgICAgICAgIHJl cXVlc3RlZCBvcGVyYXRpb24gZmFpbGVkIGZvciBzb21lIHJlYXNvbiBub3QgY292ZXJlZCBieSBh bnkKICAgICAgICAgb3RoZXIgZXJyb3IgY29uZGl0aW9uCgogICAgICBJZiBhICZsdDtzdG9wVGlt ZSZndDsgaXMgcmVxdWVzdGVkIHdoaWNoIGlzIGVhcmxpZXIgdGhlbiB0aGUgc3BlY2lmaWVkCiAg ICAgICZsdDtzdGFydFRpbWUmZ3Q7LCB0aGUgZm9sbG93aW5nIGVycm9yIGlzIHJldHVybmVkOgoK ICAgICAgICAgVGFnOiBiYWQtZWxlbWVudAoKICAgICAgICAgRXJyb3ItdHlwZTogcHJvdG9jb2wK CiAgICAgICAgIFNldmVyaXR5OiBlcnJvcgoKICAgICAgICAgRXJyb3ItaW5mbzogJmx0O2JhZC1l bGVtZW50Jmd0Ozogc3RvcFRpbWUKCiAgICAgICAgIERlc2NyaXB0aW9uOiBBbiBlbGVtZW50IHZh bHVlIGlzIG5vdCBjb3JyZWN0OyBlLmcuLCB3cm9uZyB0eXBlLAogICAgICAgICBvdXQgb2YgcmFu Z2UsIHBhdHRlcm4gbWlzbWF0Y2guCgogICAgICBJZiBhICZsdDtzdGFydFRpbWUmZ3Q7IGlzIHJl cXVlc3RlZCB3aGljaCBpcyBsYXRlciB0aGVuIHRoZSBjdXJyZW50CiAgICAgIHRpbWUsIHRoZSBm b2xsb3dpbmcgZXJyb3IgaXMgcmV0dXJuZWQ6CgogICAgICAgICBUYWc6IGJhZC1lbGVtZW50Cgog ICAgICAgICBFcnJvci10eXBlOiBwcm90b2NvbAoKICAgICAgICAgU2V2ZXJpdHk6IGVycm9yCgog ICAgICAgICBFcnJvci1pbmZvOiAmbHQ7YmFkLWVsZW1lbnQmZ3Q7OiBzdGFydFRpbWUKCiAgICAg ICAgIERlc2NyaXB0aW9uOiBBbiBlbGVtZW50IHZhbHVlIGlzIG5vdCBjb3JyZWN0OyBlLmcuLCB3 cm9uZyB0eXBlLAogICAgICAgICBvdXQgb2YgcmFuZ2UsIHBhdHRlcm4gbWlzbWF0Y2guCgoyLjEu MS4xLiAgVXNhZ2UgRXhhbXBsZQoKICAgVGhlIGZvbGxvd2luZyBkZW1vbnN0cmF0ZXMgY3JlYXRp bmcgYSBzaW1wbGUgc3Vic2NyaXB0aW9uLiAgTW9yZQogICBjb21wbGV4IGV4YW1wbGVzIGNhbiBi ZSBmb3VuZCBpbiBzZWN0aW9uIDUuCgogICAmbHQ7bmV0Y29uZjpycGMgbWVzc2FnZS1pZD0iMTAx IgogICAgICAgICB4bWxuczpuZXRjb25mPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6 YmFzZToxLjAiLyZndDsKICAgICAgICZsdDtjcmVhdGUtc3Vic2NyaXB0aW9uCiAgICAgICAgICAg eG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRpb246MS4wIiZn dDsKICAgICAgICZsdDsvY3JlYXRlLXN1YnNjcmlwdGlvbiZndDsKICAgJmx0Oy9uZXRjb25mOnJw YyZndDsKCjIuMi4gIFNlbmRpbmcgRXZlbnQgTm90aWZpY2F0aW9ucwoKICAgT25jZSB0aGUgc3Vi c2NyaXB0aW9uIGhhcyBiZWVuIHNldCB1cCwgdGhlIE5FVENPTkYgc2VydmVyIHNlbmRzIHRoZQog ICBldmVudCBub3RpZmljYXRpb25zIGFzeW5jaHJvbm91c2x5IG92ZXIgdGhlIGNvbm5lY3Rpb24u CgoyLjIuMS4gICZsdDtub3RpZmljYXRpb24mZ3Q7CgogICBEZXNjcmlwdGlvbjoKCiAgICAgIEFu IGV2ZW50IG5vdGlmaWNhdGlvbiBpcyBzZW50IHRvIHRoZSBjbGllbnQgd2hvIGluaXRpYXRlZCBh CiAgICAgICZsdDtjcmVhdGUtc3Vic2NyaXB0aW9uJmd0OyBjb21tYW5kIGFzeW5jaHJvbm91c2x5 IHdoZW4gYW4gZXZlbnQgb2YKICAgICAgaW50ZXJlc3QgKGkuZS4sIG1lZXRpbmcgdGhlIHNwZWNp ZmllZCBmaWx0ZXJpbmcgY3JpdGVyaWEpIGhhcwogICAgICBvY2N1cnJlZC4gIEFuIGV2ZW50IG5v dGlmaWNhdGlvbiBpcyBhIGNvbXBsZXRlIGFuZCB3ZWxsLWZvcm1lZCBYTUwKICAgICAgZG9jdW1l bnQuICBOb3RlIHRoYXQgJmx0O25vdGlmaWNhdGlvbiZndDsgaXMgbm90IGFuIFJQQyBtZXRob2Qg YnV0CiAgICAgIHJhdGhlciB0aGUgdG9wIGxldmVsIGVsZW1lbnQgaWRlbnRpZnlpbmcgdGhlIG9u ZS13YXkgbWVzc2FnZSBhcyBhCiAgICAgIG5vdGlmaWNhdGlvbi4KCiAgIFBhcmFtZXRlcnM6Cgog ICAgICBldmVudFRpbWUKCiAgICAgICAgIFRoZSB0aW1lIHRoZSBldmVudCB3YXMgZ2VuZXJhdGVk IGJ5IHRoZSBldmVudCBzb3VyY2UuICBUaGlzCiAgICAgICAgIHBhcmFtZXRlciBpcyBvZiB0eXBl IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+ZGF0ZVRpbWUuPC9mb250Pjwvc3RyaWtlPiA8c3Ry b25nPjxmb250IGNvbG9yPSdncmVlbic+ZGF0ZVRpbWUgYW5kIGNvbXBsaWFudCB0byBbUkZDMzMz OV0gYW5kCiAgICAgICAgIFtJU08uODYwMS4xOTg4XS4gIEltcGxlbWVudGF0aW9ucyBtdXN0IHN1 cHBvcnQgdGltZSB6b25lcy48L2ZvbnQ+PC9zdHJvbmc+CgogICAgICBBbHNvIGNvbnRhaW5zIG5v dGlmaWNhdGlvbi1zcGVjaWZpYyB0YWdnZWQgY29udGVudCwgaWYgYW55LiAgV2l0aAogICAgICB0 aGUgZXhjZXB0aW9uIG9mICZsdDtldmVudFRpbWUmZ3Q7LCB0aGUgY29udGVudCBvZiB0aGUgbm90 aWZpY2F0aW9uIGlzCiAgICAgIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4KCiAg IFJlc3BvbnNlOgoKICAgICAgTm8gcmVzcG9uc2UuICBOb3QgYXBwbGljYWJsZS4KCjIuMy4gIFRl cm1pbmF0aW5nIHRoZSBTdWJzY3JpcHRpb24KCiAgIENsb3Npbmcgb2YgdGhlIGV2ZW50IG5vdGlm aWNhdGlvbiBzdWJzY3JpcHRpb24gY2FuIGJlIGRvbmUgYnkgdXNpbmcKICAgdGhlICZsdDtjbG9z ZS1zZXNzaW9uJmd0OyBvcGVyYXRpb24gZnJvbSB0aGUgc3Vic2NyaXB0aW9ucyBzZXNzaW9uIG9y CiAgIHRlcm1pbmF0aW5nIHRoZSBORVRDT05GIHNlc3Npb24gKCAmbHQ7a2lsbC1zZXNzaW9uJmd0 OyApIG9yIHRoZSB1bmRlcmx5aW5nCiAgIHRyYW5zcG9ydCBzZXNzaW9uIGZyb20gYW5vdGhlciBz ZXNzaW9uLiAgSWYgYSBzdG9wIHRpbWUgaXMgcHJvdmlkZWQKICAgd2hlbiB0aGUgc3Vic2NyaXB0 aW9uIGlzIGNyZWF0ZWQsIHRoZSBzdWJzY3JpcHRpb24gd2lsbCB0ZXJtaW5hdGUKICAgYWZ0ZXIg dGhlIHN0b3AgdGltZSBpcyByZWFjaGVkLiAgSW4gdGhpcyBjYXNlLCB0aGUgTkVUQ09ORiBzZXNz aW9uCiAgIHdpbGwgc3RpbGwgYmUgYW4gYWN0aXZlIHNlc3Npb24uCg1ldGVyLCAmbHQ7c3RyZWFtJmd0OywgdGhhdCBpbmRpY2F0ZXMgd2hpY2gg c3RyZWFtIG9mCiAgICAgICAgIGV2ZW50cyBpcyBvZiBpbnRlcmVzdC4gIElmIG5vdCBwcmVzZW50 LCBldmVudHMgaW4gdGhlIGRlZmF1bHQKICAgICAgICAgTkVUQ09ORiBzdHJlYW0gd2lsbCBiZSBz ZW50LgoKICAgICAgRmlsdGVyOgoKICAgICAgICAgQW4gb3B0aW9uYWwgcGFyYW1ldGVyLCAmbHQ7 ZmlsdGVyJmd0OywgdGhhdCBpbmRpY2F0ZXMgd2hpY2ggc3Vic2V0IG9mCiAgICAgICAgIGFsbCBw b3NzaWJsZSBldmVudHMgaXMgb2YgaW50ZXJlc3QuICBUaGUgZm9ybWF0IG9mIHRoaXMKICAgICAg ICAgcGFyYW1ldGVyIGlzIHRoZSBzYW1lIGFzIHRoYXQgb2YgdGhlIGZpbHRlciBwYXJhbWV0ZXIg aW4gdGhlCiAgICAgICAgIE5FVENPTkYgcHJvdG9jb2wgb3BlcmF0aW9ucy4gIElmIG5vdCBwcmVz ZW50LCBhbGwgZXZlbnRzIG5vdAogICAgICAgICBwcmVjbHVkZWQgYnkgb3RoZXIgcGFyYW1ldGVy cyB3aWxsIGJlIHNlbnQuICBTZWUgc2VjdGlvbiAzLjYKICAgICAgICAgZm9yIG1vcmUgaW5mb3Jt YXRpb24gb24gZmlsdGVycy4KCiAgICAgIFN0YXJ0IFRpbWU6CgogICAgICAgICBBIHBhcmFtZXRl ciwgJmx0O3N0YXJ0VGltZSZndDssIHVzZWQgdG8gdHJpZ2dlciB0aGUgcmVwbGF5IGZlYXR1cmUK ICAgICAgICAgYW5kIGluZGljYXRlIHRoYXQgdGhlIHJlcGxheSBzaG91bGQgc3RhcnQgYXQgdGhl IHRpbWUKICAgICAgICAgc3BlY2lmaWVkLiAgSWYgJmx0O3N0YXJ0VGltZSZndDsgaXMgbm90IHBy ZXNlbnQsIHRoaXMgaXMgbm90IGEgcmVwbGF5CiAgICAgICAgIHN1YnNjcmlwdGlvbi4gIEl0IGlz IG5vdCB2YWxpZCB0byBzcGVjaWZ5IHN0YXJ0IHRpbWVzIHRoYXQgYXJlCiAgICAgICAgIGxhdGVy IHRoYW4gdGhlIGN1cnJlbnQgdGltZS4gIElmIHRoZSAmbHQ7c3RhcnRUaW1lJmd0OyBzcGVjaWZp ZWQgaXMKICAgICAgICAgZWFybGllciB0aGFuIHRoZSBsb2cgY2FuIHN1cHBvcnQsIHRoZSByZXBs YXkgd2lsbCBiZWdpbiB3aXRoCiAgICAgICAgIHRoZSBlYXJsaWVzdCBhdmFpbGFibGUgbm90aWZp Y2F0aW9uLiAgVGhpcyBwYXJhbWV0ZXIgaXMgb2YgdHlwZQogICAgICAgICA8c3RyaWtlPjxmb250 IGNvbG9yPSdyZWQnPmRhdGVUaW1lLjwvZm9udD48L3N0cmlrZT4KICAgICAgICAgPHN0cm9uZz48 Zm9udCBjb2xvcj0nZ3JlZW4nPmRhdGVUaW1lIGFuZCBjb21wbGlhbnQgdG8gW1JGQzMzMzldIGFu ZCBbSVNPLjg2MDEuMTk4OF0uCgogICAgICAgICBJbXBsZW1lbnRhdGlvbnMgbXVzdCBzdXBwb3J0 IHRpbWUgem9uZXMuPC9mb250Pjwvc3Ryb25nPgoKICAgICAgU3RvcCBUaW1lOgoKICAgICAgICAg QW4gb3B0aW9uYWwgcGFyYW1ldGVyLCAmbHQ7c3RvcFRpbWUmZ3Q7LCB1c2VkIHdpdGggdGhlIG9w dGlvbmFsCiAgICAgICAgIHJlcGxheSBmZWF0dXJlIHRvIGluZGljYXRlIHRoZSBuZXdlc3Qgbm90 aWZpY2F0aW9ucyBvZgogICAgICAgICBpbnRlcmVzdC4gIElmIHN0b3AgdGltZSBpcyBub3QgcHJl c2VudCwgdGhlIG5vdGlmaWNhdGlvbnMgd2lsbAogICAgICAgICBjb250aW51ZSB1bnRpbCB0aGUg c3Vic2NyaXB0aW9uIGlzIHRlcm1pbmF0ZWQuICBNdXN0IGJlIHVzZWQKICAgICAgICAgd2l0aCBh bmQgYmUgbGF0ZXIgdGhhbiAmbHQ7c3RhcnRUaW1lJmd0Oy4gIFZhbHVlcyBvZiAmbHQ7c3RvcFRp bWUmZ3Q7IGluCiAgICAgICAgIHRoZSBmdXR1cmUgYXJlIHZhbGlkLiAgVGhpcyBwYXJhbWV0ZXIg aXMgb2YgdHlwZSA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPmRhdGVUaW1lLjwvZm9udD48L3N0 cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPmRhdGVUaW1lIGFuZAogICAgICAgICBj b21wbGlhbnQgdG8gW1JGQzMzMzldIGFuZCBbSVNPLjg2MDEuMTk4OF0uICBJbXBsZW1lbnRhdGlv bnMKICAgICAgICAgbXVzdCBzdXBwb3J0IHRpbWUgem9uZXMuPC9mb250Pjwvc3Ryb25nPgoKICAg UG9zaXRpdmUgUmVzcG9uc2U6CgogICAgICBJZiB0aGUgTkVUQ09ORiBzZXJ2ZXIgY2FuIHNhdGlz ZnkgdGhlIHJlcXVlc3QsIHRoZSBzZXJ2ZXIgc2VuZHMgYW4KICAgICAgJmx0O29rJmd0OyBlbGVt ZW50LgoKICAgTmVnYXRpdmUgUmVzcG9uc2U6CgogICAgICBBbiAmbHQ7cnBjLWVycm9yJmd0OyBl bGVtZW50IGlzIGluY2x1ZGVkIHdpdGhpbiB0aGUgJmx0O3JwYy1yZXBseSZndDsgaWYgdGhlCiAg ICAgIHJlcXVlc3QgY2Fubm90IGJlIGNvbXBsZXRlZCBmb3IgYW55IHJlYXNvbi4gIFN1YnNjcmlw dGlvbiByZXF1ZXN0cwogICAgICB3aWxsIGZhaWwgaWYgYSBmaWx0ZXIgd2l0aCBpbnZhbGlkIHN5 bnRheCBpcyBwcm92aWRlZCBvciBpZiB0aGUKICAgICAgbmFtZSBvZiBhIG5vbi1leGlzdGVudCBz dHJlYW0gaXMgcHJvdmlkZWQuCgogICAgICBJZiBhICZsdDtzdG9wVGltZSZndDsgaXMgc3BlY2lm aWVkIGluIGEgcmVxdWVzdCB3aXRob3V0IGhhdmluZyBzcGVjaWZpZWQKICAgICAgYSAmbHQ7c3Rh cnRUaW1lJmd0OywgdGhlIGZvbGxvd2luZyBlcnJvciBpcyByZXR1cm5lZDoKCiAgICAgICAgIFRh ZzogbWlzc2luZy1lbGVtZW50CgogICAgICAgICBFcnJvci10eXBlOiBwcm90b2NvbAoKICAgICAg ICAgU2V2ZXJpdHk6IGVycm9yCgogICAgICAgICBFcnJvci1pbmZvOiAmbHQ7YmFkLWVsZW1lbnQm Z3Q7OiBzdGFydFRpbWUKCiAgICAgICAgIERlc2NyaXB0aW9uOiBBbiBleHBlY3RlZCBlbGVtZW50 IGlzIG1pc3NpbmcuCgogICAgICBJZiB0aGUgb3B0aW9uYWwgcmVwbGF5IGZlYXR1cmUgaXMgcmVx dWVzdGVkIGJ1dCBpdCBpcyBub3QKICAgICAgc3VwcG9ydGVkIGJ5IHRoZSBORVRDT05GIHNlcnZl ciwgdGhlIGZvbGxvd2luZyBlcnJvciBpcyByZXR1cm5lZDoKCiAgICAgICAgIFRhZzogb3BlcmF0 aW9uLWZhaWxlZAoKICAgICAgICAgRXJyb3ItdHlwZTogcHJvdG9jb2wKICAgICAgICAgU2V2ZXJp dHk6IGVycm9yCgogICAgICAgICBFcnJvci1pbmZvOiBub25lCgogICAgICAgICBEZXNjcmlwdGlv bjogUmVxdWVzdCBjb3VsZCBub3QgYmUgYozLiAgU3VwcG9ydGluZyBD b25jZXB0cwoKMy4xLiAgQ2FwYWJpbGl0aWVzIEV4Y2hhbmdlCgogICBUaGUgYWJpbGl0eSB0byBw cm9jZXNzIGFuZCBzZW5kIGV2ZW50IG5vdGlmaWNhdGlvbnMgaXMgYWR2ZXJ0aXNlZAogICBkdXJp bmcgdGhlIGNhcGFiaWxpdHkgZXhjaGFuZ2UgYmV0d2VlbiB0aGUgTkVUQ09ORiBjbGllbnQgYW5k IHNlcnZlci4KCjMuMS4xLiAgQ2FwYWJpbGl0eSBJZGVudGlmaWVyCgogICAidXJuOmlldGY6cGFy YW1zOm5ldGNvbmY6Y2FwYWJpbGl0eTpub3RpZmljYXRpb246MS4wIgoKMy4xLjIuICBDYXBhYmls aXR5IEV4YW1wbGUKCiAgICZsdDtoZWxsbyB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpu ZXRjb25mOmJhc2U6MS4wIiZndDsKICAgICAmbHQ7Y2FwYWJpbGl0aWVzJmd0OwogICAgICAgICZs dDtjYXBhYmlsaXR5Jmd0OwogICAgICAgICAgICB1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNv bmY6YmFzZToxLjAKICAgICAgICAgICZsdDsvY2FwYWJpbGl0eSZndDsKICAgICAgICAgICZsdDtj YXBhYmlsaXR5Jmd0OwogICAgICAgICAgICB1cm46aWV0ZjpwYXJhbXM6bmV0Y29uZjpjYXBhYmls aXR5OnN0YXJ0dXA6MS4wCiAgICAgICAgICAmbHQ7L2NhcGFiaWxpdHkmZ3Q7CiAgICAgICAgICAm bHQ7Y2FwYWJpbGl0eSZndDsKICAgICAgICAgICAgdXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6Y2Fw YWJpbGl0eTpub3RpZmljYXRpb246MS4wCiAgICAgICAgICAmbHQ7L2NhcGFiaWxpdHkmZ3Q7CiAg ICAgICAmbHQ7L2NhcGFiaWxpdGllcyZndDsKICAgICAmbHQ7c2Vzc2lvbi1pZCZndDs0Jmx0Oy9z ZXNzaW9uLWlkJmd0OwogICAmbHQ7L2hlbGxvJmd0OwoKMy4yLiAgRXZlbnQgU3RyZWFtcwoKICAg QW4gZXZlbnQgc3RyZWFtIGlzIGRlZmluZWQgYXMgYSBzZXQgb2YgZXZlbnQgbm90aWZpY2F0aW9u cyBtYXRjaGluZwogICBzb21lIGZvcndhcmRpbmcgY3JpdGVyaWEuCgogICBGaWd1cmUgMiBpbGx1 c3RyYXRlcyB0aGUgbm90aWZpY2F0aW9uIGZsb3cgYW5kIGNvbmNlcHRzIGlkZW50aWZpZWQgaW4K ICAgdGhpcyBkb2N1bWVudC4gIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5JdCBkb2VzIG5v dCBtYW5kYXRlIGFuZC9vciBwcmVjbHVkZSBhbgogICBpbXBsZW1lbnRhdGlvbi48L2ZvbnQ+PC9z dHJvbmc+ICBUaGUgZm9sbG93aW5nIGlzIG9ic2VydmVkIGZyb20gdGhlIGRpYWdyYW0gYmVsb3c6 CiAgIFN5c3RlbSBjb21wb25lbnRzIChjMS4uY24pIGdlbmVyYXRlIGV2ZW50IG5vdGlmaWNhdGlv bnMgd2hpY2ggYXJlCiAgIHBhc3NlZCB0byBhIGNlbnRyYWwgY29tcG9uZW50IGZvciBjbGFzc2lm aWNhdGlvbiBhbmQgZGlzdHJpYnV0aW9uLgogICBUaGUgY2VudHJhbCBjb21wb25lbnQgaW5zcGVj dHMgZWFjaCBldmVudCBub3RpZmljYXRpb24gYW5kIG1hdGNoZXMKICAgdGhlIGV2ZW50IG5vdGlm aWNhdGlvbiBhZ2FpbnN0IHRoZSBzZXQgb2Ygc3RyZWFtIGRlZmluaXRpb25zLiAgV2hlbiBhCiAg IG1hdGNoIG9jY3VycywgdGhlIGV2ZW50IG5vdGlmaWNhdGlvbiBpcyBjb25zaWRlcmVkIHRvIGJl IGEgbWVtYmVyIG9mCiAgIHRoYXQgZXZlbnQgc3RyZWFtIChzdHJlYW0gMS4uc3RyZWFtIG4pLiAg QW4gZXZlbnQgbm90aWZpY2F0aW9uIG1heSBiZQogICBwYXJ0IG9mIG11bHRpcGxlIGV2ZW50IHN0 cmVhbXMuCgogICBBdCBzb21lIHBvaW50IGFmdGVyIHRoZSBORVRDT05GIHNlcnZlciByZWNlaXZl cyB0aGUgaW50ZXJuYWwgZXZlbnQKICAgZnJvbSBhIHN0cmVhbSwgaXQgaXMgY29udmVydGVkIHRv IGFuIGFwcHJvcHJpYXRlIFhNTCBlbmNvZGluZyBieSB0aGUKICAgc2VydmVyLCBhbmQgYSAmbHQ7 bm90aWZpY2F0aW9uJmd0OyBlbGVtZW50IGlzIHJlYWR5IHRvIHNlbmQgdG8gYWxsIE5FVENPTkYK ICAgc2Vzc2lvbnMgc3Vic2NyaWJlZCB0byB0aGF0IHN0cmVhbS4KCiAgIEFmdGVyIGdlbmVyYXRp b24gb2YgdGhlICZsdDtub3RpZmljYXRpb24mZ3Q7IGVsZW1lbnQsIGFjY2VzcyBjb250cm9sIGlz CiAgIGFwcGxpZWQgYnkgdGhlIHNlcnZlci4gIElmIGEgc2Vzc2lvbiBkb2VzIG5vdCBoYXZlIHBl cm1pc3Npb24gdG8KICAgcmVjZWl2ZSB0aGUgJmx0O25vdGlmaWNhdGlvbiZndDssIHRoZW4gaXQg aXMgZGlzY2FyZGVkIGZvciB0aGF0IHNlc3Npb24sCiAgIGFuZCBwcm9jZXNzaW5nIG9mIHRoZSBp bnRlcm5hbCBldmVudCBpcyBjb21wbGV0ZWQgZm9yIHRoYXQgc2Vzc2lvbi4KCiAgIFdoZW4gYSBO RVRDT05GIGNsaWVudCBzdWJzY3JpYmVzIHRvIGEgZ2l2ZW4gZXZlbnQgc3RyZWFtLCB1c2VyLQog ICBkZWZpbmVkIGZpbHRlciBlbGVtZW50cywgaWYgYXBwbGljYWJsZSwgYXJlIGFwcGxpZWQgdG8g dGhlIGV2ZW50CiAgIHN0cmVhbSBhbmQgbWF0Y2hpbmcgZXZlbnQgbm90aWZpY2F0aW9ucyBhcmUg Zm9yd2FyZGVkIHRvIHRoZSBORVRDT05GCiAgIHNlcnZlciBmb3IgZGlzdHJpYnV0aW9uIHRvIHN1 YnNjcmliZWQgTkVUQ09ORiBjbGllbnRzLiAgQSBmaWx0ZXIgaXMKICAgdHJhbnNmZXJyZWQgZnJv bSB0aGUgY2xpZW50IHRvIHRoZSBzZXJ2ZXIgZHVyaW5nIHRoZSAmbHQ7Y3JlYXRlLQogICBzdWJz Y3JpcHRpb24mZ3Q7IG9wZXJhdGlvbiBhbmQgYXBwbGllZCBhZ2FpbnN0IGVhY2ggJmx0O25vdGlm aWNhdGlvbiZndDsKICAgZWxlbWVudCBnZW5lcmF0ZWQgYnkgdGhlIHN0cmVhbS4gIEZvciBtb3Jl IGluZm9ybWF0aW9uIG9uIGZpbHRlcmluZywKICAgc2VlIHNlY3Rpb24gMy42LgoKICAgQSBub3Rp ZmljYXRpb24gbG9nZ2luZyBzZXJ2aWNlIG1heSBhbHNvIGJlIGF2YWlsYWJsZSwgaW4gd2hpY2gg Y2FzZSwKICAgdGhlIGNlbnRyYWwgY29tcG9uZW50IGxvZ3Mgbm90aWZpY2F0aW9ucy4gIFRoZSBO RVRDT05GIHNlcnZlciBtYXkKICAgbGF0ZXIgcmV0cmlldmUgbG9nZ2VkIG5vdGlmaWNhdGlvbnMg dmlhIHRoZSBvcHRpb25hbCByZXBsYXkgZmVhdHVyZS4KICAgRm9yIG1vcmUgaW5mb3JtYXRpb24g b24gcmVwbGF5LCBzZWUgc2VjdGlvbiAzLjMuCgogICArLS0tLSsKICAgfCBjMSB8LS0tL29tcGxldGVkIGJlY2F1c2UgdGhlCiAgICAgICAgIHJl cXVlc3RlZCBvcGVyYXRpb24gZmFpbGVkIGZvciBzb21lIHJlYXNvbiBub3QgY292ZXJlZCBieSBh bnkKICAgICAgICAgb3RoZXIgZXJyb3IgY29uZGl0aW9uCgogICAgICBJZiBhICZsdDtzdG9wVGlt ZSZndDsgaXMgcmVxdWVzdGVkIHdoaWNoIGlzIGVhcmxpZXIgdGhlbiB0aGUgc3BlY2lmaWVkCiAg ICAgICZsdDtzdGFydFRpbWUmZ3Q7LCB0aGUgZm9sbG93aW5nIGVycm9yIGlzIHJldHVybmVkOgoK ICAgICAgICAgVGFnOiBiYWQtZWxlbWVudAoKICAgICAgICAgRXJyb3ItdHlwZTogcHJvdG9jb2wK CiAgICAgICAgIFNldmVyaXR5OiBlcnJvcgoKICAgICAgICAgRXJyb3ItaW5mbzogJmx0O2JhZC1l bGVtZW50Jmd0Ozogc3RvcFRpbWUKCiAgICAgICAgIERlc2NyaXB0aW9uOiBBbiBlbGVtZW50IHZh bHVlIGlzIG5vdCBjb3JyZWN0OyBlLmcuLCB3cm9uZyB0eXBlLAogICAgICAgICBvdXQgb2YgcmFu Z2UsIHBhdHRlcm4gbWlzbWF0Y2guCgogICAgICBJZiBhICZsdDtzdGFydFRpbWUmZ3Q7IGlzIHJl cXVlc3RlZCB3aGljaCBpcyBsYXRlciB0aGVuIHRoZSBjdXJyZW50CiAgICAgIHRpbWUsIHRoZSBm b2xsb3dpbmcgZXJyb3IgaXMgcmV0dXJuZWQ6CgogICAgICAgICBUYWc6IGJhZC1lbGVtZW50Cgog ICAgICAgICBFcnJvci10eXBlOiBwcm90b2NvbAoKICAgICAgICAgU2V2ZXJpdHk6IGVycm9yCgog ICAgICAgICBFcnJvci1pbmZvOiAmbHQ7YmFkLWVsZW1lbnQmZ3Q7OiBzdGFydFRpbWUKCiAgICAg ICAgIERlc2NyaXB0aW9uOiBBbiBlbGVtZW50IHZhbHVlIGlzIG5vdCBjb3JyZWN0OyBlLmcuLCB3 cm9uZyB0eXBlLAogICAgICAgICBvdXQgb2YgcmFuZ2UsIHBhdHRlcm4gbWlzbWF0Y2guCgoyLjEu MS4xLiAgVXNhZ2UgRXhhbXBsZQoKICAgVGhlIGZvbGxvd2luZyBkZW1vbnN0cmF0ZXMgY3JlYXRp bmcgYSBzaW1wbGUgc3Vic2NyaXB0aW9uLiAgTW9yZQogICBjb21wbGV4IGV4YW1wbGVzIGNhbiBi ZSBmb3VuZCBpbiBzZWN0aW9uIDUuCgogICAmbHQ7bmV0Y29uZjpycGMgbWVzc2FnZS1pZD0iMTAx IgogICAgICAgICB4bWxuczpuZXRjb25mPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6 YmFzZToxLjAiLyZndDsKICAgICAgICZsdDtjcmVhdGUtc3Vic2NyaXB0aW9uCiAgICAgICAgICAg eG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRpb246MS4wIiZn dDsKICAgICAgICZsdDsvY3JlYXRlLXN1YnNjcmlwdGlvbiZndDsKICAgJmx0Oy9uZXRjb25mOnJw YyZndDsKCjIuMi4gIFNlbmRpbmcgRXZlbnQgTm90aWZpY2F0aW9ucwoKICAgT25jZSB0aGUgc3Vi c2NyaXB0aW9uIGhhcyBiZWVuIHNldCB1cCwgdGhlIE5FVENPTkYgc2VydmVyIHNlbmRzIHRoZQog ICBldmVudCBub3RpZmljYXRpb25zIGFzeW5jaHJvbm91c2x5IG92ZXIgdGhlIGNvbm5lY3Rpb24u CgoyLjIuMS4gICZsdDtub3RpZmljYXRpb24mZ3Q7CgogICBEZXNjcmlwdGlvbjoKCiAgICAgIEFu IGV2ZW50IG5vdGlmaWNhdGlvbiBpcyBzZW50IHRvIHRoZSBjbGllbnQgd2hvIGluaXRpYXRlZCBh CiAgICAgICZsdDtjcmVhdGUtc3Vic2NyaXB0aW9uJmd0OyBjb21tYW5kIGFzeW5jaHJvbm91c2x5 IHdoZW4gYW4gZXZlbnQgb2YKICAgICAgaW50ZXJlc3QgKGkuZS4sIG1lZXRpbmcgdGhlIHNwZWNp ZmllZCBmaWx0ZXJpbmcgY3JpdGVyaWEpIGhhcwogICAgICBvY2N1cnJlZC4gIEFuIGV2ZW50IG5v dGlmaWNhdGlvbiBpcyBhIGNvbXBsZXRlIGFuZCB3ZWxsLWZvcm1lZCBYTUwKICAgICAgZG9jdW1l bnQuICBOb3RlIHRoYXQgJmx0O25vdGlmaWNhdGlvbiZndDsgaXMgbm90IGFuIFJQQyBtZXRob2Qg YnV0CiAgICAgIHJhdGhlciB0aGUgdG9wIGxldmVsIGVsZW1lbnQgaWRlbnRpZnlpbmcgdGhlIG9u ZS13YXkgbWVzc2FnZSBhcyBhCiAgICAgIG5vdGlmaWNhdGlvbi4KCiAgIFBhcmFtZXRlcnM6Cgog ICAgICBldmVudFRpbWUKCiAgICAgICAgIFRoZSB0aW1lIHRoZSBldmVudCB3YXMgZ2VuZXJhdGVk IGJ5IHRoZSBldmVudCBzb3VyY2UuICBUaGlzCiAgICAgICAgIHBhcmFtZXRlciBpcyBvZiB0eXBl IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+ZGF0ZVRpbWUuPC9mb250Pjwvc3RyaWtlPiA8c3Ry b25nPjxmb250IGNvbG9yPSdncmVlbic+ZGF0ZVRpbWUgYW5kIGNvbXBsaWFudCB0byBbUkZDMzMz OV0gYW5kCiAgICAgICAgIFtJU08uODYwMS4xOTg4XS4gIEltcGxlbWVudGF0aW9ucyBtdXN0IHN1 cHBvcnQgdGltZSB6b25lcy48L2ZvbnQ+PC9zdHJvbmc+CgogICAgICBBbHNvIGNvbnRhaW5zIG5v dGlmaWNhdGlvbi1zcGVjaWZpYyB0YWdnZWQgY29udGVudCwgaWYgYW55LiAgV2l0aAogICAgICB0 aGUgZXhjZXB0aW9uIG9mICZsdDtldmVudFRpbWUmZ3Q7LCB0aGUgY29udGVudCBvZiB0aGUgbm90 aWZpY2F0aW9uIGlzCiAgICAgIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4KCiAg IFJlc3BvbnNlOgoKICAgICAgTm8gcmVzcG9uc2UuICBOb3QgYXBwbGljYWJsZS4KCjIuMy4gIFRl cm1pbmF0aW5nIHRoZSBTdWJzY3JpcHRpb24KCiAgIENsb3Npbmcgb2YgdGhlIGV2ZW50IG5vdGlm aWNhdGlvbiBzdWJzY3JpcHRpb24gY2FuIGJlIGRvbmUgYnkgdXNpbmcKICAgdGhlICZsdDtjbG9z ZS1zZXNzaW9uJmd0OyBvcGVyYXRpb24gZnJvbSB0aGUgc3Vic2NyaXB0aW9ucyBzZXNzaW9uIG9y CiAgIHRlcm1pbmF0aW5nIHRoZSBORVRDT05GIHNlc3Npb24gKCAmbHQ7a2lsbC1zZXNzaW9uJmd0 OyApIG9yIHRoZSB1bmRlcmx5aW5nCiAgIHRyYW5zcG9ydCBzZXNzaW9uIGZyb20gYW5vdGhlciBz ZXNzaW9uLiAgSWYgYSBzdG9wIHRpbWUgaXMgcHJvdmlkZWQKICAgd2hlbiB0aGUgc3Vic2NyaXB0 aW9uIGlzIGNyZWF0ZWQsIHRoZSBzdWJzY3JpcHRpb24gd2lsbCB0ZXJtaW5hdGUKICAgYWZ0ZXIg dGhlIHN0b3AgdGltZSBpcyByZWFjaGVkLiAgSW4gdGhpcyBjYXNlLCB0aGUgTkVUQ09ORiBzZXNz aW9uCiAgIHdpbGwgc3RpbGwgYmUgYW4gYWN0aXZlIHNlc3NpSsgICAg ICAgICAgICAgYXZhaWxhYmxlIHN0cmVhbXMKICAgKy0tLS0rICAgIHwgICAgKy0tLS0tLS0tLSsK ICAgKy0tLS0rICAgIHwgICAgfGNlbnRyYWwgIHwtJmd0OyBzdHJlYW0gMQogICB8IGMyIHwgICAg Ky0tLSZndDt8ZXZlbnQgICAgfC0mZ3Q7IHN0cmVhbSAyICAgICBmaWx0ZXIgICstLS0tLS0tKwog ICArLS0tLSsgICAgfCAgICB8cHJvY2Vzc29yfC0mZ3Q7IE5FVENPTkYgc3RyZWFtIC0tLS0tJmd0 O3xORVRDT05GfAogICAgLi4uICAgICAgfCAgICB8ICAgICAgICAgfC0mZ3Q7IHN0cmVhbSBuICAg ICAgICAgICAgIHxzZXJ2ZXIgfAogICBTeXN0ZW0gICAgfCAgICArLS0tLS0tLS0tKyAgICAgICAg ICAgICAgICAgICAgICAgICstLS0tLS0tKwogICBDb21wb25lbnRzfCAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC9cCiAgICAuLi4gICAgICB8ICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfHwKICAgKy0tLS0rICAgIHwgICAgICAgIHwgICAg ICAgKC0tLS0tLS0tLS0tLSkgICAgICAgICAgICB8fAogICB8IGNuIHwtLS0tKyAgICAgICAgfCAg ICAgICAobm90aWZpY2F0aW9uKSAgICAgICAgICAgIHx8CiAgICstLS0tKyAgICAgICAgICAgICAr LS0tLS0mZ3Q7ICggIGxvZ2dpbmcgICApICAgICAgICAgICAgfHwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKCAgc2VydmljZSAgICkgICAgICAgICAgICB8fAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAoLS0tLS0tLS0tLS0tKSAgICAgICAgICAgIHx8CiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfHwKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8fAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwvCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLSsKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHxORVRDT05G fAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfGNs aWVudCB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICArLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDIKCjMu Mi4xLiAgRXZlbnQgU3RyZWFtIERlZmluaXRpb24KCiAgIEV2ZW50IHN0cmVhbXMgYXJlIHByZWRl ZmluZWQgb24gdGhlIG1hbmFnZWQgZGV2aWNlLiAgVGhlCiAgIGNvbmZpZ3VyYXRpb24gb2YgZXZl bnQgc3RyZWFtcyBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LgogICBIb3dl dmVyLCBpdCBpcyBlbnZpc2lvbmVkIHRoYXQgZXZlbnQgc3RyZWFtcyBhcmUgZWl0aGVyIHByZS0K ICAgZXN0YWJsaXNoZWQgYnkgdGhlIHZlbmRvciAocHJlLWNvbmZpZ3VyZWQpLCB1c2VyIGNvbmZp Z3VyYWJsZSAoZS5nLiwKICAgcGFydCBvZiB0aGUgZGV2aWNlJ3MgY29uZmlndXJhdGlvbikgb3Ig Ym90aC4gIERldmljZSB2ZW5kb3JzIG1heQogICBhbGxvdyBldmVudCBzdHJlYW0gY29uZmlndXJh dGlvbiB2aWEgdGhlIE5FVENPTkYgcHJvdG9jb2wgKGkuZS4sCiAgICZsdDtlZGl0LWNvbmZpZyZn dDsgb3BlcmF0aW9uKS4KCjMuMi4yLiAgRXZlbnQgU3RyZWFtIENvbnRlbnQgRm9ybWF0CgogICBU aGUgY29udGVudHMgb2YgYWxsIGV2ZW50IHN0cmVhbXMgbWFkZSBhdmFpbGFibGUgdG8gYSBORVRD T05GIGNsaWVudAogICAoaS5lLiwgdGhlIG5vdGlmaWNhdGlvbiBzZW50IGJ5IHRoZSBORVRDT05G IHNlcnZlcikgTVVTVCBiZSBlbmNvZGVkCiAgIGluIFhNTC4KCjMuMi4zLiAgRGVmYXVsdCBFdmVu dCBTdHJlYW0KCiAgIEEgTkVUQ09ORiBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gc3VwcG9ydGluZyB0 aGUgbm90aWZpY2F0aW9uCiAgIGNhcGFiaWxpdHkgTVVTVCBzdXBwb3J0IHRoZSAiTkVUQ09ORiIg bm90aWZpY2F0aW9uIGV2ZW50IHN0cmVhbS4KICAgVGhpcyBzdHJlYW0gY29udGFpbnMgYWxsIE5F VENPTkYgWE1MIGV2ZW50IG5vdGlmaWNhdGlvbnMgc3VwcG9ydGVkIGJ5CiAgIHRoZSBORVRDT05G IHNlcnZlci4gIFRoZSBleGFjdCBzdHJpbmcgIk5FVENPTkYiIGlzIHVzZWQgZHVyaW5nCiAgIGFk dmVydGlzZW1lbnQgb2Ygc3RyZWFtIHN1cHBvcnQgZHVyaW5nIHRoZSAmbHQ7Z2V0Jmd0OyBvcGVy YXRpb24gb24KICAgJmx0O3N0cmVhbXMmZ3Q7IGFuZCBkdXJpbmcgdGhlICZsdDtjcmVhdGUtc3Vi c2NyaXB0aW9uJmd0OyBvcGVyYXRpb24uICBEZWZpbml0aW9uCiAgIG9mIHRoZSBldmVudCBub3Rp ZmljYXRpb25zIGFuZCB0aGVpciBjb250ZW50cywgYmV5b25kIHRoZSBpbmNsdXNpb24KICAgb2Yg Jmx0O2V2ZW50VGltZSZndDssIGZvciB0aGlzIGV2ZW50IHN0cmVhbSBpcyBvdXRzaWRlIHRoZSBz Y29wZSBvZiB0aGlzCiAgIGRvY3VtZW50LgoKMy4yLjQuICBFdmVudCBTdHJlYW0gU291cmNlcwoK ICAgV2l0aCB0aGUgZXhjZXB0aW9uIG9mIHRoZSBkZWZhdWx0IGV2ZW50IHN0cmVhbSAoTkVUQ09O RiksCiAgIHNwZWNpZmljYXRpb24gb2YgYWRkaXRpb25hbCBldmVudCBzdHJlYW0gc291cmNlcyAo ZS5nLiwgU05NUCwgc3lzbG9nKQogICBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3Vt ZW50LiAgTkVUQ09ORiBzZXJ2ZXIKICAgaW1wbGVtZW50YXRpb25zIG1heSBsZXZlcmFnZSBhbnkg ZGVzaXJlZCBldmVudCBzdHJlYW0gc291cmNlIGluIHRoZQogICBjcmVhdGlvbiBvZiBzdXBwb3J0 ZWQgZXZlbnQgc3RyZWFtcy4KCjMuMi41LiAgRXZlbnQgU3RyZWFtIERpc2NvdmVyeQoKICAgQSBO RVRDT05GIGNsaWVudCByZXRyaWV2ZXMgdGhlIGxpc3Qgb2Ygc3VwcG9ydGVkIGV2ZW50IHN0cmVh bXMgZnJvbSBhCiAgIE5FVENPTkYgc2VydmVyIHVzaW5nIHRoZSAmbHQ7Z2V0Jmd0OyBvcGVyYXRp b24uCgob24uCgozLiAgU3VwcG9ydGluZyBD b25jZXB0cwoKMy4xLiAgQ2FwYWJpbGl0aWVzIEV4Y2hhbmdlCgogICBUaGUgYWJpbGl0eSB0byBw cm9jZXNzIGFuZCBzZW5kIGV2ZW50IG5vdGlmaWNhdGlvbnMgaXMgYWR2ZXJ0aXNlZAogICBkdXJp bmcgdGhlIGNhcGFiaWxpdHkgZXhjaGFuZ2UgYmV0d2VlbiB0aGUgTkVUQ09ORiBjbGllbnQgYW5k IHNlcnZlci4KCjMuMS4xLiAgQ2FwYWJpbGl0eSBJZGVudGlmaWVyCgogICAidXJuOmlldGY6cGFy YW1zOm5ldGNvbmY6Y2FwYWJpbGl0eTpub3RpZmljYXRpb246MS4wIgoKMy4xLjIuICBDYXBhYmls aXR5IEV4YW1wbGUKCiAgICZsdDtoZWxsbyB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpu ZXRjb25mOmJhc2U6MS4wIiZndDsKICAgICAmbHQ7Y2FwYWJpbGl0aWVzJmd0OwogICAgICAgICZs dDtjYXBhYmlsaXR5Jmd0OwogICAgICAgICAgICB1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNv bmY6YmFzZToxLjAKICAgICAgICAgICZsdDsvY2FwYWJpbGl0eSZndDsKICAgICAgICAgICZsdDtj YXBhYmlsaXR5Jmd0OwogICAgICAgICAgICB1cm46aWV0ZjpwYXJhbXM6bmV0Y29uZjpjYXBhYmls aXR5OnN0YXJ0dXA6MS4wCiAgICAgICAgICAmbHQ7L2NhcGFiaWxpdHkmZ3Q7CiAgICAgICAgICAm bHQ7Y2FwYWJpbGl0eSZndDsKICAgICAgICAgICAgdXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6Y2Fw YWJpbGl0eTpub3RpZmljYXRpb246MS4wCiAgICAgICAgICAmbHQ7L2NhcGFiaWxpdHkmZ3Q7CiAg ICAgICAmbHQ7L2NhcGFiaWxpdGllcyZndDsKICAgICAmbHQ7c2Vzc2lvbi1pZCZndDs0Jmx0Oy9z ZXNzaW9uLWlkJmd0OwogICAmbHQ7L2hlbGxvJmd0OwoKMy4yLiAgRXZlbnQgU3RyZWFtcwoKICAg QW4gZXZlbnQgc3RyZWFtIGlzIGRlZmluZWQgYXMgYSBzZXQgb2YgZXZlbnQgbm90aWZpY2F0aW9u cyBtYXRjaGluZwogICBzb21lIGZvcndhcmRpbmcgY3JpdGVyaWEuCgogICBGaWd1cmUgMiBpbGx1 c3RyYXRlcyB0aGUgbm90aWZpY2F0aW9uIGZsb3cgYW5kIGNvbmNlcHRzIGlkZW50aWZpZWQgaW4K ICAgdGhpcyBkb2N1bWVudC4gIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5JdCBkb2VzIG5v dCBtYW5kYXRlIGFuZC9vciBwcmVjbHVkZSBhbgogICBpbXBsZW1lbnRhdGlvbi48L2ZvbnQ+PC9z dHJvbmc+ICBUaGUgZm9sbG93aW5nIGlzIG9ic2VydmVkIGZyb20gdGhlIGRpYWdyYW0gYmVsb3c6 CiAgIFN5c3RlbSBjb21wb25lbnRzIChjMS4uY24pIGdlbmVyYXRlIGV2ZW50IG5vdGlmaWNhdGlv bnMgd2hpY2ggYXJlCiAgIHBhc3NlZCB0byBhIGNlbnRyYWwgY29tcG9uZW50IGZvciBjbGFzc2lm aWNhdGlvbiBhbmQgZGlzdHJpYnV0aW9uLgogICBUaGUgY2VudHJhbCBjb21wb25lbnQgaW5zcGVj dHMgZWFjaCBldmVudCBub3RpZmljYXRpb24gYW5kIG1hdGNoZXMKICAgdGhlIGV2ZW50IG5vdGlm aWNhdGlvbiBhZ2FpbnN0IHRoZSBzZXQgb2Ygc3RyZWFtIGRlZmluaXRpb25zLiAgV2hlbiBhCiAg IG1hdGNoIG9jY3VycywgdGhlIGV2ZW50IG5vdGlmaWNhdGlvbiBpcyBjb25zaWRlcmVkIHRvIGJl IGEgbWVtYmVyIG9mCiAgIHRoYXQgZXZlbnQgc3RyZWFtIChzdHJlYW0gMS4uc3RyZWFtIG4pLiAg QW4gZXZlbnQgbm90aWZpY2F0aW9uIG1heSBiZQogICBwYXJ0IG9mIG11bHRpcGxlIGV2ZW50IHN0 cmVhbXMuCgogICBBdCBzb21lIHBvaW50IGFmdGVyIHRoZSBORVRDT05GIHNlcnZlciByZWNlaXZl cyB0aGUgaW50ZXJuYWwgZXZlbnQKICAgZnJvbSBhIHN0cmVhbSwgaXQgaXMgY29udmVydGVkIHRv IGFuIGFwcHJvcHJpYXRlIFhNTCBlbmNvZGluZyBieSB0aGUKICAgc2VydmVyLCBhbmQgYSAmbHQ7 bm90aWZpY2F0aW9uJmd0OyBlbGVtZW50IGlzIHJlYWR5IHRvIHNlbmQgdG8gYWxsIE5FVENPTkYK ICAgc2Vzc2lvbnMgc3Vic2NyaWJlZCB0byB0aGF0IHN0cmVhbS4KCiAgIEFmdGVyIGdlbmVyYXRp b24gb2YgdGhlICZsdDtub3RpZmljYXRpb24mZ3Q7IGVsZW1lbnQsIGFjY2VzcyBjb250cm9sIGlz CiAgIGFwcGxpZWQgYnkgdGhlIHNlcnZlci4gIElmIGEgc2Vzc2lvbiBkb2VzIG5vdCBoYXZlIHBl cm1pc3Npb24gdG8KICAgcmVjZWl2ZSB0aGUgJmx0O25vdGlmaWNhdGlvbiZndDssIHRoZW4gaXQg aXMgZGlzY2FyZGVkIGZvciB0aGF0IHNlc3Npb24sCiAgIGFuZCBwcm9jZXNzaW5nIG9mIHRoZSBp bnRlcm5hbCBldmVudCBpcyBjb21wbGV0ZWQgZm9yIHRoYXQgc2Vzc2lvbi4KCiAgIFdoZW4gYSBO RVRDT05GIGNsaWVudCBzdWJzY3JpYmVzIHRvIGEgZ2l2ZW4gZXZlbnQgc3RyZWFtLCB1c2VyLQog ICBkZWZpbmVkIGZpbHRlciBlbGVtZW50cywgaWYgYXBwbGljYWJsZSwgYXJlIGFwcGxpZWQgdG8g dGhlIGV2ZW50CiAgIHN0cmVhbSBhbmQgbWF0Y2hpbmcgZXZlbnQgbm90aWZpY2F0aW9ucyBhcmUg Zm9yd2FyZGVkIHRvIHRoZSBORVRDT05GCiAgIHNlcnZlciBmb3IgZGlzdHJpYnV0aW9uIHRvIHN1 YnNjcmliZWQgTkVUQ09ORiBjbGllbnRzLiAgQSBmaWx0ZXIgaXMKICAgdHJhbnNmZXJyZWQgZnJv bSB0aGUgY2xpZW50IHRvIHRoZSBzZXJ2ZXIgZHVyaW5nIHRoZSAmbHQ7Y3JlYXRlLQogICBzdWJz Y3JpcHRpb24mZ3Q7IG9wZXJhdGlvbiBhbmQgYXBwbGllZCBhZ2FpbnN0IGVhY2ggJmx0O25vdGlm aWNhdGlvbiZndDsKICAgZWxlbWVudCBnZW5lcmF0ZWQgYnkgdGhlIHN0cmVhbS4gIEZvciBtb3Jl IGluZm9ybWF0aW9uIG9uIGZpbHRlcmluZywKICAgc2VlIHNlY3Rpb24gMy42LgoKICAgQSBub3Rp ZmljYXRpb24gbG9nZ2luZyBzZXJ2aWNlIG1heSBhbHNvIGJlIGF2YWlsYWJsZSwgaW4gd2hpY2gg Y2FzZSwKICAgdGhlIGNlbnRyYWwgY29tcG9uZW50IGxvZ3Mgbm90aWZpY2F0aW9ucy4gIFRoZSBO RVRDT05GIHNlcnZlciBtYXkKICAgbGF0ZXIgcmV0cmlldmUgbG9nZ2VkIG5vdGlmaWNhdGlvbnMg dmlhIHRoZSBvcHRpb25hbCByZXBsYXkgZmVhdHVyZS4KICAgRm9yIG1vcmUgaW5mb3JtYXRpb24g b24gcmVwbGF5LCBzZWUgc2VjdGlvbiAzLjMuCgogICArLS0tLSsKICAgfCBjMSBzLjIuNS4xLiAgTmFtZSBSZXRyaWV2YWwgdXNpbmcgJmx0O2dldCZndDsgb3BlcmF0aW9u CgogICBUaGUgbGlzdCBvZiBhdmFpbGFibGUgZXZlbnQgc3RyZWFtcyBpcyByZXRyaWV2ZWQgYnkg cmVxdWVzdGluZyB0aGUKICAgJmx0O3N0cmVhbXMmZ3Q7IHN1YnRyZWUgdmlhIGEgJmx0O2dldCZn dDsgb3BlcmF0aW9uLiAgQXZhaWxhYmxlIGV2ZW50IHN0cmVhbXMgZm9yCiAgIHRoZSByZXF1ZXN0 aW5nIHNlc3Npb24gYXJlIHJldHVybmVkIGluIHRoZSByZXBseSBjb250YWluaW5nIHRoZQogICAm bHQ7bmFtZSZndDsgYW5kICZsdDtkZXNjcmlwdGlvbiZndDsgZWxlbWVudHMsIHdoZXJlIHRoZSAm bHQ7bmFtZSZndDsgZWxlbWVudCBpcwogICBtYW5kYXRvcnksIGFuZCBpdHMgdmFsdWUgaXMgdW5p cXVlIHdpdGhpbiB0aGUgc2NvcGUgb2YgYSBORVRDT05GCiAgIHNlcnZlci4gIEFuIGVtcHR5IHJl cGx5IGlzIHJldHVybmVkIGlmIHRoZXJlIGFyZSBubyBhdmFpbGFibGUgZXZlbnQKICAgc3RyZWFt cywgZHVlIHRvIHVzZXItc3BlY2lmaWVkIGZpbHRlcnMgb24gdGhlICZsdDtnZXQmZ3Q7IG9wZXJh dGlvbiAuCgogICBBZGRpdGlvbmFsIGluZm9ybWF0aW9uIGF2YWlsYWJsZSBhYm91dCBhIHN0cmVh bSBpbmNsdWRlIHdoZXRoZXIKICAgbm90aWZpY2F0aW9uIHJlcGxheSBpcyBhdmFpbGFibGUgYW5k IGlmIHNvLCB0aGUgdGltZXN0YW1wIG9mIHRoZQogICBlYXJsaWVzdCBwb3NzaWJsZSBub3RpZmlj YXRpb24gdG8gcmVwbGF5LgoKICAgVGhlIGZvbGxvd2luZyBleGFtcGxlIHNob3dzIHJldHJpZXZp bmcgdGhlIGxpc3Qgb2YgYXZhaWxhYmxlIGV2ZW50CiAgIHN0cmVhbSBsaXN0IHVzaW5nIHRoZSAm bHQ7Z2V0Jmd0OyBvcGVyYXRpb24uCgogICAmbHQ7cnBjIG1lc3NhZ2UtaWQ9IjEwMSIKICAgICAg eG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCImZ3Q7CiAgICAg Jmx0O2dldCZndDsKICAgICAgJmx0O2ZpbHRlciB0eXBlPSJzdWJ0cmVlIiZndDsKICAgICAgICAm bHQ7bmV0Y29uZiB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRtb2Q6bm90aWZpY2F0 aW9uIiZndDsKICAgICAgICAgICAmbHQ7c3RyZWFtcy8mZ3Q7CiAgICAgICAgICZsdDsvbmV0Y29u ZiZndDsKICAgICAgJmx0Oy9maWx0ZXImZ3Q7CiAgICAgJmx0Oy9nZXQmZ3Q7CiAgICZsdDsvcnBj Jmd0OwogICBUaGUgTkVUQ09ORiBzZXJ2ZXIgcmV0dXJucyBhIGxpc3Qgb2YgZXZlbnQgc3RyZWFt cyBhdmFpbGFibGUgZm9yCiAgIHN1YnNjcmlwdGlvbjogTkVUQ09ORiwgU05NUCwgYW5kIHN5c2xv Zy1jcml0aWNhbCBpbiB0aGlzIGV4YW1wbGUuCgogICAmbHQ7cnBjLXJlcGx5IG1lc3NhZ2UtaWQ9 IjEwMSIKICAgICAgICAgICAgICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpu ZXRjb25mOmJhc2U6MS4wIiZndDsKICAgICAmbHQ7ZGF0YSZndDsKICAgICAgICZsdDtuZXRjb25m ICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRtb2Q6bm90aWZpY2F0aW9uIiZndDsK ICAgICAgICAmbHQ7c3RyZWFtcyZndDsKICAgICAgICAgICAmbHQ7c3RyZWFtJmd0OwogICAgICAg ICAgICAgICZsdDtuYW1lJmd0O05FVENPTkYmbHQ7L25hbWUmZ3Q7CiAgICAgICAgICAgICAgJmx0 O2Rlc2NyaXB0aW9uJmd0O2RlZmF1bHQgTkVUQ09ORiBldmVudCBzdHJlYW0KICAgICAgICAgICAg ICAmbHQ7L2Rlc2NyaXB0aW9uJmd0OwogICAgICAgICAgICAgICZsdDtyZXBsYXlTdXBwb3J0Jmd0 O3RydWUmbHQ7L3JlcGxheVN1cHBvcnQmZ3Q7CiAgICAgICAgICAgICAgJmx0O3JlcGxheUxvZ0Ny ZWF0aW9uVGltZSZndDsKICAgICAgICAgICAgICAgIDIwMDctMDctMDhUMDA6MDA6MDBaCiAgICAg ICAgICAgICAgJmx0Oy9yZXBsYXlMb2dDcmVhdGlvblRpbWUmZ3Q7CiAgICAgICAgICAgJmx0Oy9z dHJlYW0mZ3Q7CiAgICAgICAgICAgJmx0O3N0cmVhbSZndDsKICAgICAgICAgICAgICAmbHQ7bmFt ZSZndDtTTk1QJmx0Oy9uYW1lJmd0OwogICAgICAgICAgICAgICZsdDtkZXNjcmlwdGlvbiZndDtT Tk1QIG5vdGlmaWNhdGlvbnMmbHQ7L2Rlc2NyaXB0aW9uJmd0OwogICAgICAgICAgICAgICZsdDty ZXBsYXlTdXBwb3J0Jmd0O2ZhbHNlJmx0Oy9yZXBsYXlTdXBwb3J0Jmd0OwogICAgICAgICAgICZs dDsvc3RyZWFtJmd0OwogICAgICAgICAgICZsdDtzdHJlYW0mZ3Q7CiAgICAgICAgICAgICAmbHQ7 bmFtZSZndDtzeXNsb2ctY3JpdGljYWwmbHQ7L25hbWUmZ3Q7CiAgICAgICAgICAgICAmbHQ7ZGVz Y3JpcHRpb24mZ3Q7Q3JpdGljYWwgYW5kIGhpZ2hlciBzZXZlcml0eQogICAgICAgICAgICAgJmx0 Oy9kZXNjcmlwdGlvbiZndDsKICAgICAgICAgICAgICZsdDtyZXBsYXlTdXBwb3J0Jmd0O3RydWUm bHQ7L3JlcGxheVN1cHBvcnQmZ3Q7CiAgICAgICAgICAgICAmbHQ7cmVwbGF5TG9nQ3JlYXRpb25U aW1lJmd0OwogICAgICAgICAgICAgICAyMDA3LTA3LTAxVDAwOjAwOjAwWgogICAgICAgICAgICAg Jmx0Oy9yZXBsYXlMb2dDcmVhdGlvblRpbWUmZ3Q7CiAgICAgICAgICAgICZsdDsvc3RyZWFtJmd0 OwogICAgICAgICAgICZsdDsvc3RyZWFtcyZndDsKICAgICAgICAgJmx0Oy9uZXRjb25mJmd0Owog ICAgICZsdDsvZGF0YSZndDsKICAgJmx0Oy9ycGMtcmVwbHkmZ3Q7CgozLjIuNS4yLiAgRXZlbnQg U3RyZWFtIFN1YnNjcmlwdGlvbgoKICAgQSBORVRDT05GIGNsaWVudCBtYXkgcmVxdWVzdCBmcm9t IHRoZSBORVRDT05GIHNlcnZlciB0aGUgbGlzdCBvZgogICBldmVudCBzdHJlYW1zIGF2YWlsYWJs ZSB0byB0aGlzIHNlc3Npb24gYW5kIHRoZW4gaXNzdWUgYSAmbHQ7Y3JlYXRlLQogICBzdWJzY3Jp cHRpb24mZ3Q7IHJlcXVlc3Qgd2l0aCB0aGUgZGVzaXJlZCBldmVudCBzdHJlYW0gbmFtZS4gIE9t aXR0aW5nCiAgIHRoZSBldmVudCBzdHJlYW0gbmFtZSBmcm9tIHRoZSAmbHQ7Y3JlYXRlLXN1YnNj cmlwdGlvbiZndDsgcmVxdWVzdCByZXN1bHRzCiAgIGluIHN1YnNjcmlwdGlvbiB0byB0aGUgZGVm YXVsdCBORVRDT05GIGV2ZW8LS0tLSsgICAg ICAgICAgICAgYXZhaWxhYmxlIHN0cmVhbXMKICAgKy0tLS0rICAgIHwgICAgKy0tLS0tLS0tLSsK ICAgKy0tLS0rICAgIHwgICAgfGNlbnRyYWwgIHwtJmd0OyBzdHJlYW0gMQogICB8IGMyIHwgICAg Ky0tLSZndDt8ZXZlbnQgICAgfC0mZ3Q7IHN0cmVhbSAyICAgICBmaWx0ZXIgICstLS0tLS0tKwog ICArLS0tLSsgICAgfCAgICB8cHJvY2Vzc29yfC0mZ3Q7IE5FVENPTkYgc3RyZWFtIC0tLS0tJmd0 O3xORVRDT05GfAogICAgLi4uICAgICAgfCAgICB8ICAgICAgICAgfC0mZ3Q7IHN0cmVhbSBuICAg ICAgICAgICAgIHxzZXJ2ZXIgfAogICBTeXN0ZW0gICAgfCAgICArLS0tLS0tLS0tKyAgICAgICAg ICAgICAgICAgICAgICAgICstLS0tLS0tKwogICBDb21wb25lbnRzfCAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC9cCiAgICAuLi4gICAgICB8ICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfHwKICAgKy0tLS0rICAgIHwgICAgICAgIHwgICAg ICAgKC0tLS0tLS0tLS0tLSkgICAgICAgICAgICB8fAogICB8IGNuIHwtLS0tKyAgICAgICAgfCAg ICAgICAobm90aWZpY2F0aW9uKSAgICAgICAgICAgIHx8CiAgICstLS0tKyAgICAgICAgICAgICAr LS0tLS0mZ3Q7ICggIGxvZ2dpbmcgICApICAgICAgICAgICAgfHwKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKCAgc2VydmljZSAgICkgICAgICAgICAgICB8fAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAoLS0tLS0tLS0tLS0tKSAgICAgICAgICAgIHx8CiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfHwKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8fAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwvCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLSsKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHxORVRDT05G fAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfGNs aWVudCB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICArLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDIKCjMu Mi4xLiAgRXZlbnQgU3RyZWFtIERlZmluaXRpb24KCiAgIEV2ZW50IHN0cmVhbXMgYXJlIHByZWRl ZmluZWQgb24gdGhlIG1hbmFnZWQgZGV2aWNlLiAgVGhlCiAgIGNvbmZpZ3VyYXRpb24gb2YgZXZl bnQgc3RyZWFtcyBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LgogICBIb3dl dmVyLCBpdCBpcyBlbnZpc2lvbmVkIHRoYXQgZXZlbnQgc3RyZWFtcyBhcmUgZWl0aGVyIHByZS0K ICAgZXN0YWJsaXNoZWQgYnkgdGhlIHZlbmRvciAocHJlLWNvbmZpZ3VyZWQpLCB1c2VyIGNvbmZp Z3VyYWJsZSAoZS5nLiwKICAgcGFydCBvZiB0aGUgZGV2aWNlJ3MgY29uZmlndXJhdGlvbikgb3Ig Ym90aC4gIERldmljZSB2ZW5kb3JzIG1heQogICBhbGxvdyBldmVudCBzdHJlYW0gY29uZmlndXJh dGlvbiB2aWEgdGhlIE5FVENPTkYgcHJvdG9jb2wgKGkuZS4sCiAgICZsdDtlZGl0LWNvbmZpZyZn dDsgb3BlcmF0aW9uKS4KCjMuMi4yLiAgRXZlbnQgU3RyZWFtIENvbnRlbnQgRm9ybWF0CgogICBU aGUgY29udGVudHMgb2YgYWxsIGV2ZW50IHN0cmVhbXMgbWFkZSBhdmFpbGFibGUgdG8gYSBORVRD T05GIGNsaWVudAogICAoaS5lLiwgdGhlIG5vdGlmaWNhdGlvbiBzZW50IGJ5IHRoZSBORVRDT05G IHNlcnZlcikgTVVTVCBiZSBlbmNvZGVkCiAgIGluIFhNTC4KCjMuMi4zLiAgRGVmYXVsdCBFdmVu dCBTdHJlYW0KCiAgIEEgTkVUQ09ORiBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gc3VwcG9ydGluZyB0 aGUgbm90aWZpY2F0aW9uCiAgIGNhcGFiaWxpdHkgTVVTVCBzdXBwb3J0IHRoZSAiTkVUQ09ORiIg bm90aWZpY2F0aW9uIGV2ZW50IHN0cmVhbS4KICAgVGhpcyBzdHJlYW0gY29udGFpbnMgYWxsIE5F VENPTkYgWE1MIGV2ZW50IG5vdGlmaWNhdGlvbnMgc3VwcG9ydGVkIGJ5CiAgIHRoZSBORVRDT05G IHNlcnZlci4gIFRoZSBleGFjdCBzdHJpbmcgIk5FVENPTkYiIGlzIHVzZWQgZHVyaW5nCiAgIGFk dmVydGlzZW1lbnQgb2Ygc3RyZWFtIHN1cHBvcnQgZHVyaW5nIHRoZSAmbHQ7Z2V0Jmd0OyBvcGVy YXRpb24gb24KICAgJmx0O3N0cmVhbXMmZ3Q7IGFuZCBkdXJpbmcgdGhlICZsdDtjcmVhdGUtc3Vi c2NyaXB0aW9uJmd0OyBvcGVyYXRpb24uICBEZWZpbml0aW9uCiAgIG9mIHRoZSBldmVudCBub3Rp ZmljYXRpb25zIGFuZCB0aGVpciBjb250ZW50cywgYmV5b25kIHRoZSBpbmNsdXNpb24KICAgb2Yg Jmx0O2V2ZW50VGltZSZndDssIGZvciB0aGlzIGV2ZW50IHN0cmVhbSBpcyBvdXRzaWRlIHRoZSBz Y29wZSBvZiB0aGlzCiAgIGRvY3VtZW50LgoKMy4yLjQuICBFdmVudCBTdHJlYW0gU291cmNlcwoK ICAgV2l0aCB0aGUgZXhjZXB0aW9uIG9mIHRoZSBkZWZhdWx0IGV2ZW50IHN0cmVhbSAoTkVUQ09O RiksCiAgIHNwZWNpZmljYXRpb24gb2YgYWRkaXRpb25hbCBldmVudCBzdHJlYW0gc291cmNlcyAo ZS5nLiwgU05NUCwgc3lzbG9nKQogICBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3Vt ZW50LiAgTkVUQ09ORiBzZXJ2ZXIKICAgaW1wbGVtZW50YXRpb25zIG1heSBsZXZlcmFnZSBhbnkg ZGVzaXJlZCBldmVudCBzdHJlYW0gc291cmNlIGluIHRoZQogICBjcmVhdGlvbiBvZiBzdXBwb3J0 ZWQgZXZlbnQgc3RyZWFtcy4KCjMuMi41LiAgRXZlbnQgU3RyZWFtIERpc2NvdmVyeQoKICAgQSBO RVRDT05GIGNsaWVudCByZXRyaWV2ZXMgdGhlIGxpc3Qgb2Ygc3VwcG9ydGVkIGV2ZW50IHN0cmVh bXMgZnJvbSBhCiAgIE5FVENPTkYgc2VydmVyIHVzaW5nIHRoZSAmbHQ7Z2V0Jmd0OyBvcGVyYXRp b50IHN0cmVhbS4KCjMuMi41LjIuMS4gIEZpbHRlcmluZyBFdmVudCBT dHJlYW0gQ29udGVudHMKCiAgIFRoZSBzZXQgb2YgZXZlbnQgbm90aWZpY2F0aW9ucyBkZWxpdmVy ZWQgaW4gYW4gZXZlbnQgc3RyZWFtIG1heSBiZQogICBmdXJ0aGVyIHJlZmluZWQgYnkgYXBwbHlp bmcgYSB1c2VyLXNwZWNpZmllZCBmaWx0ZXIgc3VwcGxpZWQgYXQKICAgc3Vic2NyaXB0aW9uIGNy ZWF0aW9uIHRpbWUgKCAmbHQ7Y3JlYXRlLXN1YnNjcmlwdGlvbiZndDsgKS4gIFRoaXMgaXMgYQog ICB0cmFuc2llbnQgZmlsdGVyIGFzc29jaWF0ZWQgd2l0aCB0aGUgZXZlbnQgbm90aWZpY2F0aW9u IHN1YnNjcmlwdGlvbgogICBhbmQgZG9lcyBub3QgbW9kaWZ5IHRoZSBldmVudCBzdHJlYW0gY29u ZmlndXJhdGlvbi4gIFRoZSBmaWx0ZXIKICAgZWxlbWVudCBpcyBhcHBsaWVkIGFnYWluc3QgdGhl IGNvbnRlbnRzIG9mIHRoZSAmbHQ7bm90aWZpY2F0aW9uJmd0OyB3cmFwcGVyCiAgIGFuZCBub3Qg dGhlIHdyYXBwZXIgaXRzZWxmLiAgU2VlIHNlY3Rpb24gNSBmb3IgZXhhbXBsZXMuICBFaXRoZXIK ICAgc3VidHJlZSBvciBYUEFUSCBmaWx0ZXJpbmcgY2FuIGJlIHVzZWQuCgogICBYUEFUSCBzdXBw b3J0IGZvciB0aGUgTm90aWZpY2F0aW9uIGNhcGFiaWxpdHkgaXMgYWR2ZXJ0aXNlZCBhcyBwYXJ0 CiAgIG9mIHRoZSBub3JtYWwgWFBBVEggY2FwYWJpbGl0eSBhZHZlcnRpc2VtZW50LiAgSWYgWFBB VEggc3VwcG9ydCBpcwogICBhZHZlcnRpc2VkIHZpYSB0aGUgWFBBVEggY2FwYWJpbGl0eSB0aGVu IFhQQVRIIGlzIHN1cHBvcnRlZCBmb3IKICAgbm90aWZpY2F0aW9uIGZpbHRlcmluZyBhbmQgaWYg dGhpcyBjYXBhYmlsaXR5IGlzIG5vdCBhZHZlcnRpc2VkLAogICBYUEFUSCBpcyBub3Qgc3VwcG9y dGVkIGZvciBub3RpZmljYXRpb24gZmlsdGVyaW5nLgoKMy4zLiAgIE5vdGlmaWNhdGlvbiBSZXBs YXkKCjMuMy4xLiAgT3ZlcnZpZXcKCiAgIFJlcGxheSBpcyB0aGUgYWJpbGl0eSB0byBjcmVhdGUg YW4gZXZlbnQgc3Vic2NyaXB0aW9uIHRoYXQgd2lsbAogICByZXNlbmQgcmVjZW50bHkgZ2VuZXJh dGVkIG5vdGlmaWNhdGlvbnMsIG9yIGluIHNvbWUgY2FzZXMgc2VuZCB0aGVtCiAgIGZvciB0aGUg Zmlyc3QgdGltZSB0byBhIHBhcnRpY3VsYXIgTkVUQ09ORiBjbGllbnQuICBUaGVzZQogICBub3Rp ZmljYXRpb25zIGFyZSBzZW50IHRoZSBzYW1lIHdheSBhcyBub3JtYWwgbm90aWZpY2F0aW9ucy4K CiAgIEEgcmVwbGF5IG9mIG5vdGlmaWNhdGlvbnMgaXMgc3BlY2lmaWVkIGJ5IGluY2x1ZGluZyB0 aGUgb3B0aW9uYWwKICAgJmx0O3N0YXJ0VGltZSZndDsgcGFyYW1ldGVyIHRvIHRoZSBzdWJzY3Jp cHRpb24gY29tbWFuZCwgd2hpY2ggaW5kaWNhdGVzCiAgIHRoZSBzdGFydCB0aW1lIG9mIHRoZSBy ZXBsYXkuICBUaGUgZW5kIHRpbWUgaXMgc3BlY2lmaWVkIHVzaW5nIHRoZQogICBvcHRpb25hbCAm bHQ7c3RvcFRpbWUmZ3Q7IHBhcmFtZXRlci4gIElmIG5vdCBwcmVzZW50LCBub3RpZmljYXRpb25z IHdpbGwKICAgY29udGludWUgdG8gYmUgc2VudCB1bnRpbCB0aGUgc3Vic2NyaXB0aW9uIGlzIHRl cm1pbmF0ZWQuCgogICBBIG5vdGlmaWNhdGlvbiBzdHJlYW0gdGhhdCBzdXBwb3J0cyByZXBsYXkg aXMgbm90IGV4cGVjdGVkIHRvIGhhdmUgYW4KICAgdW5saW1pdGVkIHN1cHBseSBvZiBzYXZlZCBu b3RpZmljYXRpb25zIGF2YWlsYWJsZSB0byBhY2NvbW1vZGF0ZSBhbnkKICAgcmVwbGF5IHJlcXVl c3QuICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+Q2xpZW50cyBjYW4gcXVlcnkgJmx0O3Jl cGxheUxvZ0NyZWF0aW9uVGltZSZndDsgYW5kCiAgICZsdDtyZXBsYXlMb2dBZ2VkVGltZSZndDsg dG8gbGVhcm4gYWJvdXQgdGhlIGF2YWlsYWJpbGl0eSBvZiBub3RpZmljYXRpb25zCiAgIGZvciBy ZXBsYXkuPC9mb250Pjwvc3Ryb25nPgoKICAgVGhlIGFjdHVhbCBudW1iZXIgb2Ygc3RvcmVkIG5v dGlmaWNhdGlvbnMgYXZhaWxhYmxlIGZvciByZXRyaWV2YWwgYXQKICAgYW55IGdpdmVuIHRpbWUg aXMgYSBORVRDT05GIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyBtYXR0ZXIuCiAgIENv bnRyb2wgcGFyYW1ldGVycyBmb3IgdGhpcyBhc3BlY3Qgb2YgdGhlIGZlYXR1cmUgYXJlIG91dHNp ZGUgdGhlCiAgIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuCgogICBSZXBsYXkgaXMgZGVwZW5kZW50 IG9uIGEgbm90aWZpY2F0aW9uIHN0cmVhbSBzdXBwb3J0aW5nIHNvbWUgZm9ybSBvZgogICBub3Rp ZmljYXRpb24gbG9nZ2luZywgYWx0aG91Z2ggaXQgcHV0cyBubyByZXN0cmljdGlvbnMgb24gdGhl IHNpemUgb3IKICAgZm9ybSBvZiB0aGUgbG9nLCBvciB3aGVyZSBpdCByZXNpZGVzIHdpdGhpbiB0 aGUgZGV2aWNlLiAgV2hldGhlciBvcgogICBub3QgYSBzdHJlYW0gc3VwcG9ydHMgcmVwbGF5IGNh biBiZSBkaXNjb3ZlcmVkIGJ5IGRvaW5nIGEgJmx0O2dldCZndDsKICAgb3BlcmF0aW9uIG9uIHRo ZSAmbHQ7c3RyZWFtcyZndDsgZWxlbWVudCBvZiB0aGUgTm90aWZpY2F0aW9uIE1hbmFnZW1lbnQK ICAgU2NoZW1hIGFuZCBsb29raW5nIGF0IHRoZSB2YWx1ZSBvZiB0aGUgJmx0O3JlcGxheVN1cHBv cnQmZ3Q7IG9iamVjdC4gIFRoaXMKICAgc2NoZW1hIGFsc28gcHJvdmlkZXMgdGhlICZsdDtyZXBs YXlMb2dDcmVhdGlvblRpbWUmZ3Q7IGVsZW1lbnQgdG8gaW5kaWNhdGUKICAgdGhlIGVhcmxpZXN0 IGF2YWlsYWJsZSBsb2dnZWQgbm90aWZpY2F0aW9uLgoKMy4zLjIuICBDcmVhdGluZyBhIFN1YnNj cmlwdGlvbiB3aXRoIFJlcGxheQoKICAgVGhpcyBmZWF0dXJlIHVzZXMgb3B0aW9uYWwgcGFyYW1l dGVycyB0byB0aGUgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7CiAgIGNvbW1hbmQgY2FsbGVk ICZsdDtzdGFydFRpbWUmZ3Q7IGFuZCAmbHQ7c3RvcFRpbWUmZ3Q7LiAmbHQ7c3RhcnRUaW1lJmd0 OyBpZGVudGlmaWVzIHRoZQogICBlYXJsaWVzdCBkYXRlIGFuZCB0aW1lIG9mIGludGVyZXN0IGZv ciBldmVudCBub3RpZmljYXRpb25zIGJlaW5nC24uCgozLjIuNS4xLiAgTmFtZSBSZXRyaWV2YWwgdXNpbmcgJmx0O2dldCZndDsgb3BlcmF0aW9u CgogICBUaGUgbGlzdCBvZiBhdmFpbGFibGUgZXZlbnQgc3RyZWFtcyBpcyByZXRyaWV2ZWQgYnkg cmVxdWVzdGluZyB0aGUKICAgJmx0O3N0cmVhbXMmZ3Q7IHN1YnRyZWUgdmlhIGEgJmx0O2dldCZn dDsgb3BlcmF0aW9uLiAgQXZhaWxhYmxlIGV2ZW50IHN0cmVhbXMgZm9yCiAgIHRoZSByZXF1ZXN0 aW5nIHNlc3Npb24gYXJlIHJldHVybmVkIGluIHRoZSByZXBseSBjb250YWluaW5nIHRoZQogICAm bHQ7bmFtZSZndDsgYW5kICZsdDtkZXNjcmlwdGlvbiZndDsgZWxlbWVudHMsIHdoZXJlIHRoZSAm bHQ7bmFtZSZndDsgZWxlbWVudCBpcwogICBtYW5kYXRvcnksIGFuZCBpdHMgdmFsdWUgaXMgdW5p cXVlIHdpdGhpbiB0aGUgc2NvcGUgb2YgYSBORVRDT05GCiAgIHNlcnZlci4gIEFuIGVtcHR5IHJl cGx5IGlzIHJldHVybmVkIGlmIHRoZXJlIGFyZSBubyBhdmFpbGFibGUgZXZlbnQKICAgc3RyZWFt cywgZHVlIHRvIHVzZXItc3BlY2lmaWVkIGZpbHRlcnMgb24gdGhlICZsdDtnZXQmZ3Q7IG9wZXJh dGlvbiAuCgogICBBZGRpdGlvbmFsIGluZm9ybWF0aW9uIGF2YWlsYWJsZSBhYm91dCBhIHN0cmVh bSBpbmNsdWRlIHdoZXRoZXIKICAgbm90aWZpY2F0aW9uIHJlcGxheSBpcyBhdmFpbGFibGUgYW5k IGlmIHNvLCB0aGUgdGltZXN0YW1wIG9mIHRoZQogICBlYXJsaWVzdCBwb3NzaWJsZSBub3RpZmlj YXRpb24gdG8gcmVwbGF5LgoKICAgVGhlIGZvbGxvd2luZyBleGFtcGxlIHNob3dzIHJldHJpZXZp bmcgdGhlIGxpc3Qgb2YgYXZhaWxhYmxlIGV2ZW50CiAgIHN0cmVhbSBsaXN0IHVzaW5nIHRoZSAm bHQ7Z2V0Jmd0OyBvcGVyYXRpb24uCgogICAmbHQ7cnBjIG1lc3NhZ2UtaWQ9IjEwMSIKICAgICAg eG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCImZ3Q7CiAgICAg Jmx0O2dldCZndDsKICAgICAgJmx0O2ZpbHRlciB0eXBlPSJzdWJ0cmVlIiZndDsKICAgICAgICAm bHQ7bmV0Y29uZiB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRtb2Q6bm90aWZpY2F0 aW9uIiZndDsKICAgICAgICAgICAmbHQ7c3RyZWFtcy8mZ3Q7CiAgICAgICAgICZsdDsvbmV0Y29u ZiZndDsKICAgICAgJmx0Oy9maWx0ZXImZ3Q7CiAgICAgJmx0Oy9nZXQmZ3Q7CiAgICZsdDsvcnBj Jmd0OwogICBUaGUgTkVUQ09ORiBzZXJ2ZXIgcmV0dXJucyBhIGxpc3Qgb2YgZXZlbnQgc3RyZWFt cyBhdmFpbGFibGUgZm9yCiAgIHN1YnNjcmlwdGlvbjogTkVUQ09ORiwgU05NUCwgYW5kIHN5c2xv Zy1jcml0aWNhbCBpbiB0aGlzIGV4YW1wbGUuCgogICAmbHQ7cnBjLXJlcGx5IG1lc3NhZ2UtaWQ9 IjEwMSIKICAgICAgICAgICAgICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpu ZXRjb25mOmJhc2U6MS4wIiZndDsKICAgICAmbHQ7ZGF0YSZndDsKICAgICAgICZsdDtuZXRjb25m ICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRtb2Q6bm90aWZpY2F0aW9uIiZndDsK ICAgICAgICAmbHQ7c3RyZWFtcyZndDsKICAgICAgICAgICAmbHQ7c3RyZWFtJmd0OwogICAgICAg ICAgICAgICZsdDtuYW1lJmd0O05FVENPTkYmbHQ7L25hbWUmZ3Q7CiAgICAgICAgICAgICAgJmx0 O2Rlc2NyaXB0aW9uJmd0O2RlZmF1bHQgTkVUQ09ORiBldmVudCBzdHJlYW0KICAgICAgICAgICAg ICAmbHQ7L2Rlc2NyaXB0aW9uJmd0OwogICAgICAgICAgICAgICZsdDtyZXBsYXlTdXBwb3J0Jmd0 O3RydWUmbHQ7L3JlcGxheVN1cHBvcnQmZ3Q7CiAgICAgICAgICAgICAgJmx0O3JlcGxheUxvZ0Ny ZWF0aW9uVGltZSZndDsKICAgICAgICAgICAgICAgIDIwMDctMDctMDhUMDA6MDA6MDBaCiAgICAg ICAgICAgICAgJmx0Oy9yZXBsYXlMb2dDcmVhdGlvblRpbWUmZ3Q7CiAgICAgICAgICAgJmx0Oy9z dHJlYW0mZ3Q7CiAgICAgICAgICAgJmx0O3N0cmVhbSZndDsKICAgICAgICAgICAgICAmbHQ7bmFt ZSZndDtTTk1QJmx0Oy9uYW1lJmd0OwogICAgICAgICAgICAgICZsdDtkZXNjcmlwdGlvbiZndDtT Tk1QIG5vdGlmaWNhdGlvbnMmbHQ7L2Rlc2NyaXB0aW9uJmd0OwogICAgICAgICAgICAgICZsdDty ZXBsYXlTdXBwb3J0Jmd0O2ZhbHNlJmx0Oy9yZXBsYXlTdXBwb3J0Jmd0OwogICAgICAgICAgICZs dDsvc3RyZWFtJmd0OwogICAgICAgICAgICZsdDtzdHJlYW0mZ3Q7CiAgICAgICAgICAgICAmbHQ7 bmFtZSZndDtzeXNsb2ctY3JpdGljYWwmbHQ7L25hbWUmZ3Q7CiAgICAgICAgICAgICAmbHQ7ZGVz Y3JpcHRpb24mZ3Q7Q3JpdGljYWwgYW5kIGhpZ2hlciBzZXZlcml0eQogICAgICAgICAgICAgJmx0 Oy9kZXNjcmlwdGlvbiZndDsKICAgICAgICAgICAgICZsdDtyZXBsYXlTdXBwb3J0Jmd0O3RydWUm bHQ7L3JlcGxheVN1cHBvcnQmZ3Q7CiAgICAgICAgICAgICAmbHQ7cmVwbGF5TG9nQ3JlYXRpb25U aW1lJmd0OwogICAgICAgICAgICAgICAyMDA3LTA3LTAxVDAwOjAwOjAwWgogICAgICAgICAgICAg Jmx0Oy9yZXBsYXlMb2dDcmVhdGlvblRpbWUmZ3Q7CiAgICAgICAgICAgICZsdDsvc3RyZWFtJmd0 OwogICAgICAgICAgICZsdDsvc3RyZWFtcyZndDsKICAgICAgICAgJmx0Oy9uZXRjb25mJmd0Owog ICAgICZsdDsvZGF0YSZndDsKICAgJmx0Oy9ycGMtcmVwbHkmZ3Q7CgozLjIuNS4yLiAgRXZlbnQg U3RyZWFtIFN1YnNjcmlwdGlvbgoKICAgQSBORVRDT05GIGNsaWVudCBtYXkgcmVxdWVzdCBmcm9t IHRoZSBORVRDT05GIHNlcnZlciB0aGUgbGlzdCBvZgogICBldmVudCBzdHJlYW1zIGF2YWlsYWJs ZSB0byB0aGlzIHNlc3Npb24gYW5kIHRoZW4gaXNzdWUgYSAmbHQ7Y3JlYXRlLQogICBzdWJzY3Jp cHRpb24mZ3Q7IHJlcXVlc3Qgd2l0aCB0aGUgZGVzaXJlZCBldmVudCBzdHJlYW0gbmFtZS4gIE9t aXR0aW5nCiAgIHRoZSBldmVudCBzdHJlYW0gbmFtZSBmcm9tIHRoZSAmbHQ7Y3JlYXRlLXN1YnNj cmlwdGlvbiZndDsgcmVxdWVzdCByZXN1bHRzCiAgIGluIHN1YnNjcmlwdGlvbiB0byB0aGUgZGVm YXVsdCBORVRDT05GiAgIHJlcGxheWVkIGFuZCBhbHNvIGluZGljYXRl cyB0aGF0IGEgc3Vic2NyaXB0aW9uIHdpbGwgYmUgcHJvdmlkaW5nCiAgIHJlcGxheSBvZiBub3Rp ZmljYXRpb25zLiAgRXZlbnRzIGdlbmVyYXRlZCBiZWZvcmUgdGhpcyB0aW1lIGFyZSBub3QKICAg bWF0Y2hlZC4gJmx0O3N0b3BUaW1lJmd0OyBzcGVjaWZpZXMgdGhlIGxhdGVzdCBkYXRlIGFuZCB0 aW1lIG9mIGludGVyZXN0CiAgIGZvciBldmVudCBub3RpZmljYXRpb25zIGJlaW5nIHJlcGxheWVk LiAgSWYgaXQgaXMgbm90IHByZXNlbnQsIHRoZW4KICAgbm90aWZpY2F0aW9ucyB3aWxsIGNvbnRp bnVlIHRvIGJlIHNlbnQgdW50aWwgdGhlIHN1YnNjcmlwdGlvbiBpcwogICB0ZXJtaW5hdGVkLgoK ICAgTm90ZSB0aGF0ICZsdDtzdGFydFRpbWUmZ3Q7IGFuZCAmbHQ7c3RvcFRpbWUmZ3Q7IGFyZSBh c3NvY2lhdGVkIHdpdGggdGhlIHRpbWUgYW4KICAgZXZlbnQgd2FzIGdlbmVyYXRlZCBieSB0aGUg ZXZlbnQgc291cmNlLgoKICAgQSAmbHQ7cmVwbGF5Q29tcGxldGUmZ3Q7IG5vdGlmaWNhdGlvbiBp cyBzZW50IHRvIGluZGljYXRlIHRoYXQgYWxsIG9mIHRoZQogICByZXBsYXkgbm90aWZpY2F0aW9u cyBoYXZlIGJlZW4gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5zZW50LjwvZm9udD48L3N0cmlr ZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPnNlbnQgYW5kIG11c3Qgbm90IGJlIHNlbnQg Zm9yIGFueQogICBvdGhlciByZWFzb24uPC9mb250Pjwvc3Ryb25nPiAgSWYgdGhpcyBzdWJzY3Jp cHRpb24gaGFzIGEgc3RvcCB0aW1lLCB0aGVuIHRoaXMKICAgc2Vzc2lvbiBiZWNvbWVzIGEgbm9y bWFsIE5FVENPTkYgc2Vzc2lvbiBhZ2Fpbi4gIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+V2hl bgogICBhICZsdDtzdG9wVGltZSZndDsgaGFzIGJlZW4gc3BlY2lmaWVkLCAmbHQ7bm90aWZpY2F0 aW9uQ29tcGxldGUmZ3Q7IG5vdGlmaWNhdGlvbgogICBpcyB0aGUgbGFzdCBub3RpZmljYXRpb24g c2VudCBvbiB0aGUgc3Vic2NyaXB0aW9uIGJlZm9yZSBpdAogICB0ZXJtaW5hdGVzIGFuZCB0aGUg TkVUQ09ORiBzZXNzaW9uIHJldHVybnMgdG8gYmVpbmcgYSBub3JtYWwgTkVUQ09ORgogICBzZXNz aW9uLjwvZm9udD48L3N0cmlrZT4gIFRoZSBORVRDT05GIHNlcnZlcgogICB3aWxsIHRoZW4gYWNj ZXB0ICZsdDtycGMmZ3Q7IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+b3BlcmF0aW9ucy48L2Zv bnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5vcGVyYXRpb25zIGV2ZW4g aWYgdGhlIHNlcnZlciBkaWQgbm90CiAgIHByZXZpb3VzbHkgYWNjZXB0IHN1Y2ggb3BlcmF0aW9u cyBkdWUgdG8gbGFjayBvZiBpbnRlcmxlYXZlIHN1cHBvcnQuPC9mb250Pjwvc3Ryb25nPgogICBJ biB0aGUgY2FzZSBvZiBhIHN1YnNjcmlwdGlvbiB3aXRob3V0IGEgc3RvcCB0aW1lLCBhZnRlciB0 aGUKICAgJmx0O3JlcGxheUNvbXBsZXRlJmd0OyBub3RpZmljYXRpb24gaGFzIGJlZW4gc2VudCwg aXQgY2FuIGJlIGV4cGVjdGVkIHRoYXQKICAgYW55IG5vdGlmaWNhdGlvbnMgZ2VuZXJhdGVkIHNp bmNlIHRoZSBzdGFydCBvZiB0aGUgc3Vic2NyaXB0aW9uCiAgIGNyZWF0aW9uIHdpbGwgYmUgc2Vu dCwgZm9sbG93ZWQgYnkgbm90aWZpY2F0aW9ucyBhcyB0aGV5IGFyaXNlCiAgIG5hdHVyYWxseSB3 aXRoaW4gdGhlIHN5c3RlbS4KCiAgIFRoZSAmbHQ7cmVwbGF5Q29tcGxldGUmZ3Q7IGFuZCAmbHQ7 bm90aWZpY2F0aW9uQ29tcGxldGUmZ3Q7IG5vdGlmaWNhdGlvbnMgY2Fubm90CiAgIGJlIGZpbHRl cmVkIG91dC4gIFRoZXkgd2lsbCBhbHdheXMgYmUgc2VudCBvbiBhIHJlcGxheSBzdWJzY3JpcHRp b24KICAgdGhhdCBzcGVjaWZpZWQgYSBzdGFydFRpbWUgYW5kIHN0b3BUaW1lIHJlc3BlY3RpdmVs eS4KCjMuNC4gIE5vdGlmaWNhdGlvbiBNYW5hZ2VtZW50IFNjaGVtYQoKICAgVGhpcyBTY2hlbWEg aXMgdXNlZCB0byBsZWFybiBhYm91dCB0aGUgZXZlbnQgc3RyZWFtcyBzdXBwb3J0ZWQgb24gdGhl CiAgIHN5c3RlbS4gIEl0IGFsc28gY29udGFpbnMgdGhlIGRlZmluaXRpb24gb2YgdGhlICZsdDty ZXBsYXlDb21wbGV0ZSZndDsgYW5kCiAgICZsdDtub3RpZmljYXRpb25Db21wbGV0ZSZndDsgbm90 aWZpY2F0aW9ucywgd2hpY2ggYXJlIHNlbnQgdG8gaW5kaWNhdGUgdGhhdAogICBhbiBldmVudCBy ZXBsYXkgaGFzIHNlbnQgYWxsIGFwcGxpY2FibGUgbm90aWZpY2F0aW9ucyBhbmQgdGhhdCB0aGUK ICAgc3Vic2NyaXB0aW9uIGhhcyB0ZXJtaW5hdGVkLCByZXNwZWN0aXZlbHkuCgombHQ7P3htbCB2 ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Jmd0OwombHQ7eHM6c2NoZW1hIHhtbG5zOnhz PSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIKICAgIHhtbG5zOm5ldGNvbmY9InVy bjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCIKICAgIHhtbG5zOm5jRXZlbnQ9 InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRpb246MS4wIgogICAgeG1s bnM6bWFuYWdlRXZlbnQ9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0bW9kOm5vdGlmaWNhdGlv biIKICAgIHRhcmdldE5hbWVzcGFjZT0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRtb2Q6bm90 aWZpY2F0aW9uIgogICAgZWxlbWVudEZvcm1EZWZhdWx0PSJxdWFsaWZpZWQiCiAgICBhdHRyaWJ1 dGVGb3JtRGVmYXVsdD0idW5xdWFsaWZpZWQiCiAgICB4bWw6bGFuZz0iZW4iIHZlcnNpb249IjEu MCImZ3Q7CiAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAmbHQ7eHM6ZG9jdW1lbnRh dGlvbiB4bWw6bGFuZz0iZW4iJmd0OwogICAgICAgICAgICBBIHNjaGVtYSB0aGF0IGNhbiBiZSB1 c2VkIHRvIGxlYXJuIGFib3V0IGN1cnJlbnQKICAgICAgICAgICAgZXZlbnQgc3RyZWFtcy4gSXQg YWxzbyBjb250YWlucyB0aGUgcmVwbGF5Q29tcGxldGUKICAgICAgICAgICAgYW5kIG5vdGlmaWNh dGlvbkNvbXBsZXRlICBub3RpZmljYXRpb24uCiAgICAgICAgJmx0IGV2ZW50IHN0cmVhbS4KCjMuMi41LjIuMS4gIEZpbHRlcmluZyBFdmVudCBT dHJlYW0gQ29udGVudHMKCiAgIFRoZSBzZXQgb2YgZXZlbnQgbm90aWZpY2F0aW9ucyBkZWxpdmVy ZWQgaW4gYW4gZXZlbnQgc3RyZWFtIG1heSBiZQogICBmdXJ0aGVyIHJlZmluZWQgYnkgYXBwbHlp bmcgYSB1c2VyLXNwZWNpZmllZCBmaWx0ZXIgc3VwcGxpZWQgYXQKICAgc3Vic2NyaXB0aW9uIGNy ZWF0aW9uIHRpbWUgKCAmbHQ7Y3JlYXRlLXN1YnNjcmlwdGlvbiZndDsgKS4gIFRoaXMgaXMgYQog ICB0cmFuc2llbnQgZmlsdGVyIGFzc29jaWF0ZWQgd2l0aCB0aGUgZXZlbnQgbm90aWZpY2F0aW9u IHN1YnNjcmlwdGlvbgogICBhbmQgZG9lcyBub3QgbW9kaWZ5IHRoZSBldmVudCBzdHJlYW0gY29u ZmlndXJhdGlvbi4gIFRoZSBmaWx0ZXIKICAgZWxlbWVudCBpcyBhcHBsaWVkIGFnYWluc3QgdGhl IGNvbnRlbnRzIG9mIHRoZSAmbHQ7bm90aWZpY2F0aW9uJmd0OyB3cmFwcGVyCiAgIGFuZCBub3Qg dGhlIHdyYXBwZXIgaXRzZWxmLiAgU2VlIHNlY3Rpb24gNSBmb3IgZXhhbXBsZXMuICBFaXRoZXIK ICAgc3VidHJlZSBvciBYUEFUSCBmaWx0ZXJpbmcgY2FuIGJlIHVzZWQuCgogICBYUEFUSCBzdXBw b3J0IGZvciB0aGUgTm90aWZpY2F0aW9uIGNhcGFiaWxpdHkgaXMgYWR2ZXJ0aXNlZCBhcyBwYXJ0 CiAgIG9mIHRoZSBub3JtYWwgWFBBVEggY2FwYWJpbGl0eSBhZHZlcnRpc2VtZW50LiAgSWYgWFBB VEggc3VwcG9ydCBpcwogICBhZHZlcnRpc2VkIHZpYSB0aGUgWFBBVEggY2FwYWJpbGl0eSB0aGVu IFhQQVRIIGlzIHN1cHBvcnRlZCBmb3IKICAgbm90aWZpY2F0aW9uIGZpbHRlcmluZyBhbmQgaWYg dGhpcyBjYXBhYmlsaXR5IGlzIG5vdCBhZHZlcnRpc2VkLAogICBYUEFUSCBpcyBub3Qgc3VwcG9y dGVkIGZvciBub3RpZmljYXRpb24gZmlsdGVyaW5nLgoKMy4zLiAgIE5vdGlmaWNhdGlvbiBSZXBs YXkKCjMuMy4xLiAgT3ZlcnZpZXcKCiAgIFJlcGxheSBpcyB0aGUgYWJpbGl0eSB0byBjcmVhdGUg YW4gZXZlbnQgc3Vic2NyaXB0aW9uIHRoYXQgd2lsbAogICByZXNlbmQgcmVjZW50bHkgZ2VuZXJh dGVkIG5vdGlmaWNhdGlvbnMsIG9yIGluIHNvbWUgY2FzZXMgc2VuZCB0aGVtCiAgIGZvciB0aGUg Zmlyc3QgdGltZSB0byBhIHBhcnRpY3VsYXIgTkVUQ09ORiBjbGllbnQuICBUaGVzZQogICBub3Rp ZmljYXRpb25zIGFyZSBzZW50IHRoZSBzYW1lIHdheSBhcyBub3JtYWwgbm90aWZpY2F0aW9ucy4K CiAgIEEgcmVwbGF5IG9mIG5vdGlmaWNhdGlvbnMgaXMgc3BlY2lmaWVkIGJ5IGluY2x1ZGluZyB0 aGUgb3B0aW9uYWwKICAgJmx0O3N0YXJ0VGltZSZndDsgcGFyYW1ldGVyIHRvIHRoZSBzdWJzY3Jp cHRpb24gY29tbWFuZCwgd2hpY2ggaW5kaWNhdGVzCiAgIHRoZSBzdGFydCB0aW1lIG9mIHRoZSBy ZXBsYXkuICBUaGUgZW5kIHRpbWUgaXMgc3BlY2lmaWVkIHVzaW5nIHRoZQogICBvcHRpb25hbCAm bHQ7c3RvcFRpbWUmZ3Q7IHBhcmFtZXRlci4gIElmIG5vdCBwcmVzZW50LCBub3RpZmljYXRpb25z IHdpbGwKICAgY29udGludWUgdG8gYmUgc2VudCB1bnRpbCB0aGUgc3Vic2NyaXB0aW9uIGlzIHRl cm1pbmF0ZWQuCgogICBBIG5vdGlmaWNhdGlvbiBzdHJlYW0gdGhhdCBzdXBwb3J0cyByZXBsYXkg aXMgbm90IGV4cGVjdGVkIHRvIGhhdmUgYW4KICAgdW5saW1pdGVkIHN1cHBseSBvZiBzYXZlZCBu b3RpZmljYXRpb25zIGF2YWlsYWJsZSB0byBhY2NvbW1vZGF0ZSBhbnkKICAgcmVwbGF5IHJlcXVl c3QuICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+Q2xpZW50cyBjYW4gcXVlcnkgJmx0O3Jl cGxheUxvZ0NyZWF0aW9uVGltZSZndDsgYW5kCiAgICZsdDtyZXBsYXlMb2dBZ2VkVGltZSZndDsg dG8gbGVhcm4gYWJvdXQgdGhlIGF2YWlsYWJpbGl0eSBvZiBub3RpZmljYXRpb25zCiAgIGZvciBy ZXBsYXkuPC9mb250Pjwvc3Ryb25nPgoKICAgVGhlIGFjdHVhbCBudW1iZXIgb2Ygc3RvcmVkIG5v dGlmaWNhdGlvbnMgYXZhaWxhYmxlIGZvciByZXRyaWV2YWwgYXQKICAgYW55IGdpdmVuIHRpbWUg aXMgYSBORVRDT05GIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyBtYXR0ZXIuCiAgIENv bnRyb2wgcGFyYW1ldGVycyBmb3IgdGhpcyBhc3BlY3Qgb2YgdGhlIGZlYXR1cmUgYXJlIG91dHNp ZGUgdGhlCiAgIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuCgogICBSZXBsYXkgaXMgZGVwZW5kZW50 IG9uIGEgbm90aWZpY2F0aW9uIHN0cmVhbSBzdXBwb3J0aW5nIHNvbWUgZm9ybSBvZgogICBub3Rp ZmljYXRpb24gbG9nZ2luZywgYWx0aG91Z2ggaXQgcHV0cyBubyByZXN0cmljdGlvbnMgb24gdGhl IHNpemUgb3IKICAgZm9ybSBvZiB0aGUgbG9nLCBvciB3aGVyZSBpdCByZXNpZGVzIHdpdGhpbiB0 aGUgZGV2aWNlLiAgV2hldGhlciBvcgogICBub3QgYSBzdHJlYW0gc3VwcG9ydHMgcmVwbGF5IGNh biBiZSBkaXNjb3ZlcmVkIGJ5IGRvaW5nIGEgJmx0O2dldCZndDsKICAgb3BlcmF0aW9uIG9uIHRo ZSAmbHQ7c3RyZWFtcyZndDsgZWxlbWVudCBvZiB0aGUgTm90aWZpY2F0aW9uIE1hbmFnZW1lbnQK ICAgU2NoZW1hIGFuZCBsb29raW5nIGF0IHRoZSB2YWx1ZSBvZiB0aGUgJmx0O3JlcGxheVN1cHBv cnQmZ3Q7IG9iamVjdC4gIFRoaXMKICAgc2NoZW1hIGFsc28gcHJvdmlkZXMgdGhlICZsdDtyZXBs YXlMb2dDcmVhdGlvblRpbWUmZ3Q7IGVsZW1lbnQgdG8gaW5kaWNhdGUKICAgdGhlIGVhcmxpZXN0 IGF2YWlsYWJsZSBsb2dnZWQgbm90aWZpY2F0aW9uLgoKMy4zLjIuICBDcmVhdGluZyBhIFN1YnNj cmlwdGlvbiB3aXRoIFJlcGxheQoKICAgVGhpcyBmZWF0dXJlIHVzZXMgb3B0aW9uYWwgcGFyYW1l dGVycyB0byB0aGUgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7CiAgIGNvbW1hbmQgY2FsbGVk ICZsdDtzdGFydFRpbWUmZ3Q7IGFuZCAmbHQ7c3RvcFRpbWUmZ3Q7LiAmbHQ7c3RhcnRUaW1lJmd0 OyBpZGVudGlmaWVzIHRoZQogICBlYXJsaWVzdCBkYXRlIGFuZCB0aW1lIG9mIGludGVyZXN0IGZv ciBldmVudCBub3RpZmljYXRpb25zIGJOy94czpkb2N1bWVudGF0aW9u Jmd0OwogICAgJmx0Oy94czphbm5vdGF0aW9uJmd0OwoKJmx0O3hzOmltcG9ydCBuYW1lc3BhY2U9 Imh0dHA6Ly93d3cudzMub3JnL1hNTC8xOTk4L25hbWVzcGFjZSIKICAgICAgICBzY2hlbWFMb2Nh dGlvbj0iaHR0cDovL3d3dy53My5vcmcvMjAwMS94bWwueHNkIi8mZ3Q7CiZsdDt4czppbXBvcnQg bmFtZXNwYWNlPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiCiAgICA8 c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPnNjaGVtYUxvY2F0aW9uPQogICAgICJodHRwOi8vd3d3 LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3htbC1yZWdpc3RyeS9zY2hlbWEvbmV0Y29uZi54c2QiLyZn dDs8L2ZvbnQ+PC9zdHJpa2U+CiAgICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+c2NoZW1h TG9jYXRpb249Im5ldGNvbmYueHNkIi8mZ3Q7PC9mb250Pjwvc3Ryb25nPgombHQ7eHM6aW1wb3J0 IG5hbWVzcGFjZT0KICAgICJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6bm90aWZpY2F0 aW9uOjEuMCIKICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5zY2hlbWFMb2NhdGlvbj0K Imh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMveG1sLXJlZ2lzdHJ5L3NjaGVtYS9ub3Rp ZmljYXRpb24ueHNkIi8mZ3Q7PC9mb250Pjwvc3RyaWtlPgogICAgICA8c3Ryb25nPjxmb250IGNv bG9yPSdncmVlbic+c2NoZW1hTG9jYXRpb249Im5vdGlmaWNhdGlvbi54c2QiLyZndDs8L2ZvbnQ+ PC9zdHJvbmc+CiZsdDshLS0gVGhlIGFib3ZlICBzY2hlbWFMb2NhdGlvbiB2YWx1ZSBpcyBhIHBs YWNlaG9sZGVyIGFuZCB0aGUgYWN0dWFsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgdmFsdWUgd2lsbCBiZSBhc3NpZ25lZCBieSBJQU5BIC0tJmd0OwoKJmx0O3hzOmVsZW1l bnQgbmFtZT0ibmV0Y29uZiIgdHlwZT0ibWFuYWdlRXZlbnQ6TmV0Y29uZiIvJmd0OwoKJmx0O3hz OmNvbXBsZXhUeXBlIG5hbWU9Ik5ldGNvbmYiJmd0OwogICZsdDt4czpzZXF1ZW5jZSZndDsKICAg ICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic3RyZWFtcyIgJmd0OwogICAgICAgICZsdDt4czphbm5v dGF0aW9uJmd0OwogICAgICAgICAgICZsdDt4czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAg ICAgVGhlIGxpc3Qgb2YgZXZlbnQgc3RyZWFtcyBzdXBwb3J0ZWQgYnkgdGhlCiAgICAgICAgICAg ICBzeXN0ZW0uIFdoZW4gYSBxdWVyeSBpcyBpc3N1ZWQsIHRoZSByZXR1cm5lZAogICAgICAgICAg ICAgc2V0IG9mIHN0cmVhbXMgaXMgZGV0ZXJtaW5lZCBiYXNlZCBvbiB1c2VyCiAgICAgICAgICAg ICBwcml2aWxlZ2VzLgogICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAg ICAgJmx0Oy94czphbm5vdGF0aW9uJmd0OwogICAgICAgICAmbHQ7eHM6Y29tcGxleFR5cGUmZ3Q7 CiAgICAgICAgICAgJmx0O3hzOnNlcXVlbmNlIG1pbk9jY3Vycz0iMSIgbWF4T2NjdXJzPSJ1bmJv dW5kZWQiJmd0OwogICAgICAgICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic3RyZWFtIiZndDsK ICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAm bHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICBTdHJlYW0gbmFtZSwg ZGVzY3JpcHRpb24gYW5kIG90aGVyIGluZm9ybWF0aW9uLgogICAgICAgICAgICAgICAgICAmbHQ7 L3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24m Z3Q7CiAgICAgICAgICAgICAgICAmbHQ7eHM6Y29tcGxleFR5cGUmZ3Q7CiAgICAgICAgICAgICAg ICAgICZsdDt4czpzZXF1ZW5jZSZndDsKICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVu dCBuYW1lPSJuYW1lIgogICAgICAgICAgICAgICAgICAgICAgICAgICAgdHlwZT0ibmNFdmVudDpz dHJlYW1OYW1lVHlwZSImZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmFubm90YXRp b24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsK ICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhlIG5hbWUgb2YgdGhlIGV2ZW50IHN0cmVhbS4g SWYgdGhpcyBpcwogICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgZGVmYXVsdCBORVRDT05G IHN0cmVhbSwgdGhpcyBtdXN0IGhhdmUKICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHZh bHVlICJORVRDT05GIi4KICAgICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRh dGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAg ICAgICAgICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgICAgICAg ICZsdDt4czplbGVtZW50IG5hbWU9ImRlc2NyaXB0aW9uIgogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgdHlwZT0ieHM6c3RyaW5nIiZndDsKICAgICAgICAgICAgICAgICAg ICAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICAgICZsdDt4 czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICBBIGRlc2NyaXB0 aW9uIG9mIHRoZSBldmVudCBzdHJlYW0sIGluY2x1ZGluZwogICAgICAgICAgICAgICAgICAgICAg ICAgICBzdWNoIGluZm9ybWF0aW9uIGFzIHRoZSB0eXBlIG9mIGV2ZW50cyB0aGF0CiAgICAgICAg ICAgICAgICAgICAgICAgICAgIGFyZSBzZW50IG92ZXIgdGhpcyBzdHJlYW0uCiAgICAgICAgICAg ICAgICAgICAgICAgICAmbHQ7L3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAg ICAgICAgJmx0Oy94czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICZsdDsveHM6 ZWxlbWVudCZndDsKICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJyZXBs YXlTdXBwb3J0IgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAlaW5nCiAgIHJlcGxheWVkIGFuZCBhbHNvIGluZGljYXRl cyB0aGF0IGEgc3Vic2NyaXB0aW9uIHdpbGwgYmUgcHJvdmlkaW5nCiAgIHJlcGxheSBvZiBub3Rp ZmljYXRpb25zLiAgRXZlbnRzIGdlbmVyYXRlZCBiZWZvcmUgdGhpcyB0aW1lIGFyZSBub3QKICAg bWF0Y2hlZC4gJmx0O3N0b3BUaW1lJmd0OyBzcGVjaWZpZXMgdGhlIGxhdGVzdCBkYXRlIGFuZCB0 aW1lIG9mIGludGVyZXN0CiAgIGZvciBldmVudCBub3RpZmljYXRpb25zIGJlaW5nIHJlcGxheWVk LiAgSWYgaXQgaXMgbm90IHByZXNlbnQsIHRoZW4KICAgbm90aWZpY2F0aW9ucyB3aWxsIGNvbnRp bnVlIHRvIGJlIHNlbnQgdW50aWwgdGhlIHN1YnNjcmlwdGlvbiBpcwogICB0ZXJtaW5hdGVkLgoK ICAgTm90ZSB0aGF0ICZsdDtzdGFydFRpbWUmZ3Q7IGFuZCAmbHQ7c3RvcFRpbWUmZ3Q7IGFyZSBh c3NvY2lhdGVkIHdpdGggdGhlIHRpbWUgYW4KICAgZXZlbnQgd2FzIGdlbmVyYXRlZCBieSB0aGUg ZXZlbnQgc291cmNlLgoKICAgQSAmbHQ7cmVwbGF5Q29tcGxldGUmZ3Q7IG5vdGlmaWNhdGlvbiBp cyBzZW50IHRvIGluZGljYXRlIHRoYXQgYWxsIG9mIHRoZQogICByZXBsYXkgbm90aWZpY2F0aW9u cyBoYXZlIGJlZW4gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5zZW50LjwvZm9udD48L3N0cmlr ZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPnNlbnQgYW5kIG11c3Qgbm90IGJlIHNlbnQg Zm9yIGFueQogICBvdGhlciByZWFzb24uPC9mb250Pjwvc3Ryb25nPiAgSWYgdGhpcyBzdWJzY3Jp cHRpb24gaGFzIGEgc3RvcCB0aW1lLCB0aGVuIHRoaXMKICAgc2Vzc2lvbiBiZWNvbWVzIGEgbm9y bWFsIE5FVENPTkYgc2Vzc2lvbiBhZ2Fpbi4gIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+V2hl bgogICBhICZsdDtzdG9wVGltZSZndDsgaGFzIGJlZW4gc3BlY2lmaWVkLCAmbHQ7bm90aWZpY2F0 aW9uQ29tcGxldGUmZ3Q7IG5vdGlmaWNhdGlvbgogICBpcyB0aGUgbGFzdCBub3RpZmljYXRpb24g c2VudCBvbiB0aGUgc3Vic2NyaXB0aW9uIGJlZm9yZSBpdAogICB0ZXJtaW5hdGVzIGFuZCB0aGUg TkVUQ09ORiBzZXNzaW9uIHJldHVybnMgdG8gYmVpbmcgYSBub3JtYWwgTkVUQ09ORgogICBzZXNz aW9uLjwvZm9udD48L3N0cmlrZT4gIFRoZSBORVRDT05GIHNlcnZlcgogICB3aWxsIHRoZW4gYWNj ZXB0ICZsdDtycGMmZ3Q7IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+b3BlcmF0aW9ucy48L2Zv bnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5vcGVyYXRpb25zIGV2ZW4g aWYgdGhlIHNlcnZlciBkaWQgbm90CiAgIHByZXZpb3VzbHkgYWNjZXB0IHN1Y2ggb3BlcmF0aW9u cyBkdWUgdG8gbGFjayBvZiBpbnRlcmxlYXZlIHN1cHBvcnQuPC9mb250Pjwvc3Ryb25nPgogICBJ biB0aGUgY2FzZSBvZiBhIHN1YnNjcmlwdGlvbiB3aXRob3V0IGEgc3RvcCB0aW1lLCBhZnRlciB0 aGUKICAgJmx0O3JlcGxheUNvbXBsZXRlJmd0OyBub3RpZmljYXRpb24gaGFzIGJlZW4gc2VudCwg aXQgY2FuIGJlIGV4cGVjdGVkIHRoYXQKICAgYW55IG5vdGlmaWNhdGlvbnMgZ2VuZXJhdGVkIHNp bmNlIHRoZSBzdGFydCBvZiB0aGUgc3Vic2NyaXB0aW9uCiAgIGNyZWF0aW9uIHdpbGwgYmUgc2Vu dCwgZm9sbG93ZWQgYnkgbm90aWZpY2F0aW9ucyBhcyB0aGV5IGFyaXNlCiAgIG5hdHVyYWxseSB3 aXRoaW4gdGhlIHN5c3RlbS4KCiAgIFRoZSAmbHQ7cmVwbGF5Q29tcGxldGUmZ3Q7IGFuZCAmbHQ7 bm90aWZpY2F0aW9uQ29tcGxldGUmZ3Q7IG5vdGlmaWNhdGlvbnMgY2Fubm90CiAgIGJlIGZpbHRl cmVkIG91dC4gIFRoZXkgd2lsbCBhbHdheXMgYmUgc2VudCBvbiBhIHJlcGxheSBzdWJzY3JpcHRp b24KICAgdGhhdCBzcGVjaWZpZWQgYSBzdGFydFRpbWUgYW5kIHN0b3BUaW1lIHJlc3BlY3RpdmVs eS4KCjMuNC4gIE5vdGlmaWNhdGlvbiBNYW5hZ2VtZW50IFNjaGVtYQoKICAgVGhpcyBTY2hlbWEg aXMgdXNlZCB0byBsZWFybiBhYm91dCB0aGUgZXZlbnQgc3RyZWFtcyBzdXBwb3J0ZWQgb24gdGhl CiAgIHN5c3RlbS4gIEl0IGFsc28gY29udGFpbnMgdGhlIGRlZmluaXRpb24gb2YgdGhlICZsdDty ZXBsYXlDb21wbGV0ZSZndDsgYW5kCiAgICZsdDtub3RpZmljYXRpb25Db21wbGV0ZSZndDsgbm90 aWZpY2F0aW9ucywgd2hpY2ggYXJlIHNlbnQgdG8gaW5kaWNhdGUgdGhhdAogICBhbiBldmVudCBy ZXBsYXkgaGFzIHNlbnQgYWxsIGFwcGxpY2FibGUgbm90aWZpY2F0aW9ucyBhbmQgdGhhdCB0aGUK ICAgc3Vic2NyaXB0aW9uIGhhcyB0ZXJtaW5hdGVkLCByZXNwZWN0aXZlbHkuCgombHQ7P3htbCB2 ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Jmd0OwombHQ7eHM6c2NoZW1hIHhtbG5zOnhz PSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIKICAgIHhtbG5zOm5ldGNvbmY9InVy bjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCIKICAgIHhtbG5zOm5jRXZlbnQ9 InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRpb246MS4wIgogICAgeG1s bnM6bWFuYWdlRXZlbnQ9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0bW9kOm5vdGlmaWNhdGlv biIKICAgIHRhcmdldE5hbWVzcGFjZT0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRtb2Q6bm90 aWZpY2F0aW9uIgogICAgZWxlbWVudEZvcm1EZWZhdWx0PSJxdWFsaWZpZWQiCiAgICBhdHRyaWJ1 dGVGb3JtRGVmYXVsdD0idW5xdWFsaWZpZWQiCiAgICB4bWw6bGFuZz0iZW4iIHZlcnNpb249IjEu MCImZ3Q7CiAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAmbHQ7eHM6ZG9jdW1lbnRh dGlvbiB4bWw6bGFuZz0iZW4iJmd0OwogICAgICAgICAgICBBIHNjaGVtYSB0aGF0IGNhbiBiZSB1 c2VkIHRvIGxlYXJuIGFib3V0IGN1cnJlbnQKICAgICAgICAgICAgZXZlbnQgc3RyZWFtcy4gSXQg YWxzbyBjb250YWlucyB0aGUgcmVwbGF5Q29tcGxldGUKICAgICAgICAgICAgYW5kIG5vdGlmaWNh dGlvbkNvbXBsZXRlICBub3RpZmljYXRpb24uCiAgICAgICgdHlwZT0i eHM6Ym9vbGVhbiImZ3Q7CiAgICAgICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0 OwogICAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAg ICAgICAgICAgICAgICAgICAgICAgIEFuIGluZGljYXRpb24gb2Ygd2hldGhlciBvciBub3QgZXZl bnQgcmVwbGF5CiAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzIGF2YWlsYWJsZSBvbiB0aGlz IHN0cmVhbS4KICAgICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZn dDsKICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAg ICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgICAgICAgICZsdDt4 czplbGVtZW50IG5hbWU9InJlcGxheUxvZ0NyZWF0aW9uVGltZSIKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB0eXBlPSJ4czpkYXRlVGltZSIgbWluT2NjdXJzPSIwIiZndDsKICAg ICAgICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAg ICAgICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICBU aGUgdGltZXN0YW1wIG9mIHRoZSBjcmVhdGlvbiBvZiB0aGUgbG9nCiAgICAgICAgICAgICAgICAg ICAgICAgdXNlZCB0byBzdXBwb3J0IHRoZSByZXBsYXkgZnVuY3Rpb24gb24KICAgICAgICAgICAg ICAgICAgICAgICB0aGlzIHN0cmVhbS4KICAgICAgICAgICAgICAgICAgICAgICBOb3RlIHRoYXQg dGhpcyBtaWdodCBiZSBlYXJsaWVyIHRoZW4KICAgICAgICAgICAgICAgICAgICAgICB0aGUgZWFy bGllc3QgYXZhaWxhYmxlCiAgICAgICAgICAgICAgICAgICAgICAgbm90aWZpY2F0aW9uIGluIHRo ZSBsb2cuIFRoaXMgb2JqZWN0CiAgICAgICAgICAgICAgICAgICAgICAgaXMgdXBkYXRlZCBpZiB0 aGUgbG9nIHJlc2V0cwogICAgICAgICAgICAgICAgICAgICAgIGZvciBzb21lIHJlYXNvbi4gVGhp cwogICAgICAgICAgICAgICAgICAgICAgIG9iamVjdCBNVVNUIGJlIHByZXNlbnQgaWYgcmVwbGF5 IGlzCiAgICAgICAgICAgICAgICAgICAgICAgc3VwcG9ydGVkLgogICAgICAgICAgICAgICAgICAg ICAgICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICZs dDsveHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czplbGVtZW50 Jmd0OwogICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJyZXBsYXlMb2dB Z2VkVGltZSIKICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGU9InhzOmRhdGVUaW1lIiBt aW5PY2N1cnM9IjAiJmd0OwogICAgICAgICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9u Jmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAg ICAgICAgICAgICAgICAgICAgICAgICAgIFRoZSB0aW1lc3RhbXAgb2YgdGhlIGxhc3Qgbm90aWZp Y2F0aW9uCiAgICAgICAgICAgICAgICAgICAgICAgICAgIGFnZWQgb3V0IG9mIHRoZSBsb2cuIFRo aXMKICAgICAgICAgICAgICAgICAgICAgICAgICAgb2JqZWN0IE1VU1QgYmUgcHJlc2VudCBpZiBy ZXBsYXkgaXMKICAgICAgICAgICAgICAgICAgICAgICAgICAgc3VwcG9ydGVkIGFuZCBhbnkgbm90 aWZpY2F0aW9ucwogICAgICAgICAgICAgICAgICAgICAgICAgICBoYXZlIGJlZW4gYWdlZCBvdXQg b2YgdGhlIGxvZy4KICAgICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlv biZndDsKICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAg ICAgICAgICAgICAgICAgICZsdDsveHM6ZWxlbWVudCZndDsKICAgICAgICAgICAgICAgICAgICZs dDsveHM6c2VxdWVuY2UmZ3Q7CiAgICAgICAgICAgICAgICAgJmx0Oy94czpjb21wbGV4VHlwZSZn dDsKICAgICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgJmx0Oy94 czpzZXF1ZW5jZSZndDsKICAgICAgICAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwogICAgICAg ICAmbHQ7L3hzOmVsZW1lbnQmZ3Q7CiAgICAmbHQ7L3hzOnNlcXVlbmNlJmd0OwogICAgJmx0Oy94 czpjb21wbGV4VHlwZSZndDsKCiAgICAmbHQ7eHM6Y29tcGxleFR5cGUgbmFtZT0iUmVwbGF5Q29t cGxldGVOb3RpZmljYXRpb25UeXBlIiZndDsKICAgICAgICAmbHQ7eHM6Y29tcGxleENvbnRlbnQm Z3Q7CiAgICAgICAgICAgICZsdDt4czpleHRlbnNpb24gYmFzZT0ibmNFdmVudDpOb3RpZmljYXRp b25Db250ZW50VHlwZSIvJmd0OwogICAgICAgICZsdDsveHM6Y29tcGxleENvbnRlbnQmZ3Q7CiAg ICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwoKICAgICZsdDt4czplbGVtZW50IG5hbWU9InJlcGxh eUNvbXBsZXRlIgogICAgICAgIHR5cGU9Im1hbmFnZUV2ZW50OlJlcGxheUNvbXBsZXRlTm90aWZp Y2F0aW9uVHlwZSIKICAgICAgICBzdWJzdGl0dXRpb25Hcm91cD0ibmNFdmVudDpub3RpZmljYXRp b25Db250ZW50IiZndDsKICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0OwogICAg ICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgIFRoaXMgbm90aWZpY2F0 aW9uIGlzIHNlbnQgdG8gc2lnbmFsIHRoZSBlbmQgb2YgYSByZXBsYXkKICAgICAgICAgICAgcG9y dGlvbiBvZiBhIHN1YnNjcmlwdGlvbi4KICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZn dDsKICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgJmx0Oy94czplbGVtZW50 Jmd0OwoKICAgICZsdDt4czpjb21wbGV4VHlwZSBuYW1lPSJOb3RpZmljYXRpb25Db21wbGV0ZU5v dGlmaWNhdGlvblR5cGUiJmd0OwogICAgICAgICZsdDt4czpjb21wbGV4Q29udGVudCZndDsKICAg ICAgICAgICAgJmx0O3hzOmV4dGVuc2lvbiBiYXNlPSJuY0V2ZW50Ok5vdGlmaWNhdGlvbkNvbnRl bnRUeAgJmx0Oy94czpkb2N1bWVudGF0aW9u Jmd0OwogICAgJmx0Oy94czphbm5vdGF0aW9uJmd0OwoKJmx0O3hzOmltcG9ydCBuYW1lc3BhY2U9 Imh0dHA6Ly93d3cudzMub3JnL1hNTC8xOTk4L25hbWVzcGFjZSIKICAgICAgICBzY2hlbWFMb2Nh dGlvbj0iaHR0cDovL3d3dy53My5vcmcvMjAwMS94bWwueHNkIi8mZ3Q7CiZsdDt4czppbXBvcnQg bmFtZXNwYWNlPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiCiAgICA8 c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnPnNjaGVtYUxvY2F0aW9uPQogICAgICJodHRwOi8vd3d3 LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3htbC1yZWdpc3RyeS9zY2hlbWEvbmV0Y29uZi54c2QiLyZn dDs8L2ZvbnQ+PC9zdHJpa2U+CiAgICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbic+c2NoZW1h TG9jYXRpb249Im5ldGNvbmYueHNkIi8mZ3Q7PC9mb250Pjwvc3Ryb25nPgombHQ7eHM6aW1wb3J0 IG5hbWVzcGFjZT0KICAgICJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6bm90aWZpY2F0 aW9uOjEuMCIKICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJz5zY2hlbWFMb2NhdGlvbj0K Imh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMveG1sLXJlZ2lzdHJ5L3NjaGVtYS9ub3Rp ZmljYXRpb24ueHNkIi8mZ3Q7PC9mb250Pjwvc3RyaWtlPgogICAgICA8c3Ryb25nPjxmb250IGNv bG9yPSdncmVlbic+c2NoZW1hTG9jYXRpb249Im5vdGlmaWNhdGlvbi54c2QiLyZndDs8L2ZvbnQ+ PC9zdHJvbmc+CiZsdDshLS0gVGhlIGFib3ZlICBzY2hlbWFMb2NhdGlvbiB2YWx1ZSBpcyBhIHBs YWNlaG9sZGVyIGFuZCB0aGUgYWN0dWFsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgdmFsdWUgd2lsbCBiZSBhc3NpZ25lZCBieSBJQU5BIC0tJmd0OwoKJmx0O3hzOmVsZW1l bnQgbmFtZT0ibmV0Y29uZiIgdHlwZT0ibWFuYWdlRXZlbnQ6TmV0Y29uZiIvJmd0OwoKJmx0O3hz OmNvbXBsZXhUeXBlIG5hbWU9Ik5ldGNvbmYiJmd0OwogICZsdDt4czpzZXF1ZW5jZSZndDsKICAg ICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic3RyZWFtcyIgJmd0OwogICAgICAgICZsdDt4czphbm5v dGF0aW9uJmd0OwogICAgICAgICAgICZsdDt4czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAg ICAgVGhlIGxpc3Qgb2YgZXZlbnQgc3RyZWFtcyBzdXBwb3J0ZWQgYnkgdGhlCiAgICAgICAgICAg ICBzeXN0ZW0uIFdoZW4gYSBxdWVyeSBpcyBpc3N1ZWQsIHRoZSByZXR1cm5lZAogICAgICAgICAg ICAgc2V0IG9mIHN0cmVhbXMgaXMgZGV0ZXJtaW5lZCBiYXNlZCBvbiB1c2VyCiAgICAgICAgICAg ICBwcml2aWxlZ2VzLgogICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAg ICAgJmx0Oy94czphbm5vdGF0aW9uJmd0OwogICAgICAgICAmbHQ7eHM6Y29tcGxleFR5cGUmZ3Q7 CiAgICAgICAgICAgJmx0O3hzOnNlcXVlbmNlIG1pbk9jY3Vycz0iMSIgbWF4T2NjdXJzPSJ1bmJv dW5kZWQiJmd0OwogICAgICAgICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic3RyZWFtIiZndDsK ICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAm bHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICBTdHJlYW0gbmFtZSwg ZGVzY3JpcHRpb24gYW5kIG90aGVyIGluZm9ybWF0aW9uLgogICAgICAgICAgICAgICAgICAmbHQ7 L3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24m Z3Q7CiAgICAgICAgICAgICAgICAmbHQ7eHM6Y29tcGxleFR5cGUmZ3Q7CiAgICAgICAgICAgICAg ICAgICZsdDt4czpzZXF1ZW5jZSZndDsKICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVu dCBuYW1lPSJuYW1lIgogICAgICAgICAgICAgICAgICAgICAgICAgICAgdHlwZT0ibmNFdmVudDpz dHJlYW1OYW1lVHlwZSImZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmFubm90YXRp b24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsK ICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhlIG5hbWUgb2YgdGhlIGV2ZW50IHN0cmVhbS4g SWYgdGhpcyBpcwogICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgZGVmYXVsdCBORVRDT05G IHN0cmVhbSwgdGhpcyBtdXN0IGhhdmUKICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIHZh bHVlICJORVRDT05GIi4KICAgICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRh dGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAg ICAgICAgICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgICAgICAg ICZsdDt4czplbGVtZW50IG5hbWU9ImRlc2NyaXB0aW9uIgogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgdHlwZT0ieHM6c3RyaW5nIiZndDsKICAgICAgICAgICAgICAgICAg ICAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICAgICZsdDt4 czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICBBIGRlc2NyaXB0 aW9uIG9mIHRoZSBldmVudCBzdHJlYW0sIGluY2x1ZGluZwogICAgICAgICAgICAgICAgICAgICAg ICAgICBzdWNoIGluZm9ybWF0aW9uIGFzIHRoZSB0eXBlIG9mIGV2ZW50cyB0aGF0CiAgICAgICAg ICAgICAgICAgICAgICAgICAgIGFyZSBzZW50IG92ZXIgdGhpcyBzdHJlYW0uCiAgICAgICAgICAg ICAgICAgICAgICAgICAmbHQ7L3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAg ICAgICAgJmx0Oy94czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICZsdDsveHM6 ZWxlbWVudCZndDsKICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJyZXBs YXlTdXBwb3J0IgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIXBlIi8mZ3Q7CiAgICAgICAgJmx0Oy94czpjb21wbGV4Q29udGVudCZndDsKICAgICZsdDsv eHM6Y29tcGxleFR5cGUmZ3Q7CgogICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ibm90aWZpY2F0aW9u Q29tcGxldGUiCiAgICAgICAgdHlwZT0ibWFuYWdlRXZlbnQ6Tm90aWZpY2F0aW9uQ29tcGxldGVO b3RpZmljYXRpb25UeXBlIgogICAgICAgIHN1YnN0aXR1dGlvbkdyb3VwPSJuY0V2ZW50Om5vdGlm aWNhdGlvbkNvbnRlbnQiJmd0OwogICAgICAgICAgICAgICAgJmx0O3hzOmFubm90YXRpb24mZ3Q7 CiAgICAgICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgVGhpcyBub3Rp ZmljYXRpb24gaXMgc2VudCB0byBzaWduYWwgdGhlIGVuZCBvZiBhCiAgICAgICAgICAgIG5vdGlm aWNhdGlvbiBzdWJzY3JpcHRpb24uIEl0IGlzIHNlbnQgaW4gdGhlIGNhc2UKICAgICAgICAgICAg dGhhdCBzdG9wVGltZSB3YXMgc3BlY2lmaWVkIGR1cmluZyB0aGUgY3JlYXRpb24gb2YKICAgICAg ICAgICAgdGhlIHN1YnNjcmlwdGlvbi4KICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZn dDsKICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgJmx0Oy94czplbGVtZW50 Jmd0OwoKJmx0Oy94czpzY2hlbWEmZ3Q7CgozLjUuICBTdWJzY3JpcHRpb25zIERhdGEKCiAgIFN1 YnNjcmlwdGlvbnMgYXJlIG5vbi1wZXJzaXN0ZW50IHN0YXRlIGluZm9ybWF0aW9uIGFuZCB0aGVp ciBsaWZldGltZQogICBpcyBkZWZpbmVkIGJ5IHRoZWlyIHNlc3Npb24gb3IgYnkgdGhlICZsdDtz dG9wVGltZSZndDsgcGFyYW1ldGVyLgoKMy42LiAgRmlsdGVyIE1lY2hhbmljcwoKICAgPHN0cmlr ZT48Zm9udCBjb2xvcj0ncmVkJz5XaGVuIG11bHRpcGxlIGZpbHRlciBlbGVtZW50cyBhcmUgc3Bl Y2lmaWVkLCB0aGV5IGFyZSBhcHBsaWVkCiAgIGNvbGxlY3RpdmVseSwgc28gZXZlbnQgbm90aWZp Y2F0aW9ucyBuZWVkIHRvIHBhc3MgYWxsIHNwZWNpZmllZAogICBmaWx0ZXIgZWxlbWVudHMgaW4g b3JkZXIgdG8gYmUgc2VudCB0byB0aGUgc3Vic2NyaWJlci48L2ZvbnQ+PC9zdHJpa2U+CgogICBJ ZiBhIGZpbHRlciBlbGVtZW50IGlzIHNwZWNpZmllZCB0byBsb29rIGZvciBkYXRhIG9mIGEgcGFy dGljdWxhcgogICB2YWx1ZSwgYW5kIHRoZSBkYXRhIGl0ZW0gaXMgbm90IHByZXNlbnQgd2l0aGlu IGEgcGFydGljdWxhciBldmVudAogICBub3RpZmljYXRpb24gZm9yIGl0cyB2YWx1ZSB0byBiZSBj aGVja2VkIGFnYWluc3QsIHRoZSBub3RpZmljYXRpb24KICAgd2lsbCBiZSBmaWx0ZXJlZCBvdXQu ICBGb3IgZXhhbXBsZSwgaWYgb25lIHdlcmUgdG8gY2hlY2sgZm9yCiAgICdzZXZlcml0eT1jcml0 aWNhbCcgaW4gYSBjb25maWd1cmF0aW9uIGV2ZW50IG5vdGlmaWNhdGlvbiB3aGVyZSB0aGlzCiAg IGZpZWxkIHdhcyBub3Qgc3VwcG9ydGVkLCB0aGVuIHRoZSBub3RpZmljYXRpb24gd291bGQgYmUg ZmlsdGVyZWQgb3V0LgoKICAgRm9yIHN1YnRyZWUgZmlsdGVyaW5nLCBhIG5vbi1lbXB0eSBub2Rl IHNldCBtZWFucyB0aGF0IHRoZSBmaWx0ZXIKICAgbWF0Y2hlcy4gIEZvciBYUGF0aCBmaWx0ZXJp bmcsIHRoZSBtZWNoYW5pc21zIGRlZmluZWQgaW4gW1hQQVRIXQogICBzaG91bGQgYmUgdXNlZCB0 byBjb252ZXJ0IHRoZSByZXR1cm5lZCB2YWx1ZSB0byBib29sZWFuLgoKMy42LjEuICBGaWx0ZXJp bmcKCiAgIEZpbHRlcmluZyBpcyBleHBsaWNpdGx5IHN0YXRlZCB3aGVuIHRoZSBldmVudCBub3Rp ZmljYXRpb24KICAgc3Vic2NyaXB0aW9uIGlzIGNyZWF0ZWQuICBUaGlzIGlzIHNwZWNpZmllZCB2 aWEgdGhlICdmaWx0ZXInCiAgIHBhcmFtZXRlci4gIEEgRmlsdGVyIG9ubHkgPHN0cmlrZT48Zm9u dCBjb2xvcj0ncmVkJz5leGlzdDwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0n Z3JlZW4nPmV4aXN0czwvZm9udD48L3N0cm9uZz4gYXMgYSBwYXJhbWV0ZXIgdG8gdGhlIHN1YnNj cmlwdGlvbi4KCjMuNy4gIE1lc3NhZ2UgRmxvdwogICBUaGUgZm9sbG93aW5nIGZpZ3VyZSBkZXBp Y3RzIG1lc3NhZ2UgZmxvdyBiZXR3ZWVuIGEgTkVUQ09ORiBjbGllbnQKICAgKEMpIGFuZCBORVRD T05GIHNlcnZlciAoUykgaW4gb3JkZXIgdG8gY3JlYXRlIGEgc3Vic2NyaXB0aW9uIGFuZAogICBi ZWdpbiB0aGUgZmxvdyBvZiBub3RpZmljYXRpb25zLiAgVGhpcyBzdWJzY3JpcHRpb24gc3BlY2lm aWVkIGEKICAgJmx0O3N0YXJ0VGltZSZndDssIHNvIHRoZSBzZXJ2ZXIgc3RhcnRzIGJ5IHJlcGxh eWluZyBsb2dnZWQgbm90aWZpY2F0aW9ucy4KICAgSXQgaXMgcG9zc2libGUgdGhhdCBtYW55IHJw Yy9ycGMtcmVwbHkgc2VxdWVuY2VzIG9jY3VyIGJlZm9yZSB0aGUKICAgc3Vic2NyaXB0aW9uIGlz IGNyZWF0ZWQsIGJ1dCB0aGlzIGlzIG5vdCBkZXBpY3RlZCBpbiB0aGUgZmlndXJlLgoKICAgICAg ICAgICAgICAgICAgICAgICAgQyAgICAgICAgICAgICAgICAgICAgICAgICAgIFMKICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAg ICAgICAgICAgICAgfCAgY2FwYWJpbGl0eSBleGNoYW5nZSAgICAgIHwKICAgICAgICAgICAgICAg ICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wKICAgICAgICAgICAgICAg ICAgICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wKICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAg ICAgICAgICAgfCAgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7ICAgIHwgKHN0YXJ0VGltZSkK ICAgICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wK ICAgICAgICAgICAgICAgICAgICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwK ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgJmx0O3JwYy1yZXBseSZndDsgICAgICAgICAg IHwKICAgICAgICAgICAgCAgICAgdHlwZT0i eHM6Ym9vbGVhbiImZ3Q7CiAgICAgICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0 OwogICAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAg ICAgICAgICAgICAgICAgICAgICAgIEFuIGluZGljYXRpb24gb2Ygd2hldGhlciBvciBub3QgZXZl bnQgcmVwbGF5CiAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzIGF2YWlsYWJsZSBvbiB0aGlz IHN0cmVhbS4KICAgICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZn dDsKICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAg ICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgICAgICAgICZsdDt4 czplbGVtZW50IG5hbWU9InJlcGxheUxvZ0NyZWF0aW9uVGltZSIKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB0eXBlPSJ4czpkYXRlVGltZSIgbWluT2NjdXJzPSIwIiZndDsKICAg ICAgICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAg ICAgICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICBU aGUgdGltZXN0YW1wIG9mIHRoZSBjcmVhdGlvbiBvZiB0aGUgbG9nCiAgICAgICAgICAgICAgICAg ICAgICAgdXNlZCB0byBzdXBwb3J0IHRoZSByZXBsYXkgZnVuY3Rpb24gb24KICAgICAgICAgICAg ICAgICAgICAgICB0aGlzIHN0cmVhbS4KICAgICAgICAgICAgICAgICAgICAgICBOb3RlIHRoYXQg dGhpcyBtaWdodCBiZSBlYXJsaWVyIHRoZW4KICAgICAgICAgICAgICAgICAgICAgICB0aGUgZWFy bGllc3QgYXZhaWxhYmxlCiAgICAgICAgICAgICAgICAgICAgICAgbm90aWZpY2F0aW9uIGluIHRo ZSBsb2cuIFRoaXMgb2JqZWN0CiAgICAgICAgICAgICAgICAgICAgICAgaXMgdXBkYXRlZCBpZiB0 aGUgbG9nIHJlc2V0cwogICAgICAgICAgICAgICAgICAgICAgIGZvciBzb21lIHJlYXNvbi4gVGhp cwogICAgICAgICAgICAgICAgICAgICAgIG9iamVjdCBNVVNUIGJlIHByZXNlbnQgaWYgcmVwbGF5 IGlzCiAgICAgICAgICAgICAgICAgICAgICAgc3VwcG9ydGVkLgogICAgICAgICAgICAgICAgICAg ICAgICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICZs dDsveHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czplbGVtZW50 Jmd0OwogICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJyZXBsYXlMb2dB Z2VkVGltZSIKICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGU9InhzOmRhdGVUaW1lIiBt aW5PY2N1cnM9IjAiJmd0OwogICAgICAgICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9u Jmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAg ICAgICAgICAgICAgICAgICAgICAgICAgIFRoZSB0aW1lc3RhbXAgb2YgdGhlIGxhc3Qgbm90aWZp Y2F0aW9uCiAgICAgICAgICAgICAgICAgICAgICAgICAgIGFnZWQgb3V0IG9mIHRoZSBsb2cuIFRo aXMKICAgICAgICAgICAgICAgICAgICAgICAgICAgb2JqZWN0IE1VU1QgYmUgcHJlc2VudCBpZiBy ZXBsYXkgaXMKICAgICAgICAgICAgICAgICAgICAgICAgICAgc3VwcG9ydGVkIGFuZCBhbnkgbm90 aWZpY2F0aW9ucwogICAgICAgICAgICAgICAgICAgICAgICAgICBoYXZlIGJlZW4gYWdlZCBvdXQg b2YgdGhlIGxvZy4KICAgICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlv biZndDsKICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAg ICAgICAgICAgICAgICAgICZsdDsveHM6ZWxlbWVudCZndDsKICAgICAgICAgICAgICAgICAgICZs dDsveHM6c2VxdWVuY2UmZ3Q7CiAgICAgICAgICAgICAgICAgJmx0Oy94czpjb21wbGV4VHlwZSZn dDsKICAgICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgJmx0Oy94 czpzZXF1ZW5jZSZndDsKICAgICAgICAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwogICAgICAg ICAmbHQ7L3hzOmVsZW1lbnQmZ3Q7CiAgICAmbHQ7L3hzOnNlcXVlbmNlJmd0OwogICAgJmx0Oy94 czpjb21wbGV4VHlwZSZndDsKCiAgICAmbHQ7eHM6Y29tcGxleFR5cGUgbmFtZT0iUmVwbGF5Q29t cGxldGVOb3RpZmljYXRpb25UeXBlIiZndDsKICAgICAgICAmbHQ7eHM6Y29tcGxleENvbnRlbnQm Z3Q7CiAgICAgICAgICAgICZsdDt4czpleHRlbnNpb24gYmFzZT0ibmNFdmVudDpOb3RpZmljYXRp b25Db250ZW50VHlwZSIvJmd0OwogICAgICAgICZsdDsveHM6Y29tcGxleENvbnRlbnQmZ3Q7CiAg ICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwoKICAgICZsdDt4czplbGVtZW50IG5hbWU9InJlcGxh eUNvbXBsZXRlIgogICAgICAgIHR5cGU9Im1hbmFnZUV2ZW50OlJlcGxheUNvbXBsZXRlTm90aWZp Y2F0aW9uVHlwZSIKICAgICAgICBzdWJzdGl0dXRpb25Hcm91cD0ibmNFdmVudDpub3RpZmljYXRp b25Db250ZW50IiZndDsKICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0OwogICAg ICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgIFRoaXMgbm90aWZpY2F0 aW9uIGlzIHNlbnQgdG8gc2lnbmFsIHRoZSBlbmQgb2YgYSByZXBsYXkKICAgICAgICAgICAgcG9y dGlvbiBvZiBhIHN1YnNjcmlwdGlvbi4KICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZn dDsKICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgJmx0Oy94czplbGVtZW50 Jmd0OwoKICAgICZsdDt4czpjb21wbGV4VHlwZSBuYW1lPSJOb3RpZmljYXRpb25Db21wbGV0ZU5v dGlmaWNhdGlvblR5cGUiJmd0OwogICAgICAgICZsdDt4czpjb21wbGV4Q29udGVudCZndDsKICAg ICAgICAgICAgJmx0O3hzOmV4dGVuc2lvbiBiYXNlPSJuY0V2ZW50Ok5vdGlmaWNhdGlvbkNvbnRlICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgJmx0O25vdGlmaWNhdGlvbiZndDsgICAgICAg IHwKICAgICAgICAgICAgICAgICAgICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LXwKICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgJmx0O25vdGlmaWNhdGlvbiZndDsgICAgICAg IHwKICAgICAgICAgICAgICAgICAgICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LXwKICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICZsdDtub3RpZmljYXRpb24mZ3Q7ICAg ICAgIHwgKHJlcGxheUNvbXBsZXRlKQogICAgICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAmbHQ7bm90aWZpY2F0 aW9uJmd0OyAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAmbHQ7bm90aWZpY2F0aW9u Jmd0OyAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDMKICAgVGhl IGZvbGxvd2luZyBmaWd1cmUgZGVwaWN0cyBtZXNzYWdlIGZsb3cgYmV0d2VlbiBhIE5FVENPTkYg Y2xpZW50CiAgIChDKSBhbmQgTkVUQ09ORiBzZXJ2ZXIgKFMpIGluIG9yZGVyIHRvIGNyZWF0ZSBh IHN1YnNjcmlwdGlvbiBhbmQKICAgYmVnaW4gdGhlIGZsb3cgb2Ygbm90aWZpY2F0aW9ucy4gIFRo aXMgc3Vic2NyaXB0aW9uIHNwZWNpZmllZCBhCiAgICZsdDtzdGFydFRpbWUmZ3Q7IGFuZCAmbHQ7 c3RvcFRpbWUmZ3Q7IHNvIGl0IHN0YXJ0cyBieSByZXBsYXlpbmcgbG9nZ2VkCiAgIG5vdGlmaWNh dGlvbnMgYW5kIHRoZW4gcmV0dXJucyB0byBiZSBhIG5vcm1hbCBjb21tYW5kLXJlc3BvbnNlCiAg IE5FVENPTkYgc2Vzc2lvbiBhZnRlciB0aGUgJmx0O3JlcGxheUNvbXBsZXRlJmd0OyBhbmQgJmx0 O25vdGlmaWNhdGlvbkNvbXBsZXRlJmd0OwogICBub3RpZmljYXRpb25zIGFyZSBzZW50IGFuZCBp dCBpcyBhdmFpbGFibGUgdG8gcHJvY2VzcyAmbHQ7cnBjJmd0OyByZXF1ZXN0cy4KICAgSXQgaXMg cG9zc2libGUgdGhhdCBtYW55IHJwYy9ycGMtcmVwbHkgc2VxdWVuY2VzIG9jY3VyIGJlZm9yZSB0 aGUKICAgc3Vic2NyaXB0aW9uIGlzIGNyZWF0ZWQsIGJ1dCB0aGlzIGlzIG5vdCBkZXBpY3RlZCBp biB0aGUgZmlndXJlLgoKICAgICAgICAgICAgICAgICAgICAgQyAgICAgICAgICAgICAgICAgICAg ICAgICAgIFMKICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg IHwKICAgICAgICAgICAgICAgICAgICAgfCAgY2FwYWJpbGl0eSBleGNoYW5nZSAgICAgIHwKICAg ICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wKICAgICAg ICAgICAgICAgICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wKICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAg ICAgICAgICAgfCAgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7ICAgIHwgKHN0YXJ0VGltZSwK ICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wgIHN0 b3BUaW1lKQogICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tfAogICAgICAgICAgICAgICAgICAgICB8ICAgICAmbHQ7cnBjLXJlcGx5Jmd0OyAgICAgICAg ICAgfAogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAog ICAgICAgICAgICAgICAgICAgICB8ICAgICAmbHQ7bm90aWZpY2F0aW9uJmd0OyAgICAgICAgfAog ICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfAogICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAg ICAgICAgICAgICB8ICAgICAmbHQ7bm90aWZpY2F0aW9uJmd0OyAgICAgICAgfAogICAgICAgICAg ICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfAogICAgICAgICAgICAg ICAgICAgICB8ICAgICAgJmx0O25vdGlmaWNhdGlvbiZndDsgICAgICAgfCAocmVwbGF5Q29tcGxl dGUpCiAgICAgICAgICAgICAgICAgICAgIHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18 CiAgICAgICAgICAgICAgICAgICAgIHwgICAgICAmbHQ7bm90aWZpY2F0aW9uJmd0OyAgICAgICB8 KG5vdGlmaWNhdGlvbkNvbXBsZXRlKQogICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tfAogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgICAgICAgICAgICAgICA bnRUeXBlIi8mZ3Q7CiAgICAgICAgJmx0Oy94czpjb21wbGV4Q29udGVudCZndDsKICAgICZsdDsv eHM6Y29tcGxleFR5cGUmZ3Q7CgogICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ibm90aWZpY2F0aW9u Q29tcGxldGUiCiAgICAgICAgdHlwZT0ibWFuYWdlRXZlbnQ6Tm90aWZpY2F0aW9uQ29tcGxldGVO b3RpZmljYXRpb25UeXBlIgogICAgICAgIHN1YnN0aXR1dGlvbkdyb3VwPSJuY0V2ZW50Om5vdGlm aWNhdGlvbkNvbnRlbnQiJmd0OwogICAgICAgICAgICAgICAgJmx0O3hzOmFubm90YXRpb24mZ3Q7 CiAgICAgICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgVGhpcyBub3Rp ZmljYXRpb24gaXMgc2VudCB0byBzaWduYWwgdGhlIGVuZCBvZiBhCiAgICAgICAgICAgIG5vdGlm aWNhdGlvbiBzdWJzY3JpcHRpb24uIEl0IGlzIHNlbnQgaW4gdGhlIGNhc2UKICAgICAgICAgICAg dGhhdCBzdG9wVGltZSB3YXMgc3BlY2lmaWVkIGR1cmluZyB0aGUgY3JlYXRpb24gb2YKICAgICAg ICAgICAgdGhlIHN1YnNjcmlwdGlvbi4KICAgICAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZn dDsKICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgJmx0Oy94czplbGVtZW50 Jmd0OwoKJmx0Oy94czpzY2hlbWEmZ3Q7CgozLjUuICBTdWJzY3JpcHRpb25zIERhdGEKCiAgIFN1 YnNjcmlwdGlvbnMgYXJlIG5vbi1wZXJzaXN0ZW50IHN0YXRlIGluZm9ybWF0aW9uIGFuZCB0aGVp ciBsaWZldGltZQogICBpcyBkZWZpbmVkIGJ5IHRoZWlyIHNlc3Npb24gb3IgYnkgdGhlICZsdDtz dG9wVGltZSZndDsgcGFyYW1ldGVyLgoKMy42LiAgRmlsdGVyIE1lY2hhbmljcwoKICAgPHN0cmlr ZT48Zm9udCBjb2xvcj0ncmVkJz5XaGVuIG11bHRpcGxlIGZpbHRlciBlbGVtZW50cyBhcmUgc3Bl Y2lmaWVkLCB0aGV5IGFyZSBhcHBsaWVkCiAgIGNvbGxlY3RpdmVseSwgc28gZXZlbnQgbm90aWZp Y2F0aW9ucyBuZWVkIHRvIHBhc3MgYWxsIHNwZWNpZmllZAogICBmaWx0ZXIgZWxlbWVudHMgaW4g b3JkZXIgdG8gYmUgc2VudCB0byB0aGUgc3Vic2NyaWJlci48L2ZvbnQ+PC9zdHJpa2U+CgogICBJ ZiBhIGZpbHRlciBlbGVtZW50IGlzIHNwZWNpZmllZCB0byBsb29rIGZvciBkYXRhIG9mIGEgcGFy dGljdWxhcgogICB2YWx1ZSwgYW5kIHRoZSBkYXRhIGl0ZW0gaXMgbm90IHByZXNlbnQgd2l0aGlu IGEgcGFydGljdWxhciBldmVudAogICBub3RpZmljYXRpb24gZm9yIGl0cyB2YWx1ZSB0byBiZSBj aGVja2VkIGFnYWluc3QsIHRoZSBub3RpZmljYXRpb24KICAgd2lsbCBiZSBmaWx0ZXJlZCBvdXQu ICBGb3IgZXhhbXBsZSwgaWYgb25lIHdlcmUgdG8gY2hlY2sgZm9yCiAgICdzZXZlcml0eT1jcml0 aWNhbCcgaW4gYSBjb25maWd1cmF0aW9uIGV2ZW50IG5vdGlmaWNhdGlvbiB3aGVyZSB0aGlzCiAg IGZpZWxkIHdhcyBub3Qgc3VwcG9ydGVkLCB0aGVuIHRoZSBub3RpZmljYXRpb24gd291bGQgYmUg ZmlsdGVyZWQgb3V0LgoKICAgRm9yIHN1YnRyZWUgZmlsdGVyaW5nLCBhIG5vbi1lbXB0eSBub2Rl IHNldCBtZWFucyB0aGF0IHRoZSBmaWx0ZXIKICAgbWF0Y2hlcy4gIEZvciBYUGF0aCBmaWx0ZXJp bmcsIHRoZSBtZWNoYW5pc21zIGRlZmluZWQgaW4gW1hQQVRIXQogICBzaG91bGQgYmUgdXNlZCB0 byBjb252ZXJ0IHRoZSByZXR1cm5lZCB2YWx1ZSB0byBib29sZWFuLgoKMy42LjEuICBGaWx0ZXJp bmcKCiAgIEZpbHRlcmluZyBpcyBleHBsaWNpdGx5IHN0YXRlZCB3aGVuIHRoZSBldmVudCBub3Rp ZmljYXRpb24KICAgc3Vic2NyaXB0aW9uIGlzIGNyZWF0ZWQuICBUaGlzIGlzIHNwZWNpZmllZCB2 aWEgdGhlICdmaWx0ZXInCiAgIHBhcmFtZXRlci4gIEEgRmlsdGVyIG9ubHkgPHN0cmlrZT48Zm9u dCBjb2xvcj0ncmVkJz5leGlzdDwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0n Z3JlZW4nPmV4aXN0czwvZm9udD48L3N0cm9uZz4gYXMgYSBwYXJhbWV0ZXIgdG8gdGhlIHN1YnNj cmlwdGlvbi4KCjMuNy4gIE1lc3NhZ2UgRmxvdwogICBUaGUgZm9sbG93aW5nIGZpZ3VyZSBkZXBp Y3RzIG1lc3NhZ2UgZmxvdyBiZXR3ZWVuIGEgTkVUQ09ORiBjbGllbnQKICAgKEMpIGFuZCBORVRD T05GIHNlcnZlciAoUykgaW4gb3JkZXIgdG8gY3JlYXRlIGEgc3Vic2NyaXB0aW9uIGFuZAogICBi ZWdpbiB0aGUgZmxvdyBvZiBub3RpZmljYXRpb25zLiAgVGhpcyBzdWJzY3JpcHRpb24gc3BlY2lm aWVkIGEKICAgJmx0O3N0YXJ0VGltZSZndDssIHNvIHRoZSBzZXJ2ZXIgc3RhcnRzIGJ5IHJlcGxh eWluZyBsb2dnZWQgbm90aWZpY2F0aW9ucy4KICAgSXQgaXMgcG9zc2libGUgdGhhdCBtYW55IHJw Yy9ycGMtcmVwbHkgc2VxdWVuY2VzIG9jY3VyIGJlZm9yZSB0aGUKICAgc3Vic2NyaXB0aW9uIGlz IGNyZWF0ZWQsIGJ1dCB0aGlzIGlzIG5vdCBkZXBpY3RlZCBpbiB0aGUgZmlndXJlLgoKICAgICAg ICAgICAgICAgICAgICAgICAgQyAgICAgICAgICAgICAgICAgICAgICAgICAgIFMKICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAg ICAgICAgICAgICAgfCAgY2FwYWJpbGl0eSBleGNoYW5nZSAgICAgIHwKICAgICAgICAgICAgICAg ICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wKICAgICAgICAgICAgICAg ICAgICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wKICAgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAg ICAgICAgICAgfCAgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7ICAgIHwgKHN0YXJ0VGltZSkK ICAgICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wK ICAgICAgICAgICAgICAgICAgICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwK ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgJmx0O3JwYy1yZXBseSZndDsgICAgICAgICAg IHwKICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgJmx0O25vdGlmaWNhdGlvbiZndDsgICAgICAg IHwKICAgICAgICAgICAgICAgICAgICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LXwKICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgJmx0O25vdGlmaWNhdGlvbiZndDsgICAgICAg IHwKICAgICAgICAgICAgICAgICAgICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LXwKICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICZsdDtub3RpZmljYXRpb24mZ3Q7ICAg ICAgIHwgKHJlcGxheUNvbXBsZXRlKQogICAgICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAmbHQ7bm90aWZpY2F0 aW9uJmd0OyAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAmbHQ7bm90aWZpY2F0aW9u Jmd0OyAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDMKICAgVGhl IGZvbGxvd2luZyBmaWd1cmUgZGVwaWN0cyBtZXNzYWdlIGZsb3cgYmV0d2VlbiBhIE5FVENPTkYg Y2xpZW50CiAgIChDKSBhbmQgTkVUQ09ORiBzZXJ2ZXIgKFMpIGluIG9yZGVyIHRvIGNyZWF0ZSBh IHN1YnNjcmlwdGlvbiBhbmQKICAgYmVnaW4gdGhlIGZsb3cgb2Ygbm90aWZpY2F0aW9ucy4gIFRo aXMgc3Vic2NyaXB0aW9uIHNwZWNpZmllZCBhCiAgICZsdDtzdGFydFRpbWUmZ3Q7IGFuZCAmbHQ7 c3RvcFRpbWUmZ3Q7IHNvIGl0IHN0YXJ0cyBieSByZXBsYXlpbmcgbG9nZ2VkCiAgIG5vdGlmaWNh dGlvbnMgYW5kIHRoZW4gcmV0dXJucyB0byBiZSBhIG5vcm1hbCBjb21tYW5kLXJlc3BvbnNlCiAg IE5FVENPTkYgc2Vzc2lvbiBhZnRlciB0aGUgJmx0O3JlcGxheUNvbXBsZXRlJmd0OyBhbmQgJmx0 O25vdGlmaWNhdGlvbkNvbXBsZXRlJmd0OwogICBub3RpZmljYXRpb25zIGFyZSBzZW50IGFuZCBp dCBpcyBhdmFpbGFibGUgdG8gcHJvY2VzcyAmbHQ7cnBjJmd0OyByZXF1ZXN0cy4KICAgSXQgaXMg cG9zc2libGUgdGhhdCBtYW55IHJwYy9ycGMtcmVwbHkgc2VxdWVuY2VzIG9jY3VyIGJlZm9yZSB0 aGUKICAgc3Vic2NyaXB0aW9uIGlzIGNyZWF0ZWQsIGJ1dCB0aGlzIGlzIG5vdCBkZXBpY3RlZCBp biB0aGUgZmlndXJlLgoKICAgICAgICAgICAgICAgICAgICAgQyAgICAgICAgICAgICAgICAgICAg ICAgICAgIFMKICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg IHwKICAgICAgICAgICAgICAgICAgICAgfCAgY2FwYWJpbGl0eSBleGNoYW5nZSAgICAgIHwKICAg ICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wKICAgICAg ICAgICAgICAgICAgICAgfCZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wKICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAg ICAgICAgICAgfCAgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7ICAgIHwgKHN0YXJ0VGltZSwK ICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0O3wgIHN0 b3BUaW1lKQogICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tfAogICAgICAgICAgICAgICAgICAgICB8ICAgICAmbHQ7cnBjLXJlcGx5Jmd0OyAgICAgICAg ICAgfAogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAog ICAgICAgICAgICAgICAgICAgICB8ICAgICAmbHQ7bm90aWZpY2F0aW9uJmd0OyAgICAgICAgfAog ICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfAogICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAg ICAgICAgICAgICB8ICAgICAmbHQ7bm90aWZpY2F0aW9uJmd0OyAgICAgICAgfAogICAgICAgICAg ICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfAogICAgICAgICAgICAg ICAgICAgICB8ICAgICAgJmx0O25vdGlmaWNhdGlvbiZndDsgICAgICAgfCAocmVwbGF5Q29tcGxl dGUpCiAgICAgICAgICAgICAgICAgICAgIHwmbHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18 CiAgICAgICAgICAgICAgICAgICAgIHwgICAgICAmbHQ7bm90aWZpY2F0aW9uJmd0OyAgICAgICB8 KG5vdGlmaWNhdGlvbkNvbXBsZXRlKQogICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tfAogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg fAogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICZsdDtycGMmZ3Q7ICAgICAgICAgICAg fAogICAgICAgICAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fAog ICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfAogICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICZsdDtycGMtcmVwbHkmZ3Q7ICAgICAgICAgfAogICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAoKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDQKCjQuICBYTUwgU2NoZW1hIGZvciBFdmVu dCBOb3RpZmljYXRpb25zCgogICBUaGUgZm9sbG93aW5nIFtYTUwgU2NoZW1hXSBkZWZpbmVzIE5F VENPTkYgRXZlbnQgTm90aWZpY2F0aW9ucy4KCiZsdDs/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rp bmc9IlVURi04Ij8mZ3Q7CiAgJmx0O3hzOnNjaGVtYSB4bWxuczp4cz0iaHR0cDovL3d3dy53My5v cmcvMjAwMS9YTUxTY2hlbWEiCiAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0 Y29uZjpub3RpZmljYXRpb246MS4wIgogICAgIHhtbG5zOm5ldGNvbmY9InVybjppZXRmOnBhcmFt czp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCIKICAgICB0YXJnZXROYW1lc3BhY2U9CiAgICAgICAg InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRpb246MS4wIgogICAgIGVs ZW1lbnRGb3JtRGVmYXVsdD0icXVhbGlmaWVkIgogICAgIGF0dHJpYnV0ZUZvcm1EZWZhdWx0PSJ1 bnF1YWxpZmllZCIKICAgICAgIHhtbDpsYW5nPSJlbiImZ3Q7CgogICAgJmx0OyEtLSBpbXBvcnQg c3RhbmRhcmQgWE1MIGRlZmluaXRpb25zIC0tJmd0OwoKICAgICAmbHQ7eHM6aW1wb3J0IG5hbWVz cGFjZT0iaHR0cDovL3d3dy53My5vcmcvWE1MLzE5OTgvbmFtZXNwYWNlIgogICAgICAgICAgICAg ICAgc2NoZW1hTG9jYXRpb249Imh0dHA6Ly93d3cudzMub3JnLzIwMDEveG1sLnhzZCImZ3Q7CiAg ICAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24m Z3Q7CiAgICAgICAgICAgVGhpcyBpbXBvcnQgYWNjZXNzZXMgdGhlIHhtbDogYXR0cmlidXRlIGdy b3VwcyBmb3IgdGhlCiAgICAgICAgICAgeG1sOmxhbmcgYXMgZGVjbGFyZWQgb24gdGhlIGVycm9y LW1lc3NhZ2UgZWxlbWVudC4KICAgICAgICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAg ICAgJmx0Oy94czphbm5vdGF0aW9uJmd0OwogICAgICZsdDsveHM6aW1wb3J0Jmd0OwoKICAgICAm bHQ7IS0tIGltcG9ydCBiYXNlIG5ldGNvbmYgZGVmaW5pdGlvbnMgLS0mZ3Q7CiAgICAgJmx0O3hz OmltcG9ydCBuYW1lc3BhY2U9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEu MCIKICAgICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+c2NoZW1hTG9jYXRpb249CiAgICAg Imh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMveG1sLXJlZ2lzdHJ5L3NjaGVtYS9uZXRj b25mLnhzZCIvJmd0OzwvZm9udD48L3N0cmlrZT4KICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9 J2dyZWVuJz5zY2hlbWFMb2NhdGlvbj0ibmV0Y29uZi54c2QiLyZndDs8L2ZvbnQ+PC9zdHJvbmc+ CgombHQ7IS0tICoqKioqKioqKioqKioqIFN5bW1ldHJpY2FsIE9wZXJhdGlvbnMgICoqKioqKioq KioqKioqKioqKioqLS0mZ3Q7CgogICAgICZsdDshLS0gJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24m Z3Q7IG9wZXJhdGlvbiAtLSZndDsKCiAgICAmbHQ7eHM6Y29tcGxleFR5cGUgbmFtZT0iY3JlYXRl U3Vic2NyaXB0aW9uVHlwZSImZ3Q7CiAgICAgICAgJmx0O3hzOmNvbXBsZXhDb250ZW50Jmd0Owog ICAgICAgICAgICAmbHQ7eHM6ZXh0ZW5zaW9uIGJhc2U9Im5ldGNvbmY6cnBjT3BlcmF0aW9uVHlw ZSImZ3Q7CiAgICAgICAgICAgICAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICAgICAgICAg ICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic3RyZWFtIgogICAgICAgICAgICAgICAgICAgICAg ICB0eXBlPSJzdHJlYW1OYW1lVHlwZSIgbWluT2NjdXJzPSIwIiZndDsKICAgICAgICAgICAgICAg ICAgICAgICAgJmx0O3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEFuIG9wdGlvbmFsIHBhcmFtZXRlciB0aGF0IGluZGljYXRlcwogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgd2hpY2ggc3RyZWFtIG9mIGV2ZW50cyBpcyBvZiBpbnRlcmVzdC4gSWYKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vdCBwcmVzZW50LCB0aGVuIGV2ZW50cyBpbiB0 aGUgZGVmYXVsdAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTkVUQ09ORiBzdHJlYW0g d2lsbCBiZSBzZW50LgogICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czpkb2N1bWVu dGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7 CiAgICAgICAgICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgICAg ICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJmaWx0ZXIiCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICB0eXBlPSJuZXRjb25mOmZpbHRlcklubGluZVR5cGUiCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICBtaW5PY2N1cnM9IjAiJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAg Jmx0O3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0 O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEFuIG9wdGlvbmFsIHBhcmFtZXRlciB0aGF0IGluZGljYXRlcwogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB3aGljaCBzdWJzZXQgb2YgYWxsIHBvc3NpYmxlIGV2ZW50cwogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpcyBvZiBpbnRlcmVzdC4gVGhlIGZvcm1h dCBvZiB0aGlzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhcmFtZXRlciBp cyB0aGUgc2FtZSBhcyB0aGF0IG9mIHRoZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBmaWx0ZXIgcGFyYW1ldGVyIGluIHRoZSBORVRDT05GCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHByb3RvY29sIG9wZXJhdGlvbnMuIElmIG5vdCBwcmVzZW50LAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbGwgZXZlbnRzIG5vdCBwcmVjbHVkZWQg Ynkgb3RoZXIKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFyYW1ldGVycyB3 aWxsIGJlIHNlbnQuCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czpkb2N1 bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czphbm5vdGF0 aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmVsZW1lbnQmZ3Q7CiAgICAg ICAgICAgICAgICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic3RhcnRUaW1lIiB0eXBlPSJ4czpk YXRlVGltZSIKICAgICAgICAgICAgICAgICAgICAgICAgbWluT2NjdXJzPSIwIiAmZ3Q7CiAgICAg ICAgICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAg ICAgICAgICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQSBwYXJhbWV0ZXIgdXNlZCB0byB0cmlnZ2VyIHRoZSByZXBsYXkKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBmZWF0dXJlIGFuZCBpbmRpY2F0ZXMgdGhhdCB0aGUg cmVwbGF5CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2hvdWxkIHN0YXJ0IGF0IHRo ZSB0aW1lIHNwZWNpZmllZC4gSWYKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdGFy dCB0aW1lIGlzIG5vdCBwcmVzZW50LCB0aGlzIGlzIG5vdCBhCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgcmVwbGF5IHN1YnNjcmlwdGlvbi4KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICAgJmx0 Oy94czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZWxlbWVudCZn dDsKICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJzdG9wVGltZSIgdHlw ZT0ieHM6ZGF0ZVRpbWUiCiAgICAgICAgICAgICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIgJmd0 OwogICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICZsdDt4czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEFuIG9wdGlvbmFsIHBhcmFtZXRlciB1c2VkIHdpdGggdGhlCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb3B0aW9uYWwgcmVwbGF5IGZlYXR1cmUgdG8g aW5kaWNhdGUgdGhlCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV3ZXN0IG5vdGlm aWNhdGlvbnMgb2YgaW50ZXJlc3QuIElmCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg c3RvcCB0aW1lIGlzIG5vdCBwcmVzZW50LCB0aGUKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBub3RpZmljYXRpb25zIHdpbGwgY29udGludWUgdW50aWwgdGhlCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgc3Vic2NyaXB0aW9uIGlzIHRlcm1pbmF0ZWQuIE11c3QgYmUgdXNl ZAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdpdGggc3RhcnRUaW1lLgogICAgICAg ICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAg ICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAg Jmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgICAgJmx0Oy94czpzZXF1ZW5jZSZndDsK ICAgICAgICAgICAgJmx0Oy94czpleHRlbnNpb24mZ3Q7CiAgICAgICAgJmx0Oy94czpjb21wbGV4 Q29udGVudCZndDsKICAgICZsdDsveHM6Y29tcGxleFR5cGUmZ3Q7CgogICAgJmx0O3hzOnNpbXBs ZVR5cGUgbmFtZT0ic3RyZWFtTmFtZVR5cGUiJmd0OwogICAgICAgICZsdDt4czphbm5vdGF0aW9u Jmd0OwogICAgICAgICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAg IFRoZSBuYW1lIG9mIGFuIGV2ZW50IHN0cmVhbS4KICAgICAgICAgICAgJmx0Oy94czpkb2N1bWVu dGF0aW9uJmd0OwogICAgICAgICZsdDsveHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAmbHQ7eHM6 cmVzdHJpY3Rpb24gYmFzZT0ieHM6c3RyaW5nIi8mZ3Q7CiAgICAmbHQ7L3hzOnNpbXBsZVR5cGUm Z3Q7CgogICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iY3JlYXRlLXN1YnNjcmlwdGlvbiIKICAgICAg ICB0eXBlPSJjcmVhdGVTdWJzY3JpcHRpb25UeXBlIgogICAgICAgIHN1YnN0aXR1dGlvbkdyb3Vw PSJuZXRjb25mOnJwY09wZXJhdGlvbiImZ3Q7CiAgICAgICAgJmx0O3hzOmFubm90YXRpb24mZ3Q7 CiAgICAgICAgICAgICZsdDt4czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgVGhl IGNvbW1hbmQgdG8gY3JlYXRlIGEgbm90aWZpY2F0aW9uIHN1YnNjcmlwdGlvbi4gSXQKICAgICAg ICAgICAgICAgIHRha2VzIGFzIGFyZ3VtZW50IHRoZSBuYW1lIG9mIHRoZSBub3RpZmljYXRpb24g c3RyZWFtCiAgICAgICAgICAgICAgICBhbmQgZmlsdGVyLiBCb3RoIG9mIHRob3NlIG9wdGlvbnMK ICAgICAgICAgICAgICAgIGxpbWl0IHRoZSBjb250ZW50IG9mIHRoZSBzdWJzY3JpcHRpb24uIElu IGFkZGl0aW9uLAogICAgICAgICAgICAgICAgdGhlcmUgYXJlIHR3byB0aW1lLXJlbGF0ZWQgcGFy YW1ldGVycywgc3RhcnRUaW1lIGFuZAogICAgICAgICAgICAgICAgc3RvcFRpbWUsIHdoaWNoIGNh biBiZSB1c2VkIHRvIHNlbGVjdCB0aGUgdGltZSBpbnRlcnZhbAogICAgICAgICAgICAgICAgb2Yg aW50ZXJlc3QgdG8gdGhlIG5vdGlmaWNhdGlvbiByZXBsYXkgZmVhdHVyZS4KICAgICAgICAgICAg Jmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICZsdDsveHM6YW5ub3RhdGlvbiZndDsK ICAgICZsdDsveHM6ZWxlbWVudCZndDsKCiZsdDshLS0gKioqKioqKioqKioqKiogT25lLXdheSBP cGVyYXRpb25zICAqKioqKioqKioqKioqKioqKiotLSZndDsKCiAgICAgJmx0OyEtLSAmbHQ7Tm90 aWZpY2F0aW9uJmd0OyBvcGVyYXRpb24gLS0mZ3Q7CiAgICAgJmx0O3hzOmNvbXBsZXhUeXBlIG5h bWU9Ik5vdGlmaWNhdGlvbkNvbnRlbnRUeXBlIi8mZ3Q7CgogICAgJmx0O3hzOmVsZW1lbnQgbmFt ZT0ibm90aWZpY2F0aW9uQ29udGVudCIKICAgICAgICB0eXBlPSJOb3RpZmljYXRpb25Db250ZW50 VHlwZSIgYWJzdHJhY3Q9InRydWUiLyZndDsKCiAgICAmbHQ7eHM6Y29tcGxleFR5cGUgbmFtZT0i Tm90aWZpY2F0aW9uVHlwZSImZ3Q7CiAgICAgICAgJmx0O3hzOnNlcXVlbmNlJmd0OwogICAgICAg ICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJldmVudFRpbWUiIHR5cGU9InhzOmRhdGVUaW1lIiZn dDsKICAgICAgICAgICAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgICAgICAgICZs dDt4czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgVGhlIHRpbWUgdGhlIGV2ZW50 IHdhcyBnZW5lcmF0ZWQgYnkgdGhlIGV2ZW50IHNvdXJjZQogICAgICAgICAgICAgICAgJmx0Oy94 czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICZsdDsveHM6YW5ub3RhdGlvbiZndDsK ICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAmbHQ7eHM6ZWxlbWVu dCByZWY9Im5vdGlmaWNhdGlvbkNvbnRlbnQiLyZndDsKICAgICAgICAmbHQ7L3hzOnNlcXVlbmNl Jmd0OwogICAgJmx0Oy94czpjb21wbGV4VHlwZSZndDsKCiAgICAmbHQ7eHM6ZWxlbWVudCBuYW1l PSJub3RpZmljYXRpb24iIHR5cGU9Ik5vdGlmaWNhdGlvblR5cGUiLyZndDsKCiAgJmx0Oy94czpz Y2hlbWEmZ3Q7Cgo1LiAgRmlsdGVyaW5nIEV4YW1wbGVzCgogICBUaGUgZm9sbG93aW5nIHNlY3Rp b24gcHJvdmlkZXMgZXhhbXBsZXMgdG8gaWxsdXN0cmF0ZSB0aGUgdmFyaW91cwogICBtZXRob2Rz IG9mIGZpbHRlcmluZyBjb250ZW50IG9uIGFuIGV2ZW50IG5vdGlmaWNhdGlvbiBzdWJzY3JpcHRp b24uCgogICBJbiBvcmRlciB0byBpbGx1c3RyYXRlIHRoZSB1c2Ugb2YgZmlsdGVyIGV4cHJlc3Np b25zLCBpdCBpcyBuZWNlc3NhcnkKICAgdG8gYXNzdW1lIHNvbWUgb2YgdGhlIGV2ZW50IG5vdGlm aWNhdGlvbiBjb250ZW50LiAgVGhlIGV4YW1wbGVzIGJlbG93CiAgIGFzc3VtZSB0aGF0IHRoZSBl dmVudCBub3RpZmljYXRpb24gc2NoZW1hIGRlZmluaXRpb24gaGFzIGFuICZsdDtldmVudCZndDsK ICAgZWxlbWVudCBhdCB0aGUgdG9wIGxldmVsIGNvbnNpc3Rpbmcgb2YgdGhlIGV2ZW50IGNsYXNz IChlLmcuLCBmYXVsdCwKICAgc3RhdGUsIGNvbmZpZyksIHJlcG9ydGluZyBlbnRpdHkgYW5kIGVp dGhlciBzZXZlcml0eSBvciBvcGVyYXRpb25hbAogICBzdGF0ZS4KCiAgIEV4YW1wbGVzIGluIHRo aXMgc2VjdGlvbiBhcmUgZ2VuZXJhdGVkIGZyb20gdGhlIGZvbGxvd2luZyBmaWN0aW9uYWwKICAg U2NoZW1hLgoKICAgICZsdDs/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8mZ3Q7 CiAgICZsdDt4czpzY2hlbWEgdGFyZ2V0TmFtZXNwYWNlPSJodHRwOi8vZXhhbXBsZS5jb20vZXZl bnQvMS4wIgogICAgICAgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ldmVudC8xLjAiCiAgICAg ICBlbGVtZW50Rm9ybURlZmF1bHQ9InF1YWxpZmllZCIKICAgICAgIHhtbG5zOnhzPSJodHRwOi8v d3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIKICAgICAgIHhtbG5zOm5jRXZlbnQ9InVybjppZXRm OnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRpb246MS4wIiZndDsKCiAgICAgICAmbHQ7 eHM6aW1wb3J0IG5hbWVzcGFjZT0KICAgICAgICAgICAidXJuOmlldGY6cGFyYW1zOnhtbDpuczpu ZXRjb25mOm5vdGlmaWNhdGlvbjoxLjAiCiAgICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVk Jz5zY2hlbWFMb2NhdGlvbj0KImh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMveG1sLXJl Z2lzdHJ5L3NjaGVtYS9ub3RpZmljYXRpb24ueHNkIi8mZ3Q7PC9mb250Pjwvc3RyaWtlPgogICAg ICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5zY2hlbWFMb2NhdGlvbj0ibm90aWZp Y2F0aW9uLnhzZCIvJmd0OzwvZm9udD48L3N0cm9uZz4KCiAgICAgICAmbHQ7eHM6Y29tcGxleFR5 cGUgbmFtZT0iZXZlbnRUeXBlIiZndDsKICAgICAgICAgICAmbHQ7eHM6Y29tcGxleENvbnRlbnQm Z3Q7CiAgICAgICAgICAgICAgICZsdDt4czpleHRlbnNpb24gYmFzZT0ibmNFdmVudDpOb3RpZmlj YXRpb25Db250ZW50VHlwZSImZ3Q7CiAgICAgICAgICAgICAgICAgICAmbHQ7eHM6c2VxdWVuY2Um Z3Q7CiAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iZXZlbnRDbGFz cyIgLyZndDsKICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJyZXBv cnRpbmdFbnRpdHkiJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6Y29tcGxl eFR5cGUmZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6c2VxdWVuY2Um Z3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmFueSBuYW1lc3Bh Y2U9IiMjYW55IgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByb2Nlc3NDb250 ZW50cz0ibGF4Ii8mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOnNl cXVlbmNlJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmNvbXBsZXhUeXBl Jmd0OwogICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZWxlbWVudCZndDsKICAgICAgICAg ICAgICAgICAgICAgICAmbHQ7eHM6Y2hvaWNlJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAg ICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJzZXZlcml0eSIvJmd0OwogICAgICAgICAgICAgICAgICAg ICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJvcGVyU3RhdGUiLyZndDsKICAgICAgICAgICAg ICAgICAgICAgICAmbHQ7L3hzOmNob2ljZSZndDsKICAgICAgICAgICAgICAgICAgICZsdDsveHM6 c2VxdWVuY2UmZ3Q7CiAgICAgICAgICAgICAgICZsdDsveHM6ZXh0ZW5zaW9uJmd0OwogICAgICAg ICAgICZsdDsveHM6Y29tcGxleENvbnRlbnQmZ3Q7CiAgICAgICAmbHQ7L3hzOmNvbXBsZXhUeXBl Jmd0OwoKICAgICAgICZsdDt4czplbGVtZW50IG5hbWU9ImV2ZW50IgogICAgICAgICAgIHR5cGU9 ImV2ZW50VHlwZSIKICAgICAgICAgICBzdWJzdGl0dXRpb25Hcm91cD0ibmNFdmVudDpub3RpZmlj YXRpb25Db250ZW50Ii8mZ3Q7CgogICAmbHQ7L3hzOnNjaGVtYSZndDsKCiAgIFRoZSBhYm92ZSBm aWN0aW9uYWwgbm90aWZpY2F0aW9uIGRlZmluaXRpb24gY291bGQgcmVzdWx0IGluIHRoZQogICBm b2xsb3dpbmcgc2FtcGxlIG5vdGlmaWNhdGlvbiBsaXN0LCB3aGljaCBpcyB1c2VkIGluIHRoZSBl eGFtcGxlcyBpbgogICB0aGlzIHNlY3Rpb24uCgogICAmbHQ7bm90aWZpY2F0aW9uCiAgICAgIHht bG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6bm90aWZpY2F0aW9uOjEuMCImZ3Q7 CiAgICAgICZsdDtldmVudFRpbWUmZ3Q7MjAwNy0wNy0wOFQwMDowMTowMFombHQ7L2V2ZW50VGlt ZSZndDsKICAgICAgJmx0O2V2ZW50IHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4w IiZndDsKICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7ZmF1bHQmbHQ7L2V2ZW50Q2xhc3MmZ3Q7 CiAgICAgICAgICZsdDtyZXBvcnRpbmdFbnRpdHkmZ3Q7CiAgICAgICAgICAgICAmbHQ7Y2FyZCZn dDtFdGhlcm5ldDAmbHQ7L2NhcmQmZ3Q7CiAgICAgICAgICZsdDsvcmVwb3J0aW5nRW50aXR5Jmd0 OwogICAgICAgICAmbHQ7c2V2ZXJpdHkmZ3Q7bWFqb3ImbHQ7L3NldmVyaXR5Jmd0OwogICAgICAg Jmx0Oy9ldmVudCZndDsKICAgJmx0Oy9ub3RpZmljYXRpb24mZ3Q7CgogICAmbHQ7bm90aWZpY2F0 aW9uCiAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRp b246MS4wIiZndDsKICAgICAgJmx0O2V2ZW50VGltZSZndDsyMDA3LTA3LTA4VDAwOjAyOjAwWiZs dDsvZXZlbnRUaW1lJmd0OwogICAgICAmbHQ7ZXZlbnQgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNv bS9ldmVudC8xLjAiJmd0OwogICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7ZmF1bHQmbHQ7L2V2 ZW50Q2xhc3MmZ3Q7CiAgICAgICAgICAmbHQ7cmVwb3J0aW5nRW50aXR5Jmd0OwogICAgICAgICAg ICAgICZsdDtjYXJkJmd0O0V0aGVybmV0MiZsdDsvY2FyZCZndDsKICAgICAgICAgICZsdDsvcmVw b3J0aW5nRW50aXR5Jmd0OwogICAgICAgICAgJmx0O3NldmVyaXR5Jmd0O2NyaXRpY2FsJmx0Oy9z ZXZlcml0eSZndDsKICAgICAgICZsdDsvZXZlbnQmZ3Q7CiAgICZsdDsvbm90aWZpY2F0aW9uJmd0 OwoKICAgJmx0O25vdGlmaWNhdGlvbgogICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5z Om5ldGNvbmY6bm90aWZpY2F0aW9uOjEuMCImZ3Q7CiAgICAgICZsdDtldmVudFRpbWUmZ3Q7MjAw Ny0wNy0wOFQwMDowNDowMFombHQ7L2V2ZW50VGltZSZndDsKICAgICAgJmx0O2V2ZW50IHhtbG5z PSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIiZndDsKICAgICAgICAgICZsdDtldmVudENs YXNzJmd0O2ZhdWx0Jmx0Oy9ldmVudENsYXNzJmd0OwogICAgICAgICAgJmx0O3JlcG9ydGluZ0Vu dGl0eSZndDsKICAgICAgICAgICAgICAgJmx0O2NhcmQmZ3Q7QVRNMSZsdDsvY2FyZCZndDsKICAg ICAgICAgICAmbHQ7L3JlcG9ydGluZ0VudGl0eSZndDsKICAgICAgICAgICAmbHQ7c2V2ZXJpdHkm Z3Q7bWlub3ImbHQ7L3NldmVyaXR5Jmd0OwogICAgICAmbHQ7L2V2ZW50Jmd0OwogICAmbHQ7L25v dGlmaWNhdGlvbiZndDsKCiAgICZsdDtub3RpZmljYXRpb24KICAgICB4bWxucz0idXJuOmlldGY6 cGFyYW1zOnhtbDpuczpuZXRjb25mOm5vdGlmaWNhdGlvbjoxLjAiJmd0OwogICAgICZsdDtldmVu dFRpbWUmZ3Q7MjAwNy0wNy0wOFQwMDoxMDowMFombHQ7L2V2ZW50VGltZSZndDsKICAgICAmbHQ7 ZXZlbnQgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ldmVudC8xLjAiJmd0OwogICAgICAgICAm bHQ7ZXZlbnRDbGFzcyZndDtzdGF0ZSZsdDsvZXZlbnRDbGFzcyZndDsKICAgICAgICAgJmx0O3Jl cG9ydGluZ0VudGl0eSZndDsKICAgICAgICAgICAgICZsdDtjYXJkJmd0O0V0aGVybmV0MCZsdDsv Y2FyZCZndDsKICAgICAgICAgJmx0Oy9yZXBvcnRpbmdFbnRpdHkmZ3Q7CiAgICAgICAgICZsdDtv cGVyU3RhdGUmZ3Q7ZW5hYmxlZCZsdDsvb3BlclN0YXRlJmd0OwogICAgICAmbHQ7L2V2ZW50Jmd0 OwogICAmbHQ7L25vdGlmaWNhdGlvbiZndDsKCjUuMS4gIFN1YnRyZWUgRmlsdGVyaW5nCgogICBY TUwgc3VidHJlZSBmaWx0ZXJpbmcgaXMgbm90IHdlbGwtc3VpdGVkIGZvciBjcmVhdGluZyBlbGFi b3JhdGUKICAgZmlsdGVyIGRlZmluaXRpb25zIGdpdmVuIHRoYXQgaXQgb25seSBzdXBwb3J0cyBl cXVhbGl0eSBjb21wYXJpc29ucwogICBhbmQgYXBwbGljYXRpb24gb2YgdGhlIGxvZ2ljYWwgT1Ig b3BlcmF0b3JzIChlLmcuLCBpbiBhbiBldmVudAogICBzdWJ0cmVlIGdpdmUgbWUgYWxsIGV2ZW50 IG5vdGlmaWNhdGlvbnMgd2hpY2ggaGF2ZSBzZXZlcml0eT1jcml0aWNhbAogICBvciBzZXZlcml0 eT1tYWpvciBvciBzZXZlcml0eT1taW5vcikuICBOZXZlcnRoZWxlc3MsIGl0IG1heSBiZSB1c2Vk CiAgIGZvciBkZWZpbmluZyBzaW1wbGUgZXZlbnQgbm90aWZpY2F0aW9uIGZvcndhcmRpbmcgZmls dGVycyBhcyBzaG93bgogICBiZWxvdy4KCiAgIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSBpbGx1c3Ry YXRlcyBob3cgdG8gc2VsZWN0IGZhdWx0IGV2ZW50cyB3aGljaAogICBoYXZlIHNldmVyaXRpZXMg b2YgY3JpdGljYWwsIG1ham9yLCBvciBtaW5vci4gIFRoZSBmaWx0ZXJpbmcgY3JpdGVyaWEKICAg ZXZhbHVhdGlvbiBpcyBhcyBmb2xsb3dzOgoKICAgKChmYXVsdCAmYW1wOyBzZXZlcml0eT1jcml0 aWNhbCkgfCAoZmF1bHQgJmFtcDsgc2V2ZXJpdHk9bWFqb3IpIHwgKGZhdWx0ICZhbXA7CiAgIHNl dmVyaXR5PW1pbm9yKSkKCiAgICAgICAgJmx0O25ldGNvbmY6cnBjIG5ldGNvbmY6bWVzc2FnZS1p ZD0iMTAxIgogICAgICAgICAgICAgICAgeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6cGFyYW1zOnht bDpuczpuZXRjb25mOmJhc2U6MS4wIiZndDsKICAgICAgICAgICZsdDtjcmVhdGUtc3Vic2NyaXB0 aW9uCiAgICAgICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpu b3RpZmljYXRpb246MS4wIiZndDsKICAgICAgICAgICAgJmx0O2ZpbHRlciBuZXRjb25mOnR5cGU9 InN1YnRyZWUiJmd0OwogICAgICAgICAgICAgICZsdDtldmVudCB4bWxucz0iaHR0cDovL2V4YW1w bGUuY29tL2V2ZW50LzEuMCImZ3Q7CiAgICAgICAgICAgICAgICAmbHQ7ZXZlbnRDbGFzcyZndDtm YXVsdCZsdDsvZXZlbnRDbGFzcyZndDsKICAgICAgICAgICAgICAgICZsdDtzZXZlcml0eSZndDtj cml0aWNhbCZsdDsvc2V2ZXJpdHkmZ3Q7CiAgICAgICAgICAgICAgJmx0Oy9ldmVudCZndDsKICAg ICAgICAgICAgICAmbHQ7ZXZlbnQgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ldmVudC8xLjAi Jmd0OwogICAgICAgICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7ZmF1bHQmbHQ7L2V2ZW50Q2xh c3MmZ3Q7CiAgICAgICAgICAgICAgICAmbHQ7c2V2ZXJpdHkmZ3Q7bWFqb3ImbHQ7L3NldmVyaXR5 Jmd0OwogICAgICAgICAgICAgICZsdDsvZXZlbnQmZ3Q7CiAgICAgICAgICAgICAgJmx0O2V2ZW50 IHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIiZndDsKICAgICAgICAgICAgICAg ICZsdDtldmVudENsYXNzJmd0O2ZhdWx0Jmx0Oy9ldmVudENsYXNzJmd0OwogICAgICAgICAgICAg ICAgJmx0O3NldmVyaXR5Jmd0O21pbm9yJmx0Oy9zZXZlcml0eSZndDsKICAgICAgICAgICAgICAm bHQ7L2V2ZW50Jmd0OwogICAgICAgICAgICAmbHQ7L2ZpbHRlciZndDsKICAgICAgICAgICZsdDsv Y3JlYXRlLXN1YnNjcmlwdGlvbiZndDsKICAgICAgICAmbHQ7L25ldGNvbmY6cnBjJmd0OwoKICAg VGhlIGZvbGxvd2luZyBleGFtcGxlIGlsbHVzdHJhdGVzIGhvdyB0byBzZWxlY3Qgc3RhdGUgb3Ig Y29uZmlnCiAgIEV2ZW50Q2xhc3NlcyBvciBmYXVsdCBldmVudHMgdGhhdCBhcmUgcmVsYXRlZCB0 byBjYXJkIEV0aGVybmV0MC4gIFRoZQogICBmaWx0ZXJpbmcgY3JpdGVyaWEgZXZhbHVhdGlvbiBp cyBhcyBmb2xsb3dzOgoKICAgKCBzdGF0ZSB8IGNvbmZpZyB8ICggZmF1bHQgJmFtcDsgKCBjYXJk PUV0aGVybmV0MCkpKQoKJmx0O25ldGNvbmY6cnBjIG5ldGNvbmY6bWVzc2FnZS1pZD0iMTAxIgog ICAgICAgICAgICAgICAgeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRj b25mOmJhc2U6MS4wIiZndDsKICAgICAgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24KICAgICAgICAg IHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6bm90aWZpY2F0aW9uOjEuMCIm Z3Q7CiAgICAgICAgJmx0O2ZpbHRlciBuZXRjb25mOnR5cGU9InN1YnRyZWUiJmd0OwogICAgICAg ICAgJmx0O2V2ZW50IHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIiZndDsKICAg ICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7c3RhdGUmbHQ7L2V2ZW50Q2xhc3MmZ3Q7CiAgICAg ICAgICAmbHQ7L2V2ZW50Jmd0OwogICAgICAgICAgJmx0O2V2ZW50IHhtbG5zPSJodHRwOi8vZXhh bXBsZS5jb20vZXZlbnQvMS4wIiZndDsKICAgICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7Y29u ZmlnJmx0Oy9ldmVudENsYXNzJmd0OwogICAgICAgICAgJmx0Oy9ldmVudCZndDsKICAgICAgICAg ICZsdDtldmVudCB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL2V2ZW50LzEuMCImZ3Q7CiAgICAg ICAgICAgICZsdDtldmVudENsYXNzJmd0O2ZhdWx0Jmx0Oy9ldmVudENsYXNzJmd0OwogICAgICAg ICAgICAmbHQ7cmVwb3J0aW5nRW50aXR5Jmd0OwogICAgICAgICAgICAgICZsdDtjYXJkJmd0O0V0 aGVybmV0MCZsdDsvY2FyZCZndDsKICAgICAgICAgICAgJmx0Oy9yZXBvcnRpbmdFbnRpdHkmZ3Q7 CiAgICAgICAgICAmbHQ7L2V2ZW50Jmd0OwogICAgICAgICZsdDsvZmlsdGVyJmd0OwogICAgICAm bHQ7L2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7CiZsdDsvbmV0Y29uZjpycGMmZ3Q7Cgo1LjIuICBY UEFUSCBmaWx0ZXJzCgogICBUaGUgZm9sbG93aW5nIFtYUEFUSF0gZXhhbXBsZSBpbGx1c3RyYXRl cyBob3cgdG8gc2VsZWN0IGZhdWx0CiAgIEV2ZW50Q2xhc3Mgbm90aWZpY2F0aW9ucyB0aGF0IGhh dmUgc2V2ZXJpdGllcyBvZiBjcml0aWNhbCwgbWFqb3IsIG9yCiAgIG1pbm9yLiAgVGhlIGZpbHRl cmluZyBjcml0ZXJpYSBldmFsdWF0aW9uIGlzIGFzIGZvbGxvd3M6CgogICAoKGZhdWx0KSAmYW1w OyAoKHNldmVyaXR5PWNyaXRpY2FsKSB8IChzZXZlcml0eT1tYWpvcikgfCAoc2V2ZXJpdHkgPQog ICBtaW5vcikpKQoKICAgICAgJmx0O25ldGNvbmY6cnBjIG5ldGNvbmY6bWVzc2FnZS1pZD0iMTAx IgogICAgICAgICAgICAgICAgeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpu ZXRjb25mOmJhc2U6MS4wIiZndDsKICAgICAgICAmbHQ7Y3JlYXRlLXN1YnNjcmlwdGlvbgogICAg ICAgICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6bm90aWZpY2F0 aW9uOjEuMCImZ3Q7CiAgICAgICAgICAmbHQ7ZmlsdGVyIG5ldGNvbmY6dHlwZT0ieHBhdGgiCiAg ICAgICAgICAgICAgICAgIHhtbG5zOmV4PSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIgog ICAgICAgICAgICAgc2VsZWN0PSIvZXg6ZXZlbnRbZXg6ZXZlbnRDbGFzcz0nZmF1bHQnIGFuZAog ICAgICAgICAgICAgICAgICAoZXg6c2V2ZXJpdHk9J21pbm9yJyBvciBleDpzZXZlcml0eT0nbWFq b3InCiAgICAgICAgICAgICAgICAgICAgICAgb3IgZXg6c2V2ZXJpdHk9J2NyaXRpY2FsJyldIi8m Z3Q7CiAgICAgICAgJmx0Oy9jcmVhdGUtc3Vic2NyaXB0aW9uJmd0OwogICAgICAmbHQ7L25ldGNv bmY6cnBjJmd0OwogICBUaGUgZm9sbG93aW5nIGV4YW1wbGUgaWxsdXN0cmF0ZXMgaG93IHRvIHNl bGVjdCBzdGF0ZSBhbmQgY29uZmlnCiAgIEV2ZW50Q2xhc3NlcyBvciBmYXVsdCBldmVudHMgb2Yg YW55IHNldmVyaXR5IHRoYXQgY29tZSBmcm9tIGNhcmQKICAgRXRoZXJuZXQwLiAgVGhlIGZpbHRl cmluZyBjcml0ZXJpYSBldmFsdWF0aW9uIGlzIGFzIGZvbGxvd3M6CgogICAoIHN0YXRlIHwgY29u ZmlnIHwgKGZhdWx0ICZhbXA7IGNhcmQ9RXRoZXJuZXQwKSkKCiAgICAgICZsdDtuZXRjb25mOnJw YyBtZXNzYWdlLWlkPSIxMDEiCiAgICAgICAgICAgICAgeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6 cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIiZndDsKICAgICAgICAmbHQ7Y3JlYXRlLXN1 YnNjcmlwdGlvbgogICAgICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNv bmY6bm90aWZpY2F0aW9uOjEuMCImZ3Q7CiAgICAgICAgICAgICAmbHQ7ZmlsdGVyIG5ldGNvbmY6 dHlwZT0ieHBhdGgiCiAgICAgICAgICAgICAgICAgICAgIHhtbG5zOmV4PSJodHRwOi8vZXhhbXBs ZS5jb20vZXZlbnQvMS4wIgogICAgICAgICAgICAgICAgc2VsZWN0PSIvZXg6ZXZlbnRbCiAgICAg ICAgICAgICAgICAgICAoZXg6ZXZlbnRDbGFzcz0nc3RhdGUnIG9yIGV4OmV2ZW50Q2xhc3M9J2Nv bmZpZycpIG9yCiAgICAgICAgICAgICAgICAgICAoKGV4OmV2ZW50Q2xhc3M9J2ZhdWx0JyBhbmQg ZXg6Y2FyZD0nRXRoZXJuZXQwJykpXSIvJmd0OwogICAgICAgJmx0Oy9jcmVhdGUtc3Vic2NyaXB0 aW9uJmd0OwogICAgICZsdDsvbmV0Y29uZjpycGMmZ3Q7Cgo2LiAgSW50ZXJsZWF2ZSBDYXBhYmls aXR5Cgo2LjEuICBEZXNjcmlwdGlvbgoKICAgVGhlIEludGVybGVhdmUgY2FwYWJpbGl0eSBpbmRp Y2F0ZXMgdGhhdCB0aGUgTkVUQ09ORiBwZWVyIHN1cHBvcnRzCiAgIHRoZSBhYmlsaXR5IHRvIGlu dGVybGVhdmUgb3RoZXIgTkVUQ09ORiBvcGVyYXRpb25zIHdpdGhpbiBhCiAgIE5vdGlmaWNhdGlv biBzdWJzY3JpcHRpb24uICBUaGlzIG1lYW5zIHRoZSBORVRDT05GIHNlcnZlciBNVVNUCiAgIHJl Y2VpdmUsIHByb2Nlc3MgYW5kIHJlc3BvbmQgdG8gTkVUQ09ORiByZXF1ZXN0cyBvbiBhIHNlc3Np b24gd2l0aCBhbgogICBhY3RpdmUgbm90aWZpY2F0aW9uIHN1YnNjcmlwdGlvbi4gIDxzdHJvbmc+ PGZvbnQgY29sb3I9J2dyZWVuJz5UaGlzIGNhcGFiaWxpdHkgaGVscHMgc2NhbGFiaWxpdHkKICAg YnkgcmVkdWNpbmcgdGhlIHRvdGFsIG51bWJlciBvZiBORVRDT05GIHNlc3Npb25zIHJlcXVpcmVk IGJ5IGEgZ2l2ZW4KICAgb3BlcmF0b3Igb3IgbWFuYWdlbWVudCBhcHBsaWNhdGlvbi48L2ZvbnQ+ PC9zdHJvbmc+Cgo2LjIuICBEZXBlbmRlbmNpZXMKCiAgIFRoaXMgY2FwYWJpbGl0eSBpcyBkZXBl bmRhbnQgb24gdGhlIG5vdGlmaWNhdGlvbiBjYXBhYmlsaXR5IGJlaW5nCiAgIHN1cHBvcnRlZC4K CjYuMy4gIENhcGFiaWxpdHkgSWRlbnRpZmllcgoKICAgVGhlIDppbnRlcmxlYXZlIGNhcGFiaWxp dHkgaXMgaWRlbnRpZmllZCBieSB0aGUgZm9sbG93aW5nIGNhcGFiaWxpdHkKICAgc3RyaW5nOgoK ICAgdXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6Y2FwYWJpbGl0eTppbnRlcmxlYXZlOjEuMAoKNi40 LiAgTmV3IE9wZXJhdGlvbnMKCiAgIE5vbmUuCgo2LjUuICBNb2RpZmljYXRpb25zIHRvIEV4aXN0 aW5nIE9wZXJhdGlvbnMKCiAgIFdoZW4gYSAmbHQ7Y3JlYXRlLXN1YnNjcmlwdGlvbiZndDsgaXMg c2VudCB3aGlsZSBhbm90aGVyIHN1YnNjcmlwdGlvbiBpcwogICBhY3RpdmUgb24gdGhhdCBzZXNz aW9uLCB0aGUgZm9sbG93aW5nIGVycm9yIHdpbGwgYmUgcmV0dXJuZWQ6CgogICAgICBUYWc6IG9w ZXJhdGlvbi1mYWlsZWQKCiAgICAgIEVycm9yLXR5cGU6IHByb3RvY29sCgogICAgICBTZXZlcml0 eTogZXJyb3IKCiAgICAgIEVycm9yLWluZm86IG5vbmUKCiAgICAgIERlc2NyaXB0aW9uOiBSZXF1 ZXN0IGNvdWxkIG5vdCBiZSBjb21wbGV0ZWQgYmVjYXVzZSB0aGUgcmVxdWVzdGVkCiAgICAgIG9w ZXJhdGlvbiBmYWlsZWQgZm9yIHNvbWUgcmVhc29uIG5vdCBjb3ZlcmVkIGJ5IGFueSBvdGhlciBl cnJvcgogICAgICBjb25kaXRpb24uCgo3LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFRo ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmcm9tIHRoZSBiYXNlIFtORVRDT05GXSBkb2N1bWVu dCBhbHNvCiAgIGFwcGx5IHRvIHRoZSBOb3RpZmljYXRpb24gY2FwYWJpbGl0eS4KCiAgIFRoZSBh Y2Nlc3MgY29udHJvbCBmcmFtZXdvcmsgYW5kIHRoZSBjaG9pY2Ugb2YgdHJhbnNwb3J0IHdpbGwg aGF2ZSBhCiAgIG1ham9yIGltcGFjdCBvbiB0aGUgc2VjdXJpdHkgb2YgdGhlIHNvbHV0aW9uLgoK ICAgVGhlICZsdDtub3RpZmljYXRpb24mZ3Q7IGVsZW1lbnRzIGFyZSBuZXZlciBzZW50IGJlZm9y ZSB0aGUgdHJhbnNwb3J0IGxheWVyCiAgIGFuZCB0aGUgTkVUQ09ORiBsYXllciwgaW5jbHVkaW5n IGNhcGFiaWxpdGllcyBleGNoYW5nZSwgaGF2ZSBiZWVuCiAgIGVzdGFibGlzaGVkLCBhbmQgdGhl IG1hbmFnZXIgaGFzIGJlZW4gaWRlbnRpZmllZCBhbmQgYXV0aGVudGljYXRlZC4KCiAgIEl0IGlz IHJlY29tbWVuZGVkIHRoYXQgY2FyZSBiZSB0YWtlbiB0byBzZWN1cmUgZXhlY3V0aW9uOgoKICAg byAgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7IGludm9jYXRpb24KCiAgIG8gICZsdDtnZXQm Z3Q7IG9uIHJlYWQtb25seSBkYXRhIG1vZGVscwoKICAgbyAgJmx0O25vdGlmaWNhdGlvbiZndDsg Y29udGVudAoKICAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPlNlY3VyZSBleGVjdXRpb24g bWVhbnMgZW5zdXJpbmcgdGhhdCBhIHNlY3VyZSB0cmFuc3BvcnQgaXMgdXNlZCBhcwogICB3ZWxs IGFzIGVuc3VyaW5nIHRoYXQgdGhlIHVzZXIgaGFzIHN1ZmZpY2llbnQgYXV0aG9yaXphdGlvbiB0 bwogICBwZXJmb3JtIHRoZSBmdW5jdGlvbiB0aGV5IGFyZSByZXF1ZXN0aW5nIGFnYWluc3QgdGhl IHNwZWNpZmljIHBpZWNlCiAgIG9mIE5FVENPTkYgY29udGVudCBpbnZvbHZlZC4gIFdoZW4gYSAm bHQ7Z2V0Jmd0OyBpcyByZWNlaXZlZCBhZ2FpbnN0IHRoZQogICBjb250ZW50IGRlZmluZWQgaW4g dGhpcyBtZW1vLCBjbGllbnRzIHNob3VsZCBvbmx5IGJlIGFibGUgdG8gdmlldyB0aGUKICAgY29u dGVudCBmb3Igd2hpY2ggdGhleSBoYXZlIHN1ZmZpY2llbnQgcHJpdmlsZWdlcy4gIEEgY3JlYXRl ICZsdDtjcmVhdGUtCiAgIHN1YnNjcmlwdGlvbiZndDsgb3BlcmF0aW9uIGNhbiBiZSBjb25zaWRl cmVkIGxpa2UgYSBkZWZlcnJlZCAmbHQ7Z2V0Jmd0OywgYW5kCiAgIHRoZSBjb250ZW50IHRoYXQg ZGlmZmVyZW50IHVzZXJzIGNhbiBhY2Nlc3MgbWF5IHZhcnkuICBUaGlzIGRpZmZlcmVudAogICBh Y2Nlc3MgaXMgcmVmbGVjdGVkIGluIHRoZSAmbHQ7bm90aWZpY2F0aW9uJmd0OyB0aGF0IGRpZmZl cmVudCB1c2VycyBhcmUKICAgYWJsZSB0byBzdWJzY3JpYmUgdG8uPC9mb250Pjwvc3Ryb25nPgoK ICAgT25lIHBvdGVudGlhbCBzZWN1cml0eSBpc3N1ZSBpcyB0aGUgdHJhbnNwb3J0IG9mIGRhdGEg ZnJvbSBub24tCiAgIE5FVENPTkYgc3RyZWFtcywgc3VjaCBhcyBzeXNsb2cgYW5kIFNOTVAuICBU aGlzIGRhdGEgbWF5IGJlIG1vcmUKICAgdnVsbmVyYWJsZSAob3IgbGVzcyB2dWxuZXJhYmxlKSB3 aGVuIGJlaW5nIHRyYW5zcG9ydGVkIG92ZXIgTkVUQ09ORgogICB0aGFuIHdoZW4gYmVpbmcgdHJh bnNwb3J0ZWQgdXNpbmcgdGhlIHByb3RvY29sIG5vcm1hbGx5IHVzZWQgZm9yCiAgIHRyYW5zcG9y dGluZyBpdCwgZGVwZW5kaW5nIG9uIHRoZSBzZWN1cml0eSBjcmVkZW50aWFscyBvZiB0aGUgdHdv CiAgIHN1YnN5c3RlbXMuICBUaGUgTkVUQ09ORiBzZXJ2ZXIgaXMgcmVzcG9uc2libGUgZm9yIGFw cGx5aW5nIGFjY2VzcwogICBjb250cm9sIHRvIHN0cmVhbSBjb250ZW50LgoKICAgVGhlIGNvbnRl bnRzIG9mIG5vdGlmaWNhdGlvbnMgYXMgd2VsbCBhcyB0aGUgbmFtZSBvZiBldmVudCBzdHJlYW1z CiAgIG1heSBjb250YWluIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBhbmQgY2FyZSBzaG91bGQgYmUg dGFrZW4gdG8gZW5zdXJlCiAgIHRoYXQgaXQgaXMgdmlld2VkIG9ubHkgYnkgYXV0aG9yaXplZCB1 c2Vycy4gIElmIGEgdXNlciBkb2VzIG5vdCBoYXZlCiAgIHBlcm1pc3Npb24gdG8gdmlldyBjb250 ZW50IHZpYSBvdGhlciBORVRDT05GIG9wZXJhdGlvbnMsIDxzdHJpa2U+PGZvbnQgY29sb3I9J3Jl ZCc+aXQ8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5zaGU8L2Zv bnQ+PC9zdHJvbmc+IG11c3Qgbm90CiAgIGhhdmUgYWNjZXNzIDxzdHJvbmc+PGZvbnQgY29sb3I9 J2dyZWVuJz50bzwvZm9udD48L3N0cm9uZz4gdGhhdCBjb250ZW50IHZpYSBOb3RpZmljYXRpb25z LiAgSWYgYSB1c2VyIGlzIG5vdAogICBwZXJtaXR0ZWQgdG8gdmlldyBvbmUgZWxlbWVudCBpbiB0 aGUgY29udGVudCBvZiB0aGUgbm90aWZpY2F0aW9uLCB0aGUKICAgbm90aWZpY2F0aW9uIGlzIG5v dCBzZW50IHRvIHRoYXQgdXNlci4KCiAgIElmIGEgc3Vic2NyaXB0aW9uIGlzIGNyZWF0ZWQgd2l0 aCBhICZsdDtzdG9wVGltZSZndDssIHRoZSBORVRDT05GIHNlc3Npb24KICAgd2lsbCByZXR1cm4g dG8gYmVpbmcgYSBub3JtYWwgY29tbWFuZC1yZXNwb25zZSBORVRDT05GIHNlc3Npb24gd2hlbgog ICB0aGUgcmVwbGF5IGlzIGNvbXBsZXRlZC4gIEl0IGlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiB0 aGUgTkVUQ09ORgogICBjbGllbnQgdG8gY2xvc2UgdGhpcyBzZXNzaW9uIHdoZW4gaXQgaXMgbm8g bG9uZ2VyIG9mIHVzZS4KCjguICBJQU5BIENvbnNpZGVyYXRpb25zCgogICAtLSBFZGl0b3Igbm90 ZSB0byBJQU5BL1JGQy1FZGl0b3I6IHdlIHJlcXVlc3QgdGhhdCB5b3UgbWFrZSB0aGVzZQogICBh c3NpZ25tZW50cywgaW4gd2hpY2ggY2FzZSBpdCBpcyB0byBiZSBkb2N1bWVudGVkIGFzIGJlbG93 CgogICBUaGlzIGRvY3VtZW50IHJlZ2lzdGVycyB0aHJlZSBVUklzIGZvciB0aGUgTkVUQ09ORiBY TUwgbmFtZXNwYWNlIGluCiAgIHRoZSBJRVRGIFhNTCByZWdpc3RyeSBbUkZDMzY4OF0uCgogICBG b2xsb3dpbmcgdGhlIGZvcm1hdCBpbiBSRkMgMzY4OCwgSUFOQSBoYXMgbWFkZSB0aGUgZm9sbG93 aW5nCiAgIHJlZ2lzdHJhdGlvbi4gIE5vdGUgdGhhdCB0aGUgY2FwYWJpbGl0eSB1cm5zIGFzIGFs c28gY29tcGxpYW50IHRvCiAgIFtORVRDT05GXSBzZWN0aW9uIDEwLjMuCgogICArLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsKICAgfCBJbmRleCAgICAgICAgICAgICAgfCBDYXBhYmlsaXR5IElkZW50aWZpZXIgICAgICAg ICAgICAgICAgICAgICAgICB8CiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICB8IDpub3RpZmljYXRpb24gICAg ICB8IHVybjppZXRmOnBhcmFtczpuZXRjb25mOmNhcGFiaWxpdHk6ICAgICAgICAgIHwKICAgfCAg ICAgICAgICAgICAgICAgICAgfCBub3RpZmljYXRpb246MS4wICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IDppbnRlcmxlYXZlICAgICAgICB8IHVybjpp ZXRmOnBhcmFtczpuZXRjb25mOmNhcGFiaWxpdHk6ICAgICAgICAgIHwKICAgfCAgICAgICAgICAg ICAgICAgICAgfCBpbnRlcmxlYXZlOjEuMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 CiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKwoKICAgVVJJOiB1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldG1vZDpu b3RpZmljYXRpb24KCiAgIFVSSTogdXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOm5vdGlm aWNhdGlvbjoxLjAKCiAgIFJlZ2lzdHJhbnQgQ29udGFjdDogVGhlIElFU0cuCgogICBYTUw6IE4v QSwgdGhlIHJlcXVlc3RlZCBVUkkgaXMgYW4gWE1MIG5hbWVzcGFjZS4KCiAgIEluIGFkZGl0aW9u LCBJQU5BIHJlZ2lzdGVyZWQgdGhlIGZvbGxvd2luZyBYTUwgU2NoZW1hLCB0aGUgZGVmaW5pdGlv bgogICBvZiB3aGljaCBjYW4gYmUgZm91bmQgaW4gU2VjdGlvbiA0OgogICBodHRwOi8vd3d3Lmlh bmEub3JnL2Fzc2lnbm1lbnRzL3htbC1yZWdpc3RyeS9zY2hlbWEvbm90aWZpY2F0aW9uLnhzZAoK OS4gIEFja25vd2xlZGdlbWVudHMKCiAgIFRoYW5rcyB0byBHaWxiZXJ0IEdhZ25vbiwgR3JlZyBX aWxidXIgYW5kIEtpbSBDdXJyYW4gZm9yIHByb3ZpZGluZwogICB0aGVpciBpbnB1dCBpbnRvIHRo ZSBlYXJseSB3b3JrIG9uIHRoaXMgZG9jdW1lbnQuICBJbiBhZGRpdGlvbiwgdGhlCiAgIGVkaXRv cnMgd291bGQgbGlrZSB0byBhY2tub3dsZWRnZSBpbnB1dCBhdCB0aGUgVmFuY291dmVyIGVkaXRp bmcKICAgc2Vzc2lvbiBmcm9tIHRoZSBmb2xsb3dpbmcgcGVvcGxlOiBPcmx5IE5pY2tsYXNzLCBK YW1lcyBCYWxlc3RyaWVyZSwKICAgWW9zaGlmdW1pIEF0YXJhc2hpLCBHbGVubiBXYXRlcnMsIEFs ZXhhbmRlciBDbGVtbSwgRGF2ZSBIYXJyaW5ndG9uLAogICBEYXZlIFBhcnRhaW4sIFJheSBBdGFy YXNoaSBhbmQgRGF2aWQgUGVya2lucyBhbmQgdGhlIGZvbGxvd2luZwogICBhZGRpdGlvbmFsIHBl b3BsZSBmcm9tIHRoZSBNb250cmVhbCBlZGl0aW5nIHNlc3Npb246IEJhbGF6cyBMZW5neWVsLAog ICBQaGlsIFNoYWZlciwgUm9iIEVubnMsIEFuZHkgQmllcm1hbiwgRGFuIFJvbWFzY2FudSwgQmVy dCBXaWpuZW4sCiAgIFNpbW9uIExlaW5lbiwgSnVlcmdlbiBTY2hvZW53YWVsZGVyLCBIaWRla2kg T2tpdGEsIFZpbmNlbnQgQ3JpZGxpZywKICAgTWFydGluIEJqb3JrbHVuZCwgT2xpdmllciBGZXN0 b3IsIFJhZHUgU3RhdGUsIEJyaWFuIFRyYW1tZWxsLCBXaWxsaWFtCiAgIENob3cuICBXZSB3b3Vs ZCBhbHNvIGxpa2UgdG8gdGhhbmsgTGkgWWFuIGZvciBoaXMgbnVtZXJvdXMgcmV2aWV3cyBhcwog ICB3ZWxsIGFzIFN1cmVzaCBLcmlzaG5hbiBmb3IgaGlzIGdlbi1hcnQgcmV2aWV3IG9mIHRoZSBk b2N1bWVudC4KCjEwLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIDxzdHJvbmc+PGZvbnQgY29s b3I9J2dyZWVuJz5bSVNPLjg2MDEuMTk4OF0KICAgICAgICAgICAgICBJbnRlcm5hdGlvbmFsIE9y Z2FuaXphdGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCAiRGF0YQogICAgICAgICAgICAgIGVsZW1l bnRzIGFuZCBpbnRlcmNoYW5nZSBmb3JtYXRzIC0gSW5mb3JtYXRpb24gaW50ZXJjaGFuZ2UKICAg ICAgICAgICAgICAtIFJlcHJlc2VudGF0aW9uIG9mIGRhdGVzIGFuZCB0aW1lcyIsIElTTyBTdGFu ZGFyZCA4NjAxLAogICAgICAgICAgICAgIEp1bmUgMTk4OC48L2ZvbnQ+PC9zdHJvbmc+CgogICBb TkVUQ09ORl0gIEVubnMsIFIuLCAiTkVUQ09ORiBDb25maWd1cmF0aW9uIFByb3RvY29sIiwgUkZD IDQ3NDEsCiAgICAgICAgICAgICAgRGVjZW1iZXIgMjAwNi4KCiAgIFtSRkMyMTE5XSAgQnJhZG5l ciwgcy4sICJLZXkgd29yZHMgZm9yIFJGQ3MgdG8gSW5kaWNhdGUgUmVxdWlyZW1lbnRzCiAgICAg ICAgICAgICAgTGV2ZWxzIiwgUkZDIDIxMTksIE1hcmNoIDE5OTcuCgogICA8c3Ryb25nPjxmb250 IGNvbG9yPSdncmVlbic+W1JGQzMzMzldICBLbHluZSwgRy4sIEVkLiBhbmQgQy4gTmV3bWFuLCAi RGF0ZSBhbmQgVGltZSBvbiB0aGUKICAgICAgICAgICAgICBJbnRlcm5ldDogVGltZXN0YW1wcyIs IFJGQyAzMzM5LCBKdWx5IDIwMDIuPC9mb250Pjwvc3Ryb25nPgoKICAgW1JGQzM2ODhdICBCcmFk bmVyLCBzLiwgIlRoZSBJRVRGIFhNTCBSZWdpc3RyeSIsIFJGQyAzNjg4LCBKYW51YXJ5CiAgICAg ICAgICAgICAgIDIwMDQuCgogICBbWE1MXSAgICAgIFdvcmxkIFdpZGUgV2ViIENvbnNvcnRpdW0s ICJFeHRlbnNpYmxlIE1hcmt1cCBMYW5ndWFnZQogICAgICAgICAgICAgIChYTUwpIDEuMCIsIFcz QyBYTUwsIEZlYnJ1YXJ5IDE5OTgsCiAgICAgICAgICAgICAgJmx0O2h0dHA6Ly93d3cudzMub3Jn L1RSLzE5OTgvUkVDLXhtbC0xOTk4MDIxMCZndDsuCgogICBbWE1MIFNjaGVtYV0KICAgICAgICAg ICAgICBUaG9tcHNvbiwgSC4sIEJlZWNoLCBELiwgTWFsb25leSwgTS4sIGFuZCBOLiBNZW5kZWxz b2huLAogICAgICAgICAgICAgICJYTUwgU2NoZW1hIFBhcnQgMTogU3RydWN0dXJlcyBTZWNvbmQg RWRpdGlvbiIsIFczQyBodHRwOi8KICAgICAgICAgICAgICAvd3d3LnczLm9yZy9UUi8yMDA0L1JF Qy14bWxzY2hlbWEtMS0yMDA0MTAyOC8KICAgICAgICAgICAgICBzdHJ1Y3R1cmVzLmh0bWwsIE9j dG9iZXIgMjAwNC4KCiAgIFtYUEFUSF0gICAgQ2xhcmssIEouIGFuZCBTLiBEZVJvc2UsICJYTUwg UGF0aCBMYW5ndWFnZSAoWFBhdGgpCiAgICAgICAgICAgICAgVmVyc2lvbiAxLjAiLAogICAgICAg ICAgICAgIFczQyBodHRwOi8vd3d3LnczLm9yZy9UUi8xOTk5L1JFQy14cGF0aC0xOTk5MTExNiwK ICAgICAgICAgICAgICBOb3ZlbWJlciAxOTk5LgoKQXBwZW5kaXggQS4gIENoYW5nZSBMb2cKCiAg IC0tIEVkaXRvciBub3RlIHRvIFJGQy1FZGl0b3I6IHdlIHJlcXVlc3QgdGhhdCB5b3UgcmVtb3Zl IHRoaXMgc2VjdGlvbgogICBiZWZvcmUgcHVibGlzaGluZy4KCkEuMS4gIFZlcnNpb24gLTA4Cgog ICAxLiAgIFJlbW92ZWQgbmFtZWQgcHJvZmlsZXMKCiAgIDIuICAgUmVtb3ZlZCBldmVudENsYXNz IHRoYXQgd2FzIGFjY2lkZW50YWxseSBpbmNsdWRlZCBpbiB0aGUKICAgICAgICBkZWZpbml0aW9u IG9mIHRoZSByZXBsYXlDb21wbGV0ZSBub3RpZmljYXRpb24KCiAgIDMuICAgRGVsZXRlZCBkYXRh IHdyYXBwZXIgZnJvbSBub3RpZmljYXRpb24KCiAgIDQuICAgQ2hhbmdlZCByZXBsYXlMb2dTdGFy dFRpbWUgdG8gaGF2ZSBhIG1pbk9jY3VycyBvZiAwLiAgSXQgd2lsbAogICAgICAgIG9ubHkgYmUg dGhlcmUgd2hlbiByZXBsYXkgaXMgc3VwcG9ydGVkLiAgVmVyaWZ5IGV4YW1wbGVzIGluCiAgICAg ICAgc2VjdGlvbiAzLjIuNS4xIGFyZSBjb3JyZWN0IHdpdGggcmVzcGVjdCB0byB0aGlzIGVsZW1l bnQuCgogICA1LiAgIEVycm9yIGNvZGVzIGluIHNlY3Rpb24gMi4xLjEsIGZpeGVkIGZvcm1hdHRp bmcgaXNzdWUKCiAgIDYuICAgTW92ZWQgcmVwbGF5Q29tcGxldGUgdG8gbm90IGJlIHVuZGVyICZs dDtuZXRjb25mJmd0OwoKICAgNy4gICBTZWN0aW9uIDIuMSwgZml4ZWQgY2FwaXRhbGl6YXRpb24K CiAgIDguICAgSW4gZmlndXJlIDQsIHRoZSBsaW5lIHdhcyBwdXNoZWQgb3V0IGJ5ICdzeXN0ZW0g Y29tcG9uZW50cycsCiAgICAgICAgZml4ZWQgdGhpcy4KCiAgIDkuICAgT24gcGFnZSA4LCByZXBs YWNlZCAiSWYgdGhlIHN0YXJ0VGltZSBzcGVjaWZpZWQgaXMgZWFybGllciB0aGVuCiAgICAgICAg dGhlIiB3aXRoICdJZiB0aGUgc3RhcnRUaW1lIHNwZWNpZmllZCBpcyBlYXJsaWVyIHRoYW4gdGhl IgoKICAgMTAuICBVcGRhdGVkIHNvbWUgbmFtZSBzcGFjZXMgYW5kIHNjaGVtYUxvY2F0aW9ucyBh cyBwZXIgQW5keSdzIEp1bmUKICAgICAgICAzcmQgZW1haWwuCgogICAxMS4gIEFkZGVkIGRpc2N1 c3Npb24gb2YgcmVwbGF5TG9nU3RhcnRUaW1lIHRvIGRyYWZ0IGluIHNlY3Rpb24gMy4zLjEKICAg ICAgICBhcyBmb2xsb3dzICJXaGV0aGVyIG9yIG5vdCBhIHN0cmVhbSBzdXBwb3J0cyByZXBsYXkg Y2FuIGJlCiAgICAgICAgZGlzY292ZXJlZCBieSBkb2luZyBhICZsdDtnZXQmZ3Q7IG9wZXJhdGlv biBvbiB0aGUgJmx0O3N0cmVhbXMmZ3Q7IGVsZW1lbnRzCiAgICAgICAgb2YgdGhlIE5vdGlmaWNh dGlvbiBNYW5hZ2VtZW50IFNjaGVtYS4gIFRoaXMgc2NoZW1hIGFsc28KICAgICAgICBwcm92aWRl cyB0aGUgcmVwbGF5TG9nU3RhcnRUaW1lIGVsZW1lbnQgdG8gaW5kaWNhdGUgdGhlIGVhcmxpZXN0 CiAgICAgICAgYXZhaWxhYmxlIGxvZ2dlZCBub3RpZmljYXRpb24uIgoKICAgMTIuICBSZW1vdmVk IG1vc3Qgb2YgdGhlIHVzZXMgb2YgdGhlIHBocmFzZSAnTm90ZSB0aGF0Jy4gIEkga2VwdCB0d28K ICAgICAgICB1c2VzIHRoYXQgcHJldmVudCBzZW50ZW5jZXMgZnJvbSBzdGFydGluZyB3aXRoIGVp dGhlciBhIGxvd2VyCiAgICAgICAgY2FzZSBsZXR0ZXIgb3IgYW4gYW5nbGUgYnJhY2tldC4KCiAg IDEzLiAgSW4gc2VjdGlvbiAzLjYgcmVwbGFjZWQgIml0IHdpbGwgYmUgZmlsdGVyZWQgb3V0IiB3 aXRoICJ0aGUKICAgICAgICBub3RpZmljYXRpb24gd2lsbCBiZSBmaWx0ZXJlZCBvdXQiCiAgIDE0 LiAgSW4gc2VjdGlvbiAzLjQsIHJlcGxhY2VkICJhbmQgdGhlIHF1ZXJ5IiB3aXRoICJhbmQgdG8g cXVlcnkiCgogICAxNS4gIFJlcGxhY2VkIDMgaW5zdGFuY2VzIG9mICJyZXBsYXkgY29tcGxldGUg bm90aWZpY2F0aW9uIiB3aXRoCiAgICAgICAgInJlcGxheUNvbXBsZXRlIG5vdGlmaWNhdGlvbiIK CiAgIDE2LiAgSW4gc2VjdGlvbiAzLjMuMiwgcmVwbGFjZWQgIm5vcm1hbCBORVRDT05GIHNlc3Np b24iIHdpdGggIm5vcm1hbAogICAgICAgIGNvbW1hbmQtcmVzcG9uc2UgTkVUQ09ORiBzZXNzaW9u IgoKICAgMTcuICBJbiBzZWN0aW9uIDMuMy4xLCByZXBsYWNlZCAiY3JlYXRlIGFuIGV2ZW50IHN1 YnNjcmlwdGlvbiB0aGF0CiAgICAgICAgd2lsbCByZXNlbmQgcmVjZW50bHkgZ2VuZXJhdGVkIG5v dGlmaWNhdGlvbiIgd2l0aCAiY3JlYXRlIGFuCiAgICAgICAgZXZlbnQgc3Vic2NyaXB0aW9uIHRo YXQgd2lsbCByZXNlbmQgcmVjZW50bHkgZ2VuZXJhdGVkCiAgICAgICAgbm90aWZpY2F0aW9uLCBv ciBpcyBzb21lIGNhc2VzIHNlbmQgdGhlbSBmb3IgdGhlIGZpcnN0IHRpbWUgdG8gYQogICAgICAg IHBhcnRpY3VsYXIgTkVUQ09ORiBjbGllbnQuIgoKICAgMTguICBJbiBzZWN0aW9uIDMuMi41LjIs IHMvYXZhaWxhYmxlIGV2ZW50IHN0cmVhbXMgdG8vZXZlbnQgc3RyZWFtcwogICAgICAgIGF2YWls YWJsZSB0by8KCiAgIDE5LiAgSW4gb25lIHNwb3QsIGNoYW5nZWQgc25tcCB0byBTTk1QICh0aGUg b3RoZXIgZ2V0cyBkZWxldGVkKQoKICAgMjAuICBJbiBzZWN0aW9uIDMuMi41LjEgcy93aGVyZSAm bHQ7bmFtZSZndDsgZWxlbWVudCBpcy93aGVyZSB0aGUgJmx0O25hbWUmZ3Q7CiAgICAgICAgZWxl bWVudCBpcy8KCiAgIDIxLiAgSW4gc2VjdGlvbiAzLjIuNS4xLCBjbGFyaWZpZWQgdGhhdCAidmFs dWUgaXMgdW5pcXVlIiAtIHdpdGhpbgogICAgICAgIHRoZSBzY29wZSBvZiBhIE5FVENPTkYgc2Vy dmVyLgoKICAgMjIuICBJbiBzZWN0aW9uIDIuMS4xLCBjbGFyaWZpZWQgdGhhdCBzdG9wVGltZSBj YW5ub3QgcHJlY2VkZWQgc3RhcnQKICAgICAgICB0aW1lLgoKICAgMjMuICBJbiBzZWN0aW9uIDIu MS4xLCBpbiBTdGFydCBUaW1lIHMvaW5kaWNhdGVzL2luZGljYXRlLwoKICAgMjQuICBJbiBzZWN0 aW9uIDIuMS4xLCBpbiBGaWx0ZXI6IHMvVGhpcyBpcyBtdXR1YWxseSBleGNsdXNpdmUvVGhlCiAg ICAgICAgZmlsdGVyIHBhcmFtZXRlciBpcyBtdXR1YWxseSBleGNsdXNpdmUvICgidGhpcyIgY291 bGQgcmVmZXIgdG8KICAgICAgICB0aGUgYmVoYXZpb3VyIGRlc2NyaWJlZCBpbiB0aGUgcHJldmlv dXMgc2VudGVuY2UuKQoKICAgMjUuICBJbiBzZWN0aW9uIDEuNCwgdGhpcmQgYnVsbGV0LCByZXBs YWNlZCAic3lzbG9nIGFuZCBTTk1QIGFyZQogICAgICAgIHJhdGhlciBjb25zdHJhaW5lZCBpbiB0 ZXJtcyBvZiBtZXNzYWdlIHNpemVzKSIgd2l0aCAoaWUsIG5vdCB0b28KICAgICAgICBzaG9ydCkK CiAgIDI2LiAgSW4gc2VjdGlvbiAxLjQsIG1hZGUgYWxsIGJ1bGxldHMgc3RhcnQgd2l0aCBjYXBp dGFsIGxldHRlcnMuCgogICAyNy4gIEFkZGVkIGRlZmluaXRpb24gb2YgRmlsdGVyIHRvIHNlY3Rp b24gMS4xCgogICAyOC4gIEluIHNlY3Rpb24gMS4xLCBpbXByb3ZlZCB0aGUgZGVmaW5pdGlvbiBv ZiBzdWJzY3JpcHRpb24gd2l0aCAiQW4KICAgICAgICBhZ3JlZW1lbnQgYW5kIG1ldGhvZCB0byBy ZWNlaXZlIGV2ZW50IG5vdGlmaWNhdGlvbnMgb3ZlciBhCiAgICAgICAgTkVUQ09ORiBzZXNzaW9u LiIKCiAgIDI5LiAgSW4gc2VjdGlvbiAxLjEsIGluIHRoZSBkZWZpbml0aW9uIG9mIG9wZXJhdGlv biwgYWRkZWQgYQogICAgICAgIHJlZmVyZW5jZSB0byBbTkVUQ09ORl0uCgogICAzMC4gIENyZWF0 ZWQgYSBjaGFuZ2UgbG9nIHNlY3Rpb24KCiAgIDMxLiAgRml4ZWQgcmVmZXJlbmNlIHRvIElFVEYg WE1MIFJlZ2lzdHJ5IGluIElBTkEgQ29uc2lkZXJhdGlvbnMKICAgICAgICBzZWN0aW9uLgoKICAg MzIuICBJbiBzZWN0aW9uIDMuMy4zLCBkZWxldGVkICJUaGlzIG5vdGlmaWNhdGlvbiB3aWxsIG9u bHkgYmUgc2VudAogICAgICAgIGlmIGEgJ3N0b3BUaW1lJyB3YXMgc3BlY2lmaWVkIHdoZW4gdGhl IHJlcGxheSBzdWJzY3JpcHRpb24gd2FzCiAgICAgICAgY3JlYXRlZC4iCgogICAzMy4gIEFkZGVk IHRleHQgdG8gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gdGhhdCBzYXlzICJJ ZgogICAgICAgIGEgc3Vic2NyaXB0aW9uIGlzIGNyZWF0ZWQgd2l0aCBhIHN0b3BUaW1lLCB0aGUg TkVUQ09ORiBzZXNzaW9uCiAgICAgICAgd2lsbCByZXR1cm4gdG8gYmVpbmcgYSBub3JtYWwgY29t bWFuZC1yZXNwb25zZSBORVRDT05GIHNlc3Npb24KICAgICAgICB3aGVuIHRoZSByZXBsYXkgaXMg Y29tcGxldGVkLiAgSXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZQogICAgICAgIE5FVENP TkYgY2xpZW50IHRvIGNsb3NlIG9mZiB0aGlzIHNlc3Npb24gd2hlbiBpdCBpcyBubyBsb25nZXIg b2YKICAgICAgICB1c2UiLgoKICAgMzQuICBVcGRhdGUgZXhhbXBsZXMgaW4gc2VjdGlvbiA1IHRv IGdldCByaWQgb2YgZXh0cmEgd3JhcHBlciB0YWcuCgogICAzNS4gIEluIHNlY3Rpb24gMi4xLCBy ZXBsYWNlICJBIE5FVENPTkYgc2VydmVyIGlzIG5vdCByZXF1aXJlZCB0bwogICAgICAgIHByb2Nl c3MgUlBDIHJlcXVlc3RzIG9uIHRoZSBzZXNzaW9uIGFzc29jaWF0ZWQgd2l0aCB0aGUKICAgICAg ICBzdWJzY3JpcHRpb24gdW50aWwgdGhlIG5vdGlmaWNhdGlvbiBzdWJzY3JpcHRpb24gaXMgZG9u ZSBhbmQgbWF5CiAgICAgICAgc2lsZW50bHkgZGlzY2FyZCB0aGVzZSByZXF1ZXN0cy4iIHdpdGgg IkEgTkVUQ09ORiBzZXJ2ZXIgaXMgd2lsbAogICAgICAgIG5vdCByZWFkIFJQQyByZXF1ZXN0cywg YnkgZGVmYXVsdCwgb24gdGhlIHNlc3Npb24gYXNzb2NpYXRlZAogICAgICAgIHdpdGggdGhlIHN1 YnNjcmlwdGlvbiB1bnRpbCB0aGUgbm90aWZpY2F0aW9uIHN1YnNjcmlwdGlvbiBpcwogICAgICAg IGRvbmUuCgogICAzNi4gIFVwZGF0ZWQgdGhlIG5vdGlmaWNhdGlvbiBkZWZpbml0aW9uIGFuZCB0 aGUgcmVwbHlDb21wbGV0ZQogICAgICAgIG5vdGlmaWNhdGlvbiBkZWZpbml0aW9uIHRvIHVzZSBh IHN1YnN0aXR1dGlvbiBncm91cC4KCkEuMi4gIFZlcnNpb24gLTA5CgogICAxLiAgIEluIHNlY3Rp b24gNS4xICJsb2dpY2FsIE9SIG9wZXJhdGlvbiIgLSZndDsgImFwcGxpY2F0aW9uIG9mIHRoZQog ICAgICAgIGxvZ2ljYWwgT1Igb3BlcmF0b3IiCgogICAyLiAgIEluIHNlY3Rpb24gNiAiZW5zdXJl IHRoZSBzZWN1cmUgb3BlcmF0aW9uIG9mIHRoZSBmb2xsb3dpbmcKICAgICAgICBjb21tYW5kcyIg LSZndDsgInNlY3VyZSBleGVjdXRpb24iCgogICAzLiAgIFJlbW92ZWQgYSBjb3VwbGUgcmVtYWlu aW5nIHJlZmVyZW5jZXMgdG8gbmFtZWQgcHJvZmlsZXMuCgogICA0LiAgIFVwZGF0ZWQgbmFtZSBk YXRhdHlwZSBpbiBldmVudFN0cmVhbXMgZWxlbWVudC4KCiAgIDUuICAgTW9kaWZpZWQgdGhlIGNh cmRpbmFsaXR5IG9mIGV2ZW50U3RyZWFtcyB0byByZWZsZWN0IHRoYXQgdGhlcmUKICAgICAgICB3 aWxsIGFsd2F5cyBiZSBhdCBsZWFzdCBvbmUgZXZlbnQgc3RyZWFtLgoKICAgNi4gICBGaXhlZCBk ZXNjcmlwdGlvbiBvZiBleGFtcGxlcyB0byByZW1vdmUgcmVmZXJlbmNlIHRvIGV2ZW50RW50cnks CiAgICAgICAgd2hpY2ggaXMgbm8gbG9uZ2VyIHBhcnQgb2YgdGhlIGFjdHVhbCBleGFtcGxlLgoK ICAgNy4gICBJbiBleGFtcGxlcywgZm9yIGNvbnNpc3RlbmN5IGNoYW5nZWQgc29tZSByZWZlcmVu Y2VzIHRvCiAgICAgICAgcmVwb3J0aW5nRWxlbWVudCB0byBiZSByZXBvcnRpbmdFbnRpdHkKCiAg IDguICAgRml4ZWQgc2VjdGlvbiAzLjIsIHRoaXJkIHBhcmFncmFwaCB0byB0YWxrIGFib3V0IGZp bHRlciBlbGVtZW50cwogICAgICAgIGluc3RlYWQgb2YgZmlsdGVycy4KCiAgIDkuICAgTWVyZ2Ug c2VjdGlvbiAzLjMuMiBhbmQgc2VjdGlvbiAzLjMuMy4gIERlbGV0ZSB0aGUgZmlyc3QKICAgICAg ICBwYXJhZ3JhcGggaW4gKG9sZCkgc2VjdGlvbiAzLjMuMyBzaW5jZSBpdCBib3RoIGR1cGxpY2F0 ZXMgYW5kCiAgICAgICAgY29udHJhZGljdHMgdGV4dCBpbiBzZWN0aW9uIDMuMy4yCgogICAxMC4g IEluIHNlY3Rpb24gMy4yLjUuMi4xLCBhZGRlZCBjbGFyaWZpY2F0aW9uIHRvIGZpcnN0IHBhcmFn cmFwaAogICAgICAgIHRoYXQgIkVpdGhlciBzdWJ0cmVlIG9yIFhQQVRIIGZpbHRlcmluZyBjYW4g YmUgdXNlZC4gICIKCiAgIDExLiAgUmVtb3ZlZCBkaXNjdXNzaW9uIG9mIG5vdCBhbGxvd2luZyB0 aGUgcmV0dXJuIG9mIHN0cmVhbSBuYW1lcwogICAgICAgIGZvciB3aGljaCB0aGUgdXNlciBkb2Vz IG5vdCBoYXZlIHBlcm1pc3Npb25zIGZyb20gdGhlIGJvZHkgb2YKICAgICAgICB0aGUgZG9jdW1l bnQgdG8gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24uCgogICAxMi4gIEZpeGVk IHR5cG9zIGFuZCBkaWQgd29yZHNtaXRoaW5nIGluIHZhcmlvdXMgcGFydHMgb2YgdGhlCiAgICAg ICAgZG9jdW1lbnQuCgogICAxMy4gIEluIHNlY3Rpb24gMi4xLCBleHBsaWNpdGx5IHN0YXRlZCB0 aGF0IGEgc3Vic2NyaXB0aW9uIGlzIGJvdW5kCiAgICAgICAgdG8gYSBzaW5nbGUgc3RyZWFtIGZv ciB0aGUgbGlmZXRpbWUgb2YgdGhlIHN1YnNjcmlwdGlvbi4KCiAgIDE0LiAgcmVtb3ZlZCBzaW5n bGUgcXVvdGVzIGFyb3VuZCBzb21lIGluc3RhbmNlcyBvZiBzdG9wVGltZSBhbmQKICAgICAgICBz dGFydFRpbWUgZm9yIGNvbnNpc3RlbmN5LiAgV2hlbiBhcHByb3ByaWF0ZSwgcHV0IGJldHdlZW4g YW5nbGUKICAgICAgICBicmFja2V0cy4KCiAgIDE1LiAgSW4gc2VjdGlvbiAyLjEuMSwgY2hhbmdl ZCAiRXJyb3ItaW5mbzogJmx0O2JhZEVsZW1lbnQmZ3Q7OiBzdGFydFRpbWUiCiAgICAgICAgdG8g dXNlIGJhZC1lbGVtZW50LgoKICAgMTYuICBJbiBzZWN0aW9uIDIuMi4xLCB1bmRlciB0aGUgcGFy YW1ldGVyIHRhZywgcmVwbGFjZWQgIkNvbnRhaW5zCiAgICAgICAgbm90aWZpY2F0aW9uLXNwZWNp ZmljIHRhZ2dlZCBjb250ZW50LiIgd2l0aCAiQ29udGFpbnMKICAgICAgICBub3RpZmljYXRpb24t c3BlY2lmaWMgdGFnZ2VkIGNvbnRlbnQsIGlmIGFueS4gICIKCiAgIDE3LiAgQ2xhcmlmaWVkIHNv bWUgdGV4dCBpbiBzZWN0aW9uIDMuMiwgcGFyYWdyYXBoIDMgYXJvdW5kIHNlbmRpbmcKICAgICAg ICBvZiBmaWx0ZXJzIGZyb20gY2xpZW50IGFuZCB0aGUgZmlsdGVycyBsYXRlciBiZWluZyBhcHBs aWVkIHRvCiAgICAgICAgdGhlIG5vdGlmaWNhdGlvbnMuCgogICAxOC4gIEZpeGVkIHRhcmdldCBu YW1lc3BhY2UgaW4gc2VjdGlvbiA0LgoKICAgMTkuICBBZGRlZCBtaXNzaW5nIGxhbmcgYW5kIHZl cnNpb24gaW5mb3JtYXRpb24gdG8gc2NoZW1hIGluIHNlY3Rpb24KICAgICAgICAzLjQKCiAgIDIw LiAgQ2xhcmlmaWVkIHRoYXQgdGhlIGV4YW1wbGVzIGluIHNlY3Rpb24gNSBhbGwgdXNlZCB0aGUg c2FtZQogICAgICAgIGV4YW1wbGUgZXZlbnQgbGlzdC4KCiAgIDIxLiAgQ2xlYW5lZCB1cCBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLgoKICAgMjIuICBJbiBzZWN0aW9uIDMuNCwgY2xh cmlmaWVkIHRoZSBkZWZpbml0aW9uIG9mIHJlcGxheUxvZ1N0YXJ0IHRpbWUKICAgICAgICB0byBi ZSB0aGUgdGltZXN0YW1wIG9mIHRoZSBlYXJsaWVzdCBhdmFpbGFibGUgbm90aWZpY2F0aW9uIGlu CiAgICAgICAgdGhlIGxvZyB1c2VkIHRvIHN1cHBvcnQgdGhlIHJlcGxheSBmdW5jdGlvbiBpbiB0 aGUgZGVzY3JpcHRpb24KICAgICAgICB0YWcgZm9yIHRoZSBvYmplY3QgZGVmaW5pdGlvbi4KCiAg IDIzLiAgSW4gc2VjdGlvbiAzLjMuMiwgY2xhcmlmaWVkIHRoYXQgdGhlIHRpbWUgYW4gZXZlbnQg d2FzIGdlbmVyYXRlZAogICAgICAgIGJ5IHRoZSBzeXN0ZW0gbWVhbnMgdGltZSBhbiBldmVudCB3 YXMgZ2VuZXJhdGVkIGJ5IHRoZSBldmVudAogICAgICAgIHNvdXJjZS4KCiAgIDI0LiAgSW4gc2Vj dGlvbiAzLjUsIGRlbGV0ZWQgZGlzY3Vzc2lvbiBhYm91dCBwb3NzaWJseSBkZWZpbmluZwogICAg ICAgIHN1YnNjcmlwdGlvbnMgaW4gWE1MIFNjaGVtYS4KCiAgIDI1LiAgSW4gc2VjdGlvbiAzLjYs IGRlbGV0ZWQgZGlzY3Vzc2lvbiBhYm91dCBmaWx0ZXIgZWxlbWVudAogICAgICAgIGV4ZWN1dGlv biBvcmRlciBub3QgbWF0dGVyaW5nLgoKICAgMjYuICBGaXhlZCBleGFtcGxlcyBpbiBzZWN0aW9u IDUgdG8gYWRkICZsdDtuZXRjb25mJmd0OyB0YWcgYW5kIHRvIG1ha2UKICAgICAgICBvdGhlciBj b3JyZWN0aW9ucwoKICAgMjcuICBBZGRlZCBYTUwgU2NoZW1hIGRlZmluaXRpb24gZm9yIGV4YW1w bGVzIGluIHNlY3Rpb24gNSBhbmQgc2hvd2VkCiAgICAgICAgdGhlIGV2ZW50IGxpc3Qgd2l0aCAm bHQ7bm90aWZpY2F0aW9uJmd0OyB3cmFwcGVycy4KCiAgIDI4LiAgQWRkZWQgJmx0O25vdGlmaWNh dGlvbkNvbXBsZXRlJmd0OyBub3RpZmljYXRpb24KCiAgIDI5LiAgUmVtb3ZlZCBzdXBwb3J0IG9m IHN0YXJ0VGltZSBhbmQgc3RvcFRpbWUgaW4gdGhlIGZ1dHVyZS4KCiAgIDMwLiAgUmVwbGFjZWQg cmVwbGF5TG9nU3RhcnRUaW1lIHdpdGggcmVwbGF5TG9nQ3JlYXRpb25UaW1lIGFuZAogICAgICAg IHJlcGxheUxvZ0FnZWRUaW1lLgoKQS4zLiAgVmVyc2lvbiAtMTAKCiAgIDEuICBDaGFuZ2VkIHRo ZSBkZXNjcmlwdGlvbiBvZiBzdG9wVGltZSB0byBhbGxvdyBzdG9wVGltZXMgaW4gdGhlCiAgICAg ICBmdXR1cmUuCgogICAyLiAgQWRkZWQgaW50ZXJsZWF2ZSBjYXBhYmlsaXR5CgogICAzLiAgQ2xh cmlmaWVkIGNyZWF0ZS1zdWJzY3JpcHRpb24gZXJyb3IgbWVzc2FnZXMuCgogICA0LiAgQ29ycmVj dGVkIHRhcmdldE5hbWVzcGFjZSBpbiBOZXRjb25mIE5vdGlmaWNhdGlvbiBYU0QKCiAgIDUuICBG aXhlZCB0eXBvcyBhbmQgbWFkZSBtaW5vciBlZGl0cy4KCkEuNC4gIFZlcnNpb24gLTExCgogICAx LiAgRml4ZWQgbmFtZXNwYWNlcwoKICAgMi4gIEluIHNlY3Rpb24gNi41LCBmaXhlZCBlcnJvciBt ZXNzYWdlIEVycm9yLWluZm8KICAgMy4gIEluIHNlY3Rpb24gNi4xIGNsYXJpZnkgdGhhdCBpZiB0 aGUgaW50ZXJsZWF2ZSBjYXBhYmlsaXR5IGlzCiAgICAgICBzdXBwb3J0ZWQsIHRoZW4gdGhlIHNl cnZlciBtdXN0IHJlc3BvbmQgdG8gcmVxdWVzdHMuCgpBLjUuICA8c3RyaWtlPjxmb250IGNvbG9y PSdyZWQnPlZlc3Jpb248L2ZvbnQ+PC9zdHJpa2U+ICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVl bic+VmVyc2lvbjwvZm9udD48L3N0cm9uZz4gLTEyCgogICAxLiAgQWRkIHRvIHNlY3Rpb24gMS4z IHRoZSBjbGFyaWZpY2F0aW9uICJOb3RlIHRoYXQgYSBzdWJzY3JpcHRpb24KICAgICAgIGNhbm5v dCBiZSBtb2RpZmllZCBvbmNlIGNyZWF0ZWQuIgoKICAgMi4gIEluIHNlY3Rpb24gMi4yLjEsIGlu IHRoZSBkZXNjcmlwdGlvbiBvZiBldmVudFRpbWUsIGFkZGVkIHRoZQogICAgICAgZm9sbG93aW5n IHRleHQ6ICJUaGlzIHBhcmFtZXRlciBpcyBvZiB0eXBlIGRhdGVUaW1lLiIKCiAgIDMuICBGaXhl ZCBzZXZlcmFsIHR5cG9zLgoKICAgNC4gIEFkZGVkIHRoZSBmb2xsb3dpbmcgdGV4dCB0byB0aGUg SUFOQSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uOiAiLS0KICAgICAgIEVkaXRvciBub3RlIHRvIElB TkEvUkZDLUVkaXRvcjogd2UgcmVxdWVzdCB0aGF0IHlvdSBtYWtlIHRoZXNlCiAgICAgICBhc3Np Z25tZW50cywgaW4gd2hpY2ggY2FzZSBpdCBpcyB0b3AgYmUgZG9jdW1lbnRlZCBhcyBiZWxvdyIg IgoKICAgNS4gIFJlcGxhY2VkL1VwZGF0ZWQgWE1MIFNjaGVtYSByZWZlcmVuY2UgdG8gYmUgIiBb WE1MIFNjaGVtYV0KICAgICAgIFRob21wc29uLCBILiwgQmVlY2gsIEQuLCBNYWxvbmV5LCBNLiwg TWVuZGVsc29obiwgTi4sICJYTUwgU2NoZW1hCiAgICAgICBQYXJ0IDE6IFN0cnVjdHVyZXMgU2Vj b25kIEVkaXRpb24iLCBXM0MgUmVjb21tZW5kYXRpb24sIDI4CiAgICAgICBPY3RvYmVyIDIwMDQg Jmx0O2h0dHA6Ly93d3cudzMub3JnL1RSLzIwMDQvUkVDLXhtbHNjaGVtYS0xLTIwMDQxMDI4Lwog ICAgICAgc3RydWN0dXJlcy5odG1sJmd0OyAiCgogICA2LiAgQWRkIGluc3RydWN0aW9ucyB0byBS RkMgZWRpdG9yIHRvIHJlbW92ZSBjaGFuZ2UgbG9nIGJlZm9yZQogICAgICAgcHVibGljYXRpb24K CiAgIDcuICBBZGRlZCBJQU5BIHJlZ2lzdHJhdGlvbiBpdGVtIGZvciBodHRwOi8vd3d3LmlhbmEu b3JnL2Fzc2lnbm1lbnRzLwogICAgICAgeG1sLXJlZ2lzdHJ5L3NjaGVtYS9ub3RpZmljYXRpb24u eHNkCgogICA4LiAgQ2xhcmlmaWVkIGluIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24g dGhhdCB0aGUgY2FwYWJpbGl0eQogICAgICAgVVJJcyB3ZXJlIGNvbXBsYWludCB0byBSRkM0NzQx IHNlY3Rpb24gMTAuMwoKPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPkEuNi4gIFZlcnNpb24g LTEzCgogICAxLiAgIEluIHNlY3Rpb24gMi4xLjEsIGZvciBib3RoIGluc3RhbmNlcyBhbmQgaW4g c2VjdGlvbiAyLjIuMSwKICAgICAgICByZXBsYWNlZCAiVGhpcyBwYXJhbWV0ZXIgaXMgb2YgdHlw ZSBkYXRlVGltZS4iICBXaXRoICJUaGlzCiAgICAgICAgcGFyYW1ldGVyIGlzIG9mIHR5cGUgZGF0 ZVRpbWUgYW5kIGNvbXBsaWFudCB0byBbUkZDMzMzOV0gYW5kCiAgICAgICAgW0lTTy44NjAxLjE5 ODhdLiIKCiAgIDIuICAgSW4gdGhlIG5vcm1hdGl2ZSByZWZlcmVuY2Ugc2VjdGlvbiwgYWRkZWQg dGhlIGZvbGxvd2luZyB0d28KICAgICAgICByZWZlcmVuY2VzIFtJU08uODYwMS4xOTg4XSBJbnRl cm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IKICAgICAgICBTdGFuZGFyZGl6YXRpb24sICJEYXRh IGVsZW1lbnRzIGFuZCBpbnRlcmNoYW5nZSBmb3JtYXRzIC0KICAgICAgICBJbmZvcm1hdGlvbiBp bnRlcmNoYW5nZSAtIFJlcHJlc2VudGF0aW9uIG9mIGRhdGVzIGFuZCB0aW1lcyIsCiAgICAgICAg SVNPIFN0YW5kYXJkIDg2MDEsIEp1bmUgMTk4OC4gIFtSRkMzMzM5XSBLbHluZSwgRy4sIEVkLiBh bmQgQy4KICAgICAgICBOZXdtYW4sICJEYXRlIGFuZCBUaW1lIG9uIHRoZSBJbnRlcm5ldDogVGlt ZXN0YW1wcyIsIFJGQyAzMzM5LAogICAgICAgIEp1bHkgMjAwMi4KCiAgIDMuICAgSW4gc2VjdGlv biAyLjEuMSwgZm9yIGJvdGggaW5zdGFuY2VzIGFuZCBpbiBzZWN0aW9uIDIuMi4xLCBhZGRlZAog ICAgICAgIHRoZSBmb2xsb3dpbmcgYWZ0ZXIgdGhlIHRleHQgaW5kaWNhdGluZyB0aGF0IHRoZSB0 aW1lIGZpZWxkcyBhcmUKICAgICAgICBkYXRlVGltZSAodGhpcyBjb3ZlcnMgZXZlbnRUaW1lLCBz dGFydFRpbWUgYW5kIHN0b3BUaW1lKS4KICAgICAgICAiSW1wbGVtZW50YXRpb25zIG11c3Qgc3Vw cG9ydCB0aW1lIHpvbmVzLiIKCiAgIDQuICAgSW4gU2VjdGlvbiAzLjYuMSAicGFyYW1ldGVyLiAg QSBGaWx0ZXIgb25seSBleGlzdCBhcyBhIHBhcmFtZXRlcgogICAgICAgIHRvIHRoZSBzdWJzY3Jp cHRpb24uIiBzL2V4aXN0L2V4aXN0cy8KCiAgIDUuICAgSW4gU2VjdGlvbiA3OiAidGhhdCBpdCBp cyB2aWV3ZWQgb25seSBieSBhdXRob3JpemVkIHVzZXJzLiAgSWYgYQogICAgICAgIHVzZXIgZG9l cyBub3QgaGF2ZSBwZXJtaXNzaW9uIHRvIHZpZXcgY29udGVudCB2aWEgb3RoZXIgTkVUQ09ORgog ICAgICAgIG9wZXJhdGlvbnMsIGl0IG11c3Qgbm90IGhhdmUgYWNjZXNzIHRoYXQgY29udGVudCB2 aWEKICAgICAgICBOb3RpZmljYXRpb25zLiIgcy9pdC9zaGUvIHMvYWNjZXNzIHRoYXQvYWNjZXNz IHRvIHRoYXQvCgogICA2LiAgIEluIHNlY3Rpb24gMy4zLjIsIHJlcGxhY2VkICJUaGUgTkVUQ09O RiBzZXJ2ZXIgd2lsbCB0aGVuIGFjY2VwdAogICAgICAgICZsdDtycGMmZ3Q7IG9wZXJhdGlvbnMu IiAgV2l0aCAiVGhlIE5FVENPTkYgc2VydmVyIHdpbGwgdGhlbiBhY2NlcHQKICAgICAgICAmbHQ7 cnBjJmd0OyBvcGVyYXRpb25zIGV2ZW4gaWYgdGhlIHNlcnZlciBkaWQgbm90IHByZXZpb3VzbHkg YWNjZXB0CiAgICAgICAgc3VjaCBvcGVyYXRpb25zIGR1ZSB0byBsYWNrIG9mIGludGVybGVhdmUg c3VwcG9ydC4iCgogICA3LiAgIEluIHNlY3Rpb24gMy4zLjIsIHJlcGxhY2VkICJBICZsdDtyZXBs YXlDb21wbGV0ZSZndDsgbm90aWZpY2F0aW9uIGlzCiAgICAgICAgc2VudCB0byBpbmRpY2F0ZSB0 aGF0IGFsbCBvZiB0aGUgcmVwbGF5IG5vdGlmaWNhdGlvbnMgaGF2ZSBiZWVuCiAgICAgICAgc2Vu dC4gIElmIHRoaXMgc3Vic2NyaXB0aW9uIGhhcyBhIHN0b3AgdGltZSwgdGhlbiB0aGlzIHNlc3Np b24KICAgICAgICBiZWNvbWVzIGEgbm9ybWFsIE5FVENPTkYgc2Vzc2lvbiBhZ2Fpbi4gIFdoZW4g YSAmbHQ7c3RvcFRpbWUmZ3Q7IGhhcwogICAgICAgIGJlZW4gc3BlY2lmaWVkLCAmbHQ7bm90aWZp Y2F0aW9uQ29tcGxldGUmZ3Q7IG5vdGlmaWNhdGlvbiBpcyB0aGUgbGFzdAogICAgICAgIG5vdGlm aWNhdGlvbiBzZW50IG9uIHRoZSBzdWJzY3JpcHRpb24gYmVmb3JlIGlgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg fAogICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICZsdDtycGMmZ3Q7ICAgICAgICAgICAg fAogICAgICAgICAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7fAog ICAgICAgICAgICAgICAgICAgICB8Jmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfAogICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICZsdDtycGMtcmVwbHkmZ3Q7ICAgICAgICAgfAogICAg ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAoKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDQKCjQuICBYTUwgU2NoZW1hIGZvciBFdmVu dCBOb3RpZmljYXRpb25zCgogICBUaGUgZm9sbG93aW5nIFtYTUwgU2NoZW1hXSBkZWZpbmVzIE5F VENPTkYgRXZlbnQgTm90aWZpY2F0aW9ucy4KCiZsdDs/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rp bmc9IlVURi04Ij8mZ3Q7CiAgJmx0O3hzOnNjaGVtYSB4bWxuczp4cz0iaHR0cDovL3d3dy53My5v cmcvMjAwMS9YTUxTY2hlbWEiCiAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0 Y29uZjpub3RpZmljYXRpb246MS4wIgogICAgIHhtbG5zOm5ldGNvbmY9InVybjppZXRmOnBhcmFt czp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCIKICAgICB0YXJnZXROYW1lc3BhY2U9CiAgICAgICAg InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRpb246MS4wIgogICAgIGVs ZW1lbnRGb3JtRGVmYXVsdD0icXVhbGlmaWVkIgogICAgIGF0dHJpYnV0ZUZvcm1EZWZhdWx0PSJ1 bnF1YWxpZmllZCIKICAgICAgIHhtbDpsYW5nPSJlbiImZ3Q7CgogICAgJmx0OyEtLSBpbXBvcnQg c3RhbmRhcmQgWE1MIGRlZmluaXRpb25zIC0tJmd0OwoKICAgICAmbHQ7eHM6aW1wb3J0IG5hbWVz cGFjZT0iaHR0cDovL3d3dy53My5vcmcvWE1MLzE5OTgvbmFtZXNwYWNlIgogICAgICAgICAgICAg ICAgc2NoZW1hTG9jYXRpb249Imh0dHA6Ly93d3cudzMub3JnLzIwMDEveG1sLnhzZCImZ3Q7CiAg ICAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24m Z3Q7CiAgICAgICAgICAgVGhpcyBpbXBvcnQgYWNjZXNzZXMgdGhlIHhtbDogYXR0cmlidXRlIGdy b3VwcyBmb3IgdGhlCiAgICAgICAgICAgeG1sOmxhbmcgYXMgZGVjbGFyZWQgb24gdGhlIGVycm9y LW1lc3NhZ2UgZWxlbWVudC4KICAgICAgICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAg ICAgJmx0Oy94czphbm5vdGF0aW9uJmd0OwogICAgICZsdDsveHM6aW1wb3J0Jmd0OwoKICAgICAm bHQ7IS0tIGltcG9ydCBiYXNlIG5ldGNvbmYgZGVmaW5pdGlvbnMgLS0mZ3Q7CiAgICAgJmx0O3hz OmltcG9ydCBuYW1lc3BhY2U9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEu MCIKICAgICAgIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCc+c2NoZW1hTG9jYXRpb249CiAgICAg Imh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMveG1sLXJlZ2lzdHJ5L3NjaGVtYS9uZXRj b25mLnhzZCIvJmd0OzwvZm9udD48L3N0cmlrZT4KICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9 J2dyZWVuJz5zY2hlbWFMb2NhdGlvbj0ibmV0Y29uZi54c2QiLyZndDs8L2ZvbnQ+PC9zdHJvbmc+ CgombHQ7IS0tICoqKioqKioqKioqKioqIFN5bW1ldHJpY2FsIE9wZXJhdGlvbnMgICoqKioqKioq KioqKioqKioqKioqLS0mZ3Q7CgogICAgICZsdDshLS0gJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24m Z3Q7IG9wZXJhdGlvbiAtLSZndDsKCiAgICAmbHQ7eHM6Y29tcGxleFR5cGUgbmFtZT0iY3JlYXRl U3Vic2NyaXB0aW9uVHlwZSImZ3Q7CiAgICAgICAgJmx0O3hzOmNvbXBsZXhDb250ZW50Jmd0Owog ICAgICAgICAgICAmbHQ7eHM6ZXh0ZW5zaW9uIGJhc2U9Im5ldGNvbmY6cnBjT3BlcmF0aW9uVHlw ZSImZ3Q7CiAgICAgICAgICAgICAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICAgICAgICAg ICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic3RyZWFtIgogICAgICAgICAgICAgICAgICAgICAg ICB0eXBlPSJzdHJlYW1OYW1lVHlwZSIgbWluT2NjdXJzPSIwIiZndDsKICAgICAgICAgICAgICAg ICAgICAgICAgJmx0O3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEFuIG9wdGlvbmFsIHBhcmFtZXRlciB0aGF0IGluZGljYXRlcwogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgd2hpY2ggc3RyZWFtIG9mIGV2ZW50cyBpcyBvZiBpbnRlcmVzdC4gSWYKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vdCBwcmVzZW50LCB0aGVuIGV2ZW50cyBpbiB0 aGUgZGVmYXVsdAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTkVUQ09ORiBzdHJlYW0g d2lsbCBiZSBzZW50LgogICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czpkb2N1bWVu dGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7 CiAgICAgICAgICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgICAg ICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJmaWx0ZXIiCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICB0eXBlPSJuZXRjb25mOmZpbHRlcklubGluZVR5cGUiCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICBtaW5PY2N1cnM9IjAiJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAg Jmx0O3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0 O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEFuIG9wdGlvbmFsIHBhcmFtZXRlciB0aGF0IGluZGljYXRlcwogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB3aGljaCBzdWJzZXQgb2YgYWxsIH0IHRlcm1pbmF0ZXMgYW5k CiAgICAgICAgdGhlIE5FVENPTkYgc2Vzc2lvbiByZXR1cm5zIHRvIGJlaW5nIGEgbm9ybWFsIE5F VENPTkYgc2Vzc2lvbi4iCiAgICAgICAgV2l0aCAiQSAmbHQ7cmVwbGF5Q29tcGxldGUmZ3Q7IG5v dGlmaWNhdGlvbiBpcyBzZW50IHRvIGluZGljYXRlIHRoYXQKICAgICAgICBhbGwgb2YgdGhlIHJl cGxheSBub3RpZmljYXRpb25zIGhhdmUgYmVlbiBzZW50LiAgV2hlbiBhCiAgICAgICAgJmx0O3N0 b3BUaW1lJmd0OyBoYXMgYmVlbiBzcGVjaWZpZWQsICZsdDtub3RpZmljYXRpb25Db21wbGV0ZSZn dDsKICAgICAgICBub3RpZmljYXRpb24gaXMgdGhlIGxhc3Qgbm90aWZpY2F0aW9uIHNlbnQgb24g dGhlIHN1YnNjcmlwdGlvbgogICAgICAgIGJlZm9yZSBpdCB0ZXJtaW5hdGVzIGFuZCB0aGUgTkVU Q09ORiBzZXNzaW9uIHJldHVybnMgdG8gYmVpbmcgYQogICAgICAgIG5vcm1hbCBORVRDT05GIHNl c3Npb24uICIKCiAgIDguICAgSW4gc2VjdGlvbiAzLjMuMiwgcmVwbGFjZWQsICJBICZsdDtyZXBs YXlDb21wbGV0ZSZndDsgbm90aWZpY2F0aW9uIGlzCiAgICAgICAgc2VudCB0byBpbmRpY2F0ZSB0 aGF0IGFsbCBvZiB0aGUgcmVwbGF5IG5vdGlmaWNhdGlvbnMgaGF2ZSBiZWVuCiAgICAgICAgc2Vu dC4iICBXaXRoICJBICZsdDtyZXBsYXlDb21wbGV0ZSZndDsgbm90aWZpY2F0aW9uIGlzIHNlbnQg dG8KICAgICAgICBpbmRpY2F0ZSB0aGF0IGFsbCBvZiB0aGUgcmVwbGF5IG5vdGlmaWNhdGlvbnMg aGF2ZSBiZWVuIHNlbnQgYW5kCiAgICAgICAgbXVzdCBub3QgYmUgc2VudCBmb3IgYW55IG90aGVy IHJlYXNvbi4iCgogICA5LiAgIEluIHNlY3Rpb24gMy4zLjEsIHJlcGxhY2VkICJBIG5vdGlmaWNh dGlvbiBzdHJlYW0gdGhhdCBzdXBwb3J0cwogICAgICAgIHJlcGxheSBpcyBub3QgZXhwZWN0ZWQg dG8gaGF2ZSBhbiB1bmxpbWl0ZWQgc3VwcGx5IG9mIHNhdmVkCiAgICAgICAgbm90aWZpY2F0aW9u cyBhdmFpbGFibGUgdG8gYWNjb21tb2RhdGUgYW55IHJlcGxheSByZXF1ZXN0LiIKICAgICAgICBX aXRoICJBIG5vdGlmaWNhdGlvbiBzdHJlYW0gdGhhdCBzdXBwb3J0cyByZXBsYXkgaXMgbm90IGV4 cGVjdGVkCiAgICAgICAgdG8gaGF2ZSBhbiB1bmxpbWl0ZWQgc3VwcGx5IG9mIHNhdmVkIG5vdGlm aWNhdGlvbnMgYXZhaWxhYmxlIHRvCiAgICAgICAgYWNjb21tb2RhdGUgYW55IHJlcGxheSByZXF1 ZXN0LiAgQ2xpZW50cyBjYW4gcXVlcnkKICAgICAgICAmbHQ7cmVwbGF5TG9nQ3JlYXRpb25UaW1l Jmd0OyBhbmQgJmx0O3JlcGxheUxvZ0FnZWRUaW1lJmd0OyB0byBsZWFybiBhYm91dAogICAgICAg IHRoZSBhdmFpbGFiaWxpdHkgb2Ygbm90aWZpY2F0aW9ucyBmb3IgcmVwbGF5LiIKICAgMTAuICBJ biBzZWN0aW9uIDMuMiwgcmVwbGFjZWQgIkZpZ3VyZSAyIGlsbHVzdHJhdGVzIHRoZSBub3RpZmlj YXRpb24KICAgICAgICBmbG93IGFuZCBjb25jZXB0cyBpZGVudGlmaWVkIGluIHRoaXMgZG9jdW1l bnQuIiAgV2l0aCAiRmlndXJlIDIKICAgICAgICBpbGx1c3RyYXRlcyB0aGUgbm90aWZpY2F0aW9u IGZsb3cgYW5kIGNvbmNlcHRzIGlkZW50aWZpZWQgaW4KICAgICAgICB0aGlzIGRvY3VtZW50LiAg SXQgZG9lcyBub3QgbWFuZGF0ZSBhbmQvb3IgcHJlY2x1ZGUgYW4KICAgICAgICBpbXBsZW1lbnRh dGlvbi4iCgogICAxMS4gIEluIHNlY3Rpb24gNi4xLCBhZGRlZCB0aGUgZm9sbG93aW5nIHRleHQg IlRoaXMgY2FwYWJpbGl0eSBoZWxwcwogICAgICAgIHNjYWxhYmlsaXR5IGJ5IHJlZHVjaW5nIHRo ZSB0b3RhbCBudW1iZXIgb2YgTkVUQ09ORiBzZXNzaW9ucwogICAgICAgIHJlcXVpcmVkIGJ5IGEg Z2l2ZW4gb3BlcmF0b3Igb3IgbWFuYWdlbWVudCBhcHBsaWNhdGlvbi4iCgogICAxMi4gIEluIHNl Y3Rpb24gMy42LCBkZWxldGVkICJXaGVuIG11bHRpcGxlIGZpbHRlciBlbGVtZW50cyBhcmUKICAg ICAgICBzcGVjaWZpZWQsIHRoZXkgYXJlIGFwcGxpZWQgY29sbGVjdGl2ZWx5LCBzbyBldmVudCBu b3RpZmljYXRpb25zCiAgICAgICAgbmVlZCB0byBwYXNzIGFsbCBzcGVjaWZpZWQgZmlsdGVyIGVs ZW1lbnRzIGluIG9yZGVyIHRvIGJlIHNlbnQKICAgICAgICB0byB0aGUgc3Vic2NyaWJlci4gIgoK ICAgMTMuICBJbiBzZWN0aW9uIDcgKFNlY3VyaXR5IENvbnNpZGVyYXRpb25zKSBhZnRlciB0aGUg YnVsbGV0cyBhZGRlZAogICAgICAgIHRoZSBmb2xsb3dpbmc6IFNlY3VyZSBleGVjdXRpb24gbWVh bnMgZW5zdXJpbmcgdGhhdCBhIHNlY3VyZQogICAgICAgIHRyYW5zcG9ydCBpcyB1c2VkIGFzIHdl bGwgYXMgZW5zdXJpbmcgdGhhdCB0aGUgdXNlciBoYXMKICAgICAgICBzdWZmaWNpZW50IGF1dGhv cml6YXRpb24gdG8gcGVyZm9ybSB0aGUgZnVuY3Rpb24gdGhleSBhcmUKICAgICAgICByZXF1ZXN0 aW5nIGFnYWluc3QgdGhlIHNwZWNpZmljIHBpZWNlIG9mIE5FVENPTkYgY29udGVudAogICAgICAg IGludm9sdmVkLiAgV2hlbiBhICZsdDtnZXQmZ3Q7IGlzIHJlY2VpdmVkIGFnYWluc3QgdGhlIGNv bnRlbnQgZGVmaW5lZAogICAgICAgIGluIHRoaXMgbWVtbywgY2xpZW50cyBzaG91bGQgb25seSBi ZSBhYmxlIHRvIHZpZXcgdGhlIGNvbnRlbnQKICAgICAgICBmb3Igd2hpY2ggdGhleSBoYXZlIHN1 ZmZpY2llbnQgcHJpdmlsZWdlcy4gIEEgY3JlYXRlICZsdDtjcmVhdGUtCiAgICAgICAgc3Vic2Ny aXB0aW9uJmd0OyBvcGVyYXRpb24gY2FuIGJlIGNvbnNpZGVyZWQgbGlrZSBhIGRlZmVycmVkICZs dDtnZXQmZ3Q7LAogICAgICAgIGFuZCB0aGUgY29udGVudCB0aGF0IGRpZmZlcmVudCB1c2VycyBj YW4gYWNjZXNzIG1heSB2YXJ5LiAgVGhpcwogICAgICAgIGRpZmZlcmVudCBhY2Nlc3MgaXMgcmVm bGVjdGVkIGluIHRoZSAmbHQ7bm90aWZpY2F0aW9uJmd0OyB0aGF0CiAgICAgICAgZGlmZmVyZW50 IHVzZXJzIGFyZSBhYmxlIHRvIHN1YnNjcmliZSB0by4KCiAgIDE0LiAgVXBkYXRlZCBpbXBvcnQg c3RhdGVtZW50cyB0byBub3QgdXNlZCBmdWxseSBxdWFsaWZpZWQgVVJMcy48L2ZvbnQ+PCBvc3NpYmxlIGV2ZW50cwogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpcyBvZiBpbnRlcmVzdC4gVGhlIGZvcm1h dCBvZiB0aGlzCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhcmFtZXRlciBp cyB0aGUgc2FtZSBhcyB0aGF0IG9mIHRoZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBmaWx0ZXIgcGFyYW1ldGVyIGluIHRoZSBORVRDT05GCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHByb3RvY29sIG9wZXJhdGlvbnMuIElmIG5vdCBwcmVzZW50LAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbGwgZXZlbnRzIG5vdCBwcmVjbHVkZWQg Ynkgb3RoZXIKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFyYW1ldGVycyB3 aWxsIGJlIHNlbnQuCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czpkb2N1 bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czphbm5vdGF0 aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmVsZW1lbnQmZ3Q7CiAgICAg ICAgICAgICAgICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic3RhcnRUaW1lIiB0eXBlPSJ4czpk YXRlVGltZSIKICAgICAgICAgICAgICAgICAgICAgICAgbWluT2NjdXJzPSIwIiAmZ3Q7CiAgICAg ICAgICAgICAgICAgICAgICAgICZsdDt4czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAg ICAgICAgICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQSBwYXJhbWV0ZXIgdXNlZCB0byB0cmlnZ2VyIHRoZSByZXBsYXkKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBmZWF0dXJlIGFuZCBpbmRpY2F0ZXMgdGhhdCB0aGUg cmVwbGF5CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2hvdWxkIHN0YXJ0IGF0IHRo ZSB0aW1lIHNwZWNpZmllZC4gSWYKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdGFy dCB0aW1lIGlzIG5vdCBwcmVzZW50LCB0aGlzIGlzIG5vdCBhCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgcmVwbGF5IHN1YnNjcmlwdGlvbi4KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAgICAgICAgICAgJmx0 Oy94czphbm5vdGF0aW9uJmd0OwogICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZWxlbWVudCZn dDsKICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJzdG9wVGltZSIgdHlw ZT0ieHM6ZGF0ZVRpbWUiCiAgICAgICAgICAgICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIgJmd0 OwogICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICZsdDt4czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEFuIG9wdGlvbmFsIHBhcmFtZXRlciB1c2VkIHdpdGggdGhlCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb3B0aW9uYWwgcmVwbGF5IGZlYXR1cmUgdG8g aW5kaWNhdGUgdGhlCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbmV3ZXN0IG5vdGlm aWNhdGlvbnMgb2YgaW50ZXJlc3QuIElmCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg c3RvcCB0aW1lIGlzIG5vdCBwcmVzZW50LCB0aGUKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBub3RpZmljYXRpb25zIHdpbGwgY29udGludWUgdW50aWwgdGhlCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgc3Vic2NyaXB0aW9uIGlzIHRlcm1pbmF0ZWQuIE11c3QgYmUgdXNl ZAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdpdGggc3RhcnRUaW1lLgogICAgICAg ICAgICAgICAgICAgICAgICAgICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAg ICAgICAgICAgICAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICAgICAgICAgICAgICAg Jmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAgICAgJmx0Oy94czpzZXF1ZW5jZSZndDsK ICAgICAgICAgICAgJmx0Oy94czpleHRlbnNpb24mZ3Q7CiAgICAgICAgJmx0Oy94czpjb21wbGV4 Q29udGVudCZndDsKICAgICZsdDsveHM6Y29tcGxleFR5cGUmZ3Q7CgogICAgJmx0O3hzOnNpbXBs ZVR5cGUgbmFtZT0ic3RyZWFtTmFtZVR5cGUiJmd0OwogICAgICAgICZsdDt4czphbm5vdGF0aW9u Jmd0OwogICAgICAgICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICAgICAgICAg IFRoZSBuYW1lIG9mIGFuIGV2ZW50IHN0cmVhbS4KICAgICAgICAgICAgJmx0Oy94czpkb2N1bWVu dGF0aW9uJmd0OwogICAgICAgICZsdDsveHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAmbHQ7eHM6 cmVzdHJpY3Rpb24gYmFzZT0ieHM6c3RyaW5nIi8mZ3Q7CiAgICAmbHQ7L3hzOnNpbXBsZVR5cGUm Z3Q7CgogICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iY3JlYXRlLXN1YnNjcmlwdGlvbiIKICAgICAg ICB0eXBlPSJjcmVhdGVTdWJzY3JpcHRpb25UeXBlIgogICAgICAgIHN1YnN0aXR1dGlvbkdyb3Vw PSJuZXRjb25mOnJwY09wZXJhdGlvbiImZ3Q7CiAgICAgICAgJmx0O3hzOmFubm90YXRpb24mZ3Q7 CiAgICAgICAgICAgICZsdDt4czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgVGhl IGNvbW1hbmQgdG8gY3JlYXRlIGEgbm90aWZpY2F0aW9uIHN1YnNjcmlwdGlvbi4gSXQKICAgICAg ICAgICAgICAgIHRha2VzIGFzIGFyZ3VtZW50IHRoZSBuYW1lIG9mIHRoZSBub3RpZmljYXRpb24g c3RyZWFtCiAgICAgICAgICAgICAgICBhbmQgZmlsdGVyLiBCb3RoIG9mIHRob3NlIG9wdGlvbnMK ICAgICAgICAgICAgICAgIGxpbWl0IHRoZSBjb250ZW50IG9mIHRoZSBzdWJzY3JpcHRpb24uIElu IGFkZGl0aW9uLAogICAgICAgICAgICAgICAgdGhlcmUgYXJlIHR3byB0aW1lLXJlb9zdHJv bmc+CgpBdXRob3JzJyBBZGRyZXNzZXMKCiAgIFNoYXJvbiBDaGlzaG9sbQogICBOb3J0ZWwKICAg MzUwMCBDYXJsaW5nIEF2ZQogICBOZXBlYW4sIE9udGFyaW8gIEsySCA4RTkKICAgQ2FuYWRhCgog ICBFbWFpbDogc2NoaXNob2xAbm9ydGVsLmNvbQoKICAgSGVjdG9yIFRyZXZpbm8KICAgQ2lzY28K ICAgU3VpdGUgNDAwCiAgIDkxNTUgRS4gTmljaG9scyBBdmUKICAgRW5nbGV3b29kLCBDTyAgODAx MTIKICAgVVNBCgogICBFbWFpbDogaHRyZXZpbm9AY2lzY28uY29tCgpGdWxsIENvcHlyaWdodCBT dGF0ZW1lbnQKCiAgIENvcHlyaWdodCAoQykgVGhlIElFVEYgVHJ1c3QgKDIwMDgpLgoKICAgVGhp cyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmlj dGlvbnMKICAgY29udGFpbmVkIGluIEJDUCA3OCwgYW5kIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhl cmVpbiwgdGhlIGF1dGhvcnMKICAgcmV0YWluIGFsbCB0aGVpciByaWdodHMuCgogICBUaGlzIGRv Y3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQg b24gYW4KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFU SU9OIEhFL1NIRSBSRVBSRVNFTlRTCiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhF IElOVEVSTkVUIFNPQ0lFVFksIFRIRSBJRVRGIFRSVVNUIEFORAogICBUSEUgSU5URVJORVQgRU5H SU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUwogICBP UiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFU IFRIRSBVU0UgT0YKICAgVEhFIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBB TlkgUklHSFRTIE9SIEFOWSBJTVBMSUVECiAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZ IE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLgoKSW50ZWxsZWN0dWFsIFByb3Bl cnR5CgogICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5 IG9yIHNjb3BlIG9mIGFueQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVy IHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8KICAgcGVydGFpbiB0byB0aGUgaW1wbGVt ZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbgogICB0aGlzIGRv Y3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdo dHMKICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVz ZW50IHRoYXQgaXQgaGFzCiAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlm eSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbgogICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRo IHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlCiAgIGZvdW5kIGluIEJD UCA3OCBhbmQgQkNQIDc5LgoKICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRo ZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkKICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBi ZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbgogICBhdHRlbXB0IG1hZGUgdG8g b2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YKICAg c3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMK ICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQ UiByZXBvc2l0b3J5IGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLgoKICAgVGhlIElFVEYg aW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFu eQogICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVy IHByb3ByaWV0YXJ5CiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5 IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudAogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJl c3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0CiAgIGlldGYtaXByQGlldGYub3JnLgoK QWNrbm93bGVkZ21lbnQKCiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlz IHByb3ZpZGVkIGJ5IHRoZSBJRVRGCiAgIEFkbWluaXN0cmF0aXZlIFN1cHBvcnQgQWN0aXZpdHkg KElBU0EpLgo8L3ByZT4KPC9ib2R5PjwvaHRtbD4K ------_=_NextPart_001_01C8A62E.7F0483AA Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------_=_NextPart_001_01C8A62E.7F0483AA-- GF0ZWQgcGFy YW1ldGVycywgc3RhcnRUaW1lIGFuZAogICAgICAgICAgICAgICAgc3RvcFRpbWUsIHdoaWNoIGNh biBiZSB1c2VkIHRvIHNlbGVjdCB0aGUgdGltZSBpbnRlcnZhbAogICAgICAgICAgICAgICAgb2Yg aW50ZXJlc3QgdG8gdGhlIG5vdGlmaWNhdGlvbiByZXBsYXkgZmVhdHVyZS4KICAgICAgICAgICAg Jmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICZsdDsveHM6YW5ub3RhdGlvbiZndDsK ICAgICZsdDsveHM6ZWxlbWVudCZndDsKCiZsdDshLS0gKioqKioqKioqKioqKiogT25lLXdheSBP cGVyYXRpb25zICAqKioqKioqKioqKioqKioqKiotLSZndDsKCiAgICAgJmx0OyEtLSAmbHQ7Tm90 aWZpY2F0aW9uJmd0OyBvcGVyYXRpb24gLS0mZ3Q7CiAgICAgJmx0O3hzOmNvbXBsZXhUeXBlIG5h bWU9Ik5vdGlmaWNhdGlvbkNvbnRlbnRUeXBlIi8mZ3Q7CgogICAgJmx0O3hzOmVsZW1lbnQgbmFt ZT0ibm90aWZpY2F0aW9uQ29udGVudCIKICAgICAgICB0eXBlPSJOb3RpZmljYXRpb25Db250ZW50 VHlwZSIgYWJzdHJhY3Q9InRydWUiLyZndDsKCiAgICAmbHQ7eHM6Y29tcGxleFR5cGUgbmFtZT0i Tm90aWZpY2F0aW9uVHlwZSImZ3Q7CiAgICAgICAgJmx0O3hzOnNlcXVlbmNlJmd0OwogICAgICAg ICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJldmVudFRpbWUiIHR5cGU9InhzOmRhdGVUaW1lIiZn dDsKICAgICAgICAgICAgICAmbHQ7eHM6YW5ub3RhdGlvbiZndDsKICAgICAgICAgICAgICAgICZs dDt4czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICAgVGhlIHRpbWUgdGhlIGV2ZW50 IHdhcyBnZW5lcmF0ZWQgYnkgdGhlIGV2ZW50IHNvdXJjZQogICAgICAgICAgICAgICAgJmx0Oy94 czpkb2N1bWVudGF0aW9uJmd0OwogICAgICAgICAgICAgICZsdDsveHM6YW5ub3RhdGlvbiZndDsK ICAgICAgICAgICAgJmx0Oy94czplbGVtZW50Jmd0OwogICAgICAgICAgICAmbHQ7eHM6ZWxlbWVu dCByZWY9Im5vdGlmaWNhdGlvbkNvbnRlbnQiLyZndDsKICAgICAgICAmbHQ7L3hzOnNlcXVlbmNl Jmd0OwogICAgJmx0Oy94czpjb21wbGV4VHlwZSZndDsKCiAgICAmbHQ7eHM6ZWxlbWVudCBuYW1l PSJub3RpZmljYXRpb24iIHR5cGU9Ik5vdGlmaWNhdGlvblR5cGUiLyZndDsKCiAgJmx0Oy94czpz Y2hlbWEmZ3Q7Cgo1LiAgRmlsdGVyaW5nIEV4YW1wbGVzCgogICBUaGUgZm9sbG93aW5nIHNlY3Rp b24gcHJvdmlkZXMgZXhhbXBsZXMgdG8gaWxsdXN0cmF0ZSB0aGUgdmFyaW91cwogICBtZXRob2Rz IG9mIGZpbHRlcmluZyBjb250ZW50IG9uIGFuIGV2ZW50IG5vdGlmaWNhdGlvbiBzdWJzY3JpcHRp b24uCgogICBJbiBvcmRlciB0byBpbGx1c3RyYXRlIHRoZSB1c2Ugb2YgZmlsdGVyIGV4cHJlc3Np b25zLCBpdCBpcyBuZWNlc3NhcnkKICAgdG8gYXNzdW1lIHNvbWUgb2YgdGhlIGV2ZW50IG5vdGlm aWNhdGlvbiBjb250ZW50LiAgVGhlIGV4YW1wbGVzIGJlbG93CiAgIGFzc3VtZSB0aGF0IHRoZSBl dmVudCBub3RpZmljYXRpb24gc2NoZW1hIGRlZmluaXRpb24gaGFzIGFuICZsdDtldmVudCZndDsK ICAgZWxlbWVudCBhdCB0aGUgdG9wIGxldmVsIGNvbnNpc3Rpbmcgb2YgdGhlIGV2ZW50IGNsYXNz IChlLmcuLCBmYXVsdCwKICAgc3RhdGUsIGNvbmZpZyksIHJlcG9ydGluZyBlbnRpdHkgYW5kIGVp dGhlciBzZXZlcml0eSBvciBvcGVyYXRpb25hbAogICBzdGF0ZS4KCiAgIEV4YW1wbGVzIGluIHRo aXMgc2VjdGlvbiBhcmUgZ2VuZXJhdGVkIGZyb20gdGhlIGZvbGxvd2luZyBmaWN0aW9uYWwKICAg U2NoZW1hLgoKICAgICZsdDs/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8mZ3Q7 CiAgICZsdDt4czpzY2hlbWEgdGFyZ2V0TmFtZXNwYWNlPSJodHRwOi8vZXhhbXBsZS5jb20vZXZl bnQvMS4wIgogICAgICAgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ldmVudC8xLjAiCiAgICAg ICBlbGVtZW50Rm9ybURlZmF1bHQ9InF1YWxpZmllZCIKICAgICAgIHhtbG5zOnhzPSJodHRwOi8v d3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIKICAgICAgIHhtbG5zOm5jRXZlbnQ9InVybjppZXRm OnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRpb246MS4wIiZndDsKCiAgICAgICAmbHQ7 eHM6aW1wb3J0IG5hbWVzcGFjZT0KICAgICAgICAgICAidXJuOmlldGY6cGFyYW1zOnhtbDpuczpu ZXRjb25mOm5vdGlmaWNhdGlvbjoxLjAiCiAgICAgICAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVk Jz5zY2hlbWFMb2NhdGlvbj0KImh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMveG1sLXJl Z2lzdHJ5L3NjaGVtYS9ub3RpZmljYXRpb24ueHNkIi8mZ3Q7PC9mb250Pjwvc3RyaWtlPgogICAg ICAgICAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5zY2hlbWFMb2NhdGlvbj0ibm90aWZp Y2F0aW9uLnhzZCIvJmd0OzwvZm9udD48L3N0cm9uZz4KCiAgICAgICAmbHQ7eHM6Y29tcGxleFR5 cGUgbmFtZT0iZXZlbnRUeXBlIiZndDsKICAgICAgICAgICAmbHQ7eHM6Y29tcGxleENvbnRlbnQm Z3Q7CiAgICAgICAgICAgICAgICZsdDt4czpleHRlbnNpb24gYmFzZT0ibmNFdmVudDpOb3RpZmlj YXRpb25Db250ZW50VHlwZSImZ3Q7CiAgICAgICAgICAgICAgICAgICAmbHQ7eHM6c2VxdWVuY2Um Z3Q7CiAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iZXZlbnRDbGFz cyIgLyZndDsKICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJyZXBv cnRpbmdFbnRpdHkiJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6Y29tcGxl eFR5cGUmZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7eHM6c2VxdWVuY2Um Z3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmx0O3hzOmFueSBuYW1lc3Bh Y2U9IiMjYW55IgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByb2Nlc3NDb250 ZW50cz0ibGF4Ii8mZ3Q7CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOnNl cXVlbmNlJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAgICAmbHQ7L3hzOmNvbXBsZXhUeXBl Jmd0OwogICAgICAgICAgICAgICAgICAgICAgICZsdDsveHM6ZWxlbWVudCZndDsKICAgICAgICAg ICAgICAgICAgICAgICAmbHQ7eHM6Y2hvaWNlJmd0OwogICAgICAgICAgICAgICAgICAgICAgICAg ICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJzZXZlcml0eSIvJmd0OwogICAgICAgICAgICAgICAgICAg ICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJvcGVyU3RhdGUiLyZndDsKICAgICAgICAgICAg ICAgICAgICAgICAmbHQ7L3hzOmNob2ljZSZndDsKICAgICAgICAgICAgICAgICAgICZsdDsveHM6 c2VxdWVuY2UmZ3Q7CiAgICAgICAgICAgICAgICZsdDsveHM6ZXh0ZW5zaW9uJmd0OwogICAgICAg ICAgICZsdDsveHM6Y29tcGxleENvbnRlbnQmZ3Q7CiAgICAgICAmbHQ7L3hzOmNvbXBsZXhUeXBl Jmd0OwoKICAgICAgICZsdDt4czplbGVtZW50IG5hbWU9ImV2ZW50IgogICAgICAgICAgIHR5cGU9 ImV2ZW50VHlwZSIKICAgICAgICAgICBzdWJzdGl0dXRpb25Hcm91cD0ibmNFdmVudDpub3RpZmlj YXRpb25Db250ZW50Ii8mZ3Q7CgogICAmbHQ7L3hzOnNjaGVtYSZndDsKCiAgIFRoZSBhYm92ZSBm aWN0aW9uYWwgbm90aWZpY2F0aW9uIGRlZmluaXRpb24gY291bGQgcmVzdWx0IGluIHRoZQogICBm b2xsb3dpbmcgc2FtcGxlIG5vdGlmaWNhdGlvbiBsaXN0LCB3aGljaCBpcyB1c2VkIGluIHRoZSBl eGFtcGxlcyBpbgogICB0aGlzIHNlY3Rpb24uCgogICAmbHQ7bm90aWZpY2F0aW9uCiAgICAgIHht bG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6bm90aWZpY2F0aW9uOjEuMCImZ3Q7 CiAgICAgICZsdDtldmVudFRpbWUmZ3Q7MjAwNy0wNy0wOFQwMDowMTowMFombHQ7L2V2ZW50VGlt ZSZndDsKICAgICAgJmx0O2V2ZW50IHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4w IiZndDsKICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7ZmF1bHQmbHQ7L2V2ZW50Q2xhc3MmZ3Q7 CiAgICAgICAgICZsdDtyZXBvcnRpbmdFbnRpdHkmZ3Q7CiAgICAgICAgICAgICAmbHQ7Y2FyZCZn dDtFdGhlcm5ldDAmbHQ7L2NhcmQmZ3Q7CiAgICAgICAgICZsdDsvcmVwb3J0aW5nRW50aXR5Jmd0 OwogICAgICAgICAmbHQ7c2V2ZXJpdHkmZ3Q7bWFqb3ImbHQ7L3NldmVyaXR5Jmd0OwogICAgICAg Jmx0Oy9ldmVudCZndDsKICAgJmx0Oy9ub3RpZmljYXRpb24mZ3Q7CgogICAmbHQ7bm90aWZpY2F0 aW9uCiAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRp b246MS4wIiZndDsKICAgICAgJmx0O2V2ZW50VGltZSZndDsyMDA3LTA3LTA4VDAwOjAyOjAwWiZs dDsvZXZlbnRUaW1lJmd0OwogICAgICAmbHQ7ZXZlbnQgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNv bS9ldmVudC8xLjAiJmd0OwogICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7ZmF1bHQmbHQ7L2V2 ZW50Q2xhc3MmZ3Q7CiAgICAgICAgICAmbHQ7cmVwb3J0aW5nRW50aXR5Jmd0OwogICAgICAgICAg ICAgICZsdDtjYXJkJmd0O0V0aGVybmV0MiZsdDsvY2FyZCZndDsKICAgICAgICAgICZsdDsvcmVw b3J0aW5nRW50aXR5Jmd0OwogICAgICAgICAgJmx0O3NldmVyaXR5Jmd0O2NyaXRpY2FsJmx0Oy9z ZXZlcml0eSZndDsKICAgICAgICZsdDsvZXZlbnQmZ3Q7CiAgICZsdDsvbm90aWZpY2F0aW9uJmd0 OwoKICAgJmx0O25vdGlmaWNhdGlvbgogICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5z Om5ldGNvbmY6bm90aWZpY2F0aW9uOjEuMCImZ3Q7CiAgICAgICZsdDtldmVudFRpbWUmZ3Q7MjAw Ny0wNy0wOFQwMDowNDowMFombHQ7L2V2ZW50VGltZSZndDsKICAgICAgJmx0O2V2ZW50IHhtbG5z PSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIiZndDsKICAgICAgICAgICZsdDtldmVudENs YXNzJmd0O2ZhdWx0Jmx0Oy9ldmVudENsYXNzJmd0OwogICAgICAgICAgJmx0O3JlcG9ydGluZ0Vu dGl0eSZndDsKICAgICAgICAgICAgICAgJmx0O2NhcmQmZ3Q7QVRNMSZsdDsvY2FyZCZndDsKICAg ICAgICAgICAmbHQ7L3JlcG9ydGluZ0VudGl0eSZndDsKICAgICAgICAgICAmbHQ7c2V2ZXJpdHkm Z3Q7bWlub3ImbHQ7L3NldmVyaXR5Jmd0OwogICAgICAmbHQ7L2V2ZW50Jmd0OwogICAmbHQ7L25v dGlmaWNhdGlvbiZndDsKCiAgICZsdDtub3RpZmljYXRpb24KICAgICB4bWxucz0idXJuOmlldGY6 cGFyYW1zOnhtbDpuczpuZXRjb25mOm5vdGlmaWNhdGlvbjoxLjAiJmd0OwogICAgICZsdDtldmVu dFRpbWUmZ3Q7MjAwNy0wNy0wOFQwMDoxMDowMFombHQ7L2V2ZW50VGltZSZndDsKICAgICAmbHQ7 ZXZlbnQgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ldmVudC8xLjAiJmd0OwogICAgICAgICAm bHQ7ZXZlbnRDbGFzcyZndDtzdGF0ZSZsdDsvZXZlbnRDbGFzcyZndDsKICAgICAgICAgJmx0O3Jl cG9ydGluZ0VudGl0eSZndDsKICAgICAgICAgICAgICZsdDtjYXJkJmd0O0V0aGVybmV0MCZsdDsv Y2FyZCZndDsKICAgICAgICAgJmx0Oy9yZXBvcnRpbmdFbnRpdHkmZ3Q7CiAgICAgICAgICZsdDtv cGVyU3RhdGUmZ3Q7ZW5hYmxlZCZsdDsvb3BlclN0YXRlJmd0OwogICAgICAmbHQ7L2V2ZW50Jmd0 OwogICAmbHQ7L25vdGlmaWNhdGlvbiZndDsKCjUuMS4gIFN1YnRyZWUgRmlsdGVyaW5nCgogICBY TUwgc3VidHJlZSBmaWx0ZXJpbmcgaXMgbm90IHdlbGwtc3VpdGVkIGZvciBjcmVhdGluZyBlbGFi b3JhdGUKICAgZmlsdGVyIGRlZmluaXRpb25zIGdpdmVuIHRoYXQgaXQgb25seSBzdXBwb3J0cyBl cXVhbGl0eSBjb21wYXJpc29ucwogICBhbmQgYXBwbGljYXRpb24gb2YgdGhlIGxvZ2ljYWwgT1Ig b3BlcmF0b3JzIChlLmcuLCBpbiBhbiBldmVudAogICBzdWJ0cmVlIGdpdmUgbWUgYWxsIGV2ZW50 IG5vdGlmaWNhdGlvbnMgd2hpY2ggaGF2ZSBzZXZlcml0eT1jcml0aWNhbAogICBvciBzZXZlcml0 eT1tYWpvciBvciBzZXZlcml0eT1taW5vcikuICBOZXZlcnRoZWxlc3MsIGl0IG1heSBiZSB1c2Vk CiAgIGZvciBkZWZpbmluZyBzaW1wbGUgZXZlbnQgbm90aWZpY2F0aW9uIGZvcndhcmRpbmcgZmls dGVycyBhcyBzaG93bgogICBiZWxvdy4KCiAgIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSBpbGx1c3Ry YXRlcyBob3cgdG8gc2VsZWN0IGZhdWx0IGV2ZW50cyB3aGljaAogICBoYXZlIHNldmVyaXRpZXMg b2YgY3JpdGljYWwsIG1ham9yLCBvciBtaW5vci4gIFRoZSBmaWx0ZXJpbmcgY3JpdGVyaWEKICAg ZXZhbHVhdGlvbiBpcyBhcyBmb2xsb3dzOgoKICAgKChmYXVsdCAmYW1wOyBzZXZlcml0eT1jcml0 aWNhbCkgfCAoZmF1bHQgJmFtcDsgc2V2ZXJpdHk9bWFqb3IpIHwgKGZhdWx0ICZhbXA7CiAgIHNl dmVyaXR5PW1pbm9yKSkKCiAgICAgICAgJmx0O25ldGNvbmY6cnBjIG5ldGNvbmY6bWVzc2FnZS1p ZD0iMTAxIgogICAgICAgICAgICAgICAgeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6cGFyYW1zOnht bDpuczpuZXRjb25mOmJhc2U6MS4wIiZndDsKICAgICAgICAgICZsdDtjcmVhdGUtc3Vic2NyaXB0 aW9uCiAgICAgICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpu b3RpZmljYXRpb246MS4wIiZndDsKICAgICAgICAgICAgJmx0O2ZpbHRlciBuZXRjb25mOnR5cGU9 InN1YnRyZWUiJmd0OwogICAgICAgICAgICAgICZsdDtldmVudCB4bWxucz0iaHR0cDovL2V4YW1w bGUuY29tL2V2ZW50LzEuMCImZ3Q7CiAgICAgICAgICAgICAgICAmbHQ7ZXZlbnRDbGFzcyZndDtm YXVsdCZsdDsvZXZlbnRDbGFzcyZndDsKICAgICAgICAgICAgICAgICZsdDtzZXZlcml0eSZndDtj cml0aWNhbCZsdDsvc2V2ZXJpdHkmZ3Q7CiAgICAgICAgICAgICAgJmx0Oy9ldmVudCZndDsKICAg ICAgICAgICAgICAmbHQ7ZXZlbnQgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ldmVudC8xLjAi Jmd0OwogICAgICAgICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7ZmF1bHQmbHQ7L2V2ZW50Q2xh c3MmZ3Q7CiAgICAgICAgICAgICAgICAmbHQ7c2V2ZXJpdHkmZ3Q7bWFqb3ImbHQ7L3NldmVyaXR5 Jmd0OwogICAgICAgICAgICAgICZsdDsvZXZlbnQmZ3Q7CiAgICAgICAgICAgICAgJmx0O2V2ZW50 IHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIiZndDsKICAgICAgICAgICAgICAg ICZsdDtldmVudENsYXNzJmd0O2ZhdWx0Jmx0Oy9ldmVudENsYXNzJmd0OwogICAgICAgICAgICAg ICAgJmx0O3NldmVyaXR5Jmd0O21pbm9yJmx0Oy9zZXZlcml0eSZndDsKICAgICAgICAgICAgICAm bHQ7L2V2ZW50Jmd0OwogICAgICAgICAgICAmbHQ7L2ZpbHRlciZndDsKICAgICAgICAgICZsdDsv Y3JlYXRlLXN1YnNjcmlwdGlvbiZndDsKICAgICAgICAmbHQ7L25ldGNvbmY6cnBjJmd0OwoKICAg VGhlIGZvbGxvd2luZyBleGFtcGxlIGlsbHVzdHJhdGVzIGhvdyB0byBzZWxlY3Qgc3RhdGUgb3Ig Y29uZmlnCiAgIEV2ZW50Q2xhc3NlcyBvciBmYXVsdCBldmVudHMgdGhhdCBhcmUgcmVsYXRlZCB0 byBjYXJkIEV0aGVybmV0MC4gIFRoZQogICBmaWx0ZXJpbmcgY3JpdGVyaWEgZXZhbHVhdGlvbiBp cyBhcyBmb2xsb3dzOgoKICAgKCBzdGF0ZSB8IGNvbmZpZyB8ICggZmF1bHQgJmFtcDsgKCBjYXJk PUV0aGVybmV0MCkpKQoKJmx0O25ldGNvbmY6cnBjIG5ldGNvbmY6bWVzc2FnZS1pZD0iMTAxIgog ICAgICAgICAgICAgICAgeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRj b25mOmJhc2U6MS4wIiZndDsKICAgICAgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24KICAgICAgICAg IHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6bm90aWZpY2F0aW9uOjEuMCIm Z3Q7CiAgICAgICAgJmx0O2ZpbHRlciBuZXRjb25mOnR5cGU9InN1YnRyZWUiJmd0OwogICAgICAg ICAgJmx0O2V2ZW50IHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIiZndDsKICAg ICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7c3RhdGUmbHQ7L2V2ZW50Q2xhc3MmZ3Q7CiAgICAg ICAgICAmbHQ7L2V2ZW50Jmd0OwogICAgICAgICAgJmx0O2V2ZW50IHhtbG5zPSJodHRwOi8vZXhh bXBsZS5jb20vZXZlbnQvMS4wIiZndDsKICAgICAgICAgICAgJmx0O2V2ZW50Q2xhc3MmZ3Q7Y29u ZmlnJmx0Oy9ldmVudENsYXNzJmd0OwogICAgICAgICAgJmx0Oy9ldmVudCZndDsKICAgICAgICAg ICZsdDtldmVudCB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL2V2ZW50LzEuMCImZ3Q7CiAgICAg ICAgICAgICZsdDtldmVudENsYXNzJmd0O2ZhdWx0Jmx0Oy9ldmVudENsYXNzJmd0OwogICAgICAg ICAgICAmbHQ7cmVwb3J0aW5nRW50aXR5Jmd0OwogICAgICAgICAgICAgICZsdDtjYXJkJmd0O0V0 aGVybmV0MCZsdDsvY2FyZCZndDsKICAgICAgICAgICAgJmx0Oy9yZXBvcnRpbmdFbnRpdHkmZ3Q7 CiAgICAgICAgICAmbHQ7L2V2ZW50Jmd0OwogICAgICAgICZsdDsvZmlsdGVyJmd0OwogICAgICAm bHQ7L2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7CiZsdDsvbmV0Y29uZjpycGMmZ3Q7Cgo1LjIuICBY UEFUSCBmaWx0ZXJzCgogICBUaGUgZm9sbG93aW5nIFtYUEFUSF0gZXhhbXBsZSBpbGx1c3RyYXRl cyBob3cgdG8gc2VsZWN0IGZhdWx0CiAgIEV2ZW50Q2xhc3Mgbm90aWZpY2F0aW9ucyB0aGF0IGhh dmUgc2V2ZXJpdGllcyBvZiBjcml0aWNhbCwgbWFqb3IsIG9yCiAgIG1pbm9yLiAgVGhlIGZpbHRl cmluZyBjcml0ZXJpYSBldmFsdWF0aW9uIGlzIGFzIGZvbGxvd3M6CgogICAoKGZhdWx0KSAmYW1w OyAoKHNldmVyaXR5PWNyaXRpY2FsKSB8IChzZXZlcml0eT1tYWpvcikgfCAoc2V2ZXJpdHkgPQog ICBtaW5vcikpKQoKICAgICAgJmx0O25ldGNvbmY6cnBjIG5ldGNvbmY6bWVzc2FnZS1pZD0iMTAx IgogICAgICAgICAgICAgICAgeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpu ZXRjb25mOmJhc2U6MS4wIiZndDsKICAgICAgICAmbHQ7Y3JlYXRlLXN1YnNjcmlwdGlvbgogICAg ICAgICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6bm90aWZpY2F0 aW9uOjEuMCImZ3Q7CiAgICAgICAgICAmbHQ7ZmlsdGVyIG5ldGNvbmY6dHlwZT0ieHBhdGgiCiAg ICAgICAgICAgICAgICAgIHhtbG5zOmV4PSJodHRwOi8vZXhhbXBsZS5jb20vZXZlbnQvMS4wIgog ICAgICAgICAgICAgc2VsZWN0PSIvZXg6ZXZlbnRbZXg6ZXZlbnRDbGFzcz0nZmF1bHQnIGFuZAog ICAgICAgICAgICAgICAgICAoZXg6c2V2ZXJpdHk9J21pbm9yJyBvciBleDpzZXZlcml0eT0nbWFq b3InCiAgICAgICAgICAgICAgICAgICAgICAgb3IgZXg6c2V2ZXJpdHk9J2NyaXRpY2FsJyldIi8m Z3Q7CiAgICAgICAgJmx0Oy9jcmVhdGUtc3Vic2NyaXB0aW9uJmd0OwogICAgICAmbHQ7L25ldGNv bmY6cnBjJmd0OwogICBUaGUgZm9sbG93aW5nIGV4YW1wbGUgaWxsdXN0cmF0ZXMgaG93IHRvIHNl bGVjdCBzdGF0ZSBhbmQgY29uZmlnCiAgIEV2ZW50Q2xhc3NlcyBvciBmYXVsdCBldmVudHMgb2Yg YW55IHNldmVyaXR5IHRoYXQgY29tZSBmcm9tIGNhcmQKICAgRXRoZXJuZXQwLiAgVGhlIGZpbHRl cmluZyBjcml0ZXJpYSBldmFsdWF0aW9uIGlzIGFzIGZvbGxvd3M6CgogICAoIHN0YXRlIHwgY29u ZmlnIHwgKGZhdWx0ICZhbXA7IGNhcmQ9RXRoZXJuZXQwKSkKCiAgICAgICZsdDtuZXRjb25mOnJw YyBtZXNzYWdlLWlkPSIxMDEiCiAgICAgICAgICAgICAgeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6 cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIiZndDsKICAgICAgICAmbHQ7Y3JlYXRlLXN1 YnNjcmlwdGlvbgogICAgICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNv bmY6bm90aWZpY2F0aW9uOjEuMCImZ3Q7CiAgICAgICAgICAgICAmbHQ7ZmlsdGVyIG5ldGNvbmY6 dHlwZT0ieHBhdGgiCiAgICAgICAgICAgICAgICAgICAgIHhtbG5zOmV4PSJodHRwOi8vZXhhbXBs ZS5jb20vZXZlbnQvMS4wIgogICAgICAgICAgICAgICAgc2VsZWN0PSIvZXg6ZXZlbnRbCiAgICAg ICAgICAgICAgICAgICAoZXg6ZXZlbnRDbGFzcz0nc3RhdGUnIG9yIGV4OmV2ZW50Q2xhc3M9J2Nv bmZpZycpIG9yCiAgICAgICAgICAgICAgICAgICAoKGV4OmV2ZW50Q2xhc3M9J2ZhdWx0JyBhbmQg ZXg6Y2FyZD0nRXRoZXJuZXQwJykpXSIvJmd0OwogICAgICAgJmx0Oy9jcmVhdGUtc3Vic2NyaXB0 aW9uJmd0OwogICAgICZsdDsvbmV0Y29uZjpycGMmZ3Q7Cgo2LiAgSW50ZXJsZWF2ZSBDYXBhYmls aXR5Cgo2LjEuICBEZXNjcmlwdGlvbgoKICAgVGhlIEludGVybGVhdmUgY2FwYWJpbGl0eSBpbmRp Y2F0ZXMgdGhhdCB0aGUgTkVUQ09ORiBwZWVyIHN1cHBvcnRzCiAgIHRoZSBhYmlsaXR5IHRvIGlu dGVybGVhdmUgb3RoZXIgTkVUQ09ORiBvcGVyYXRpb25zIHdpdGhpbiBhCiAgIE5vdGlmaWNhdGlv biBzdWJzY3JpcHRpb24uICBUaGlzIG1lYW5zIHRoZSBORVRDT05GIHNlcnZlciBNVVNUCiAgIHJl Y2VpdmUsIHByb2Nlc3MgYW5kIHJlc3BvbmQgdG8gTkVUQ09ORiByZXF1ZXN0cyBvbiBhIHNlc3Np b24gd2l0aCBhbgogICBhY3RpdmUgbm90aWZpY2F0aW9uIHN1YnNjcmlwdGlvbi4gIDxzdHJvbmc+ PGZvbnQgY29sb3I9J2dyZWVuJz5UaGlzIGNhcGFiaWxpdHkgaGVscHMgc2NhbGFiaWxpdHkKICAg YnkgcmVkdWNpbmcgdGhlIHRvdGFsIG51bWJlciBvZiBORVRDT05GIHNlc3Npb25zIHJlcXVpcmVk IGJ5IGEgZ2l2ZW4KICAgb3BlcmF0b3Igb3IgbWFuYWdlbWVudCBhcHBsaWNhdGlvbi48L2ZvbnQ+ PC9zdHJvbmc+Cgo2LjIuICBEZXBlbmRlbmNpZXMKCiAgIFRoaXMgY2FwYWJpbGl0eSBpcyBkZXBl bmRhbnQgb24gdGhlIG5vdGlmaWNhdGlvbiBjYXBhYmlsaXR5IGJlaW5nCiAgIHN1cHBvcnRlZC4K CjYuMy4gIENhcGFiaWxpdHkgSWRlbnRpZmllcgoKICAgVGhlIDppbnRlcmxlYXZlIGNhcGFiaWxp dHkgaXMgaWRlbnRpZmllZCBieSB0aGUgZm9sbG93aW5nIGNhcGFiaWxpdHkKICAgc3RyaW5nOgoK ICAgdXJuOmlldGY6cGFyYW1zOm5ldGNvbmY6Y2FwYWJpbGl0eTppbnRlcmxlYXZlOjEuMAoKNi40 LiAgTmV3IE9wZXJhdGlvbnMKCiAgIE5vbmUuCgo2LjUuICBNb2RpZmljYXRpb25zIHRvIEV4aXN0 aW5nIE9wZXJhdGlvbnMKCiAgIFdoZW4gYSAmbHQ7Y3JlYXRlLXN1YnNjcmlwdGlvbiZndDsgaXMg c2VudCB3aGlsZSBhbm90aGVyIHN1YnNjcmlwdGlvbiBpcwogICBhY3RpdmUgb24gdGhhdCBzZXNz aW9uLCB0aGUgZm9sbG93aW5nIGVycm9yIHdpbGwgYmUgcmV0dXJuZWQ6CgogICAgICBUYWc6IG9w ZXJhdGlvbi1mYWlsZWQKCiAgICAgIEVycm9yLXR5cGU6IHByb3RvY29sCgogICAgICBTZXZlcml0 eTogZXJyb3IKCiAgICAgIEVycm9yLWluZm86IG5vbmUKCiAgICAgIERlc2NyaXB0aW9uOiBSZXF1 ZXN0IGNvdWxkIG5vdCBiZSBjb21wbGV0ZWQgYmVjYXVzZSB0aGUgcmVxdWVzdGVkCiAgICAgIG9w ZXJhdGlvbiBmYWlsZWQgZm9yIHNvbWUgcmVhc29uIG5vdCBjb3ZlcmVkIGJ5IGFueSBvdGhlciBl cnJvcgogICAgICBjb25kaXRpb24uCgo3LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFRo ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmcm9tIHRoZSBiYXNlIFtORVRDT05GXSBkb2N1bWVu dCBhbHNvCiAgIGFwcGx5IHRvIHRoZSBOb3RpZmljYXRpb24gY2FwYWJpbGl0eS4KCiAgIFRoZSBh Y2Nlc3MgY29udHJvbCBmcmFtZXdvcmsgYW5kIHRoZSBjaG9pY2Ugb2YgdHJhbnNwb3J0IHdpbGwg aGF2ZSBhCiAgIG1ham9yIGltcGFjdCBvbiB0aGUgc2VjdXJpdHkgb2YgdGhlIHNvbHV0aW9uLgoK ICAgVGhlICZsdDtub3RpZmljYXRpb24mZ3Q7IGVsZW1lbnRzIGFyZSBuZXZlciBzZW50IGJlZm9y ZSB0aGUgdHJhbnNwb3J0IGxheWVyCiAgIGFuZCB0aGUgTkVUQ09ORiBsYXllciwgaW5jbHVkaW5n IGNhcGFiaWxpdGllcyBleGNoYW5nZSwgaGF2ZSBiZWVuCiAgIGVzdGFibGlzaGVkLCBhbmQgdGhl IG1hbmFnZXIgaGFzIGJlZW4gaWRlbnRpZmllZCBhbmQgYXV0aGVudGljYXRlZC4KCiAgIEl0IGlz IHJlY29tbWVuZGVkIHRoYXQgY2FyZSBiZSB0YWtlbiB0byBzZWN1cmUgZXhlY3V0aW9uOgoKICAg byAgJmx0O2NyZWF0ZS1zdWJzY3JpcHRpb24mZ3Q7IGludm9jYXRpb24KCiAgIG8gICZsdDtnZXQm Z3Q7IG9uIHJlYWQtb25seSBkYXRhIG1vZGVscwoKICAgbyAgJmx0O25vdGlmaWNhdGlvbiZndDsg Y29udGVudAoKICAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPlNlY3VyZSBleGVjdXRpb24g bWVhbnMgZW5zdXJpbmcgdGhhdCBhIHNlY3VyZSB0cmFuc3BvcnQgaXMgdXNlZCBhcwogICB3ZWxs IGFzIGVuc3VyaW5nIHRoYXQgdGhlIHVzZXIgaGFzIHN1ZmZpY2llbnQgYXV0aG9yaXphdGlvbiB0 bwogICBwZXJmb3JtIHRoZSBmdW5jdGlvbiB0aGV5IGFyZSByZXF1ZXN0aW5nIGFnYWluc3QgdGhl IHNwZWNpZmljIHBpZWNlCiAgIG9mIE5FVENPTkYgY29udGVudCBpbnZvbHZlZC4gIFdoZW4gYSAm bHQ7Z2V0Jmd0OyBpcyByZWNlaXZlZCBhZ2FpbnN0IHRoZQogICBjb250ZW50IGRlZmluZWQgaW4g dGhpcyBtZW1vLCBjbGllbnRzIHNob3VsZCBvbmx5IGJlIGFibGUgdG8gdmlldyB0aGUKICAgY29u dGVudCBmb3Igd2hpY2ggdGhleSBoYXZlIHN1ZmZpY2llbnQgcHJpdmlsZWdlcy4gIEEgY3JlYXRl ICZsdDtjcmVhdGUtCiAgIHN1YnNjcmlwdGlvbiZndDsgb3BlcmF0aW9uIGNhbiBiZSBjb25zaWRl cmVkIGxpa2UgYSBkZWZlcnJlZCAmbHQ7Z2V0Jmd0OywgYW5kCiAgIHRoZSBjb250ZW50IHRoYXQg ZGlmZmVyZW50IHVzZXJzIGNhbiBhY2Nlc3MgbWF5IHZhcnkuICBUaGlzIGRpZmZlcmVudAogICBh Y2Nlc3MgaXMgcmVmbGVjdGVkIGluIHRoZSAmbHQ7bm90aWZpY2F0aW9uJmd0OyB0aGF0IGRpZmZl cmVudCB1c2VycyBhcmUKICAgYWJsZSB0byBzdWJzY3JpYmUgdG8uPC9mb250Pjwvc3Ryb25nPgoK ICAgT25lIHBvdGVudGlhbCBzZWN1cml0eSBpc3N1ZSBpcyB0aGUgdHJhbnNwb3J0IG9mIGRhdGEg ZnJvbSBub24tCiAgIE5FVENPTkYgc3RyZWFtcywgc3VjaCBhcyBzeXNsb2cgYW5kIFNOTVAuICBU aGlzIGRhdGEgbWF5IGJlIG1vcmUKICAgdnVsbmVyYWJsZSAob3IgbGVzcyB2dWxuZXJhYmxlKSB3 aGVuIGJlaW5nIHRyYW5zcG9ydGVkIG92ZXIgTkVUQ09ORgogICB0aGFuIHdoZW4gYmVpbmcgdHJh bnNwb3J0ZWQgdXNpbmcgdGhlIHByb3RvY29sIG5vcm1hbGx5IHVzZWQgZm9yCiAgIHRyYW5zcG9y dGluZyBpdCwgZGVwZW5kaW5nIG9uIHRoZSBzZWN1cml0eSBjcmVkZW50aWFscyBvZiB0aGUgdHdv CiAgIHN1YnN5c3RlbXMuICBUaGUgTkVUQ09ORiBzZXJ2ZXIgaXMgcmVzcG9uc2libGUgZm9yIGFw cGx5aW5nIGFjY2VzcwogICBjb250cm9sIHRvIHN0cmVhbSBjb250ZW50LgoKICAgVGhlIGNvbnRl bnRzIG9mIG5vdGlmaWNhdGlvbnMgYXMgd2VsbCBhcyB0aGUgbmFtZSBvZiBldmVudCBzdHJlYW1z CiAgIG1heSBjb250YWluIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBhbmQgY2FyZSBzaG91bGQgYmUg dGFrZW4gdG8gZW5zdXJlCiAgIHRoYXQgaXQgaXMgdmlld2VkIG9ubHkgYnkgYXV0aG9yaXplZCB1 c2Vycy4gIElmIGEgdXNlciBkb2VzIG5vdCBoYXZlCiAgIHBlcm1pc3Npb24gdG8gdmlldyBjb250 ZW50IHZpYSBvdGhlciBORVRDT05GIG9wZXJhdGlvbnMsIDxzdHJpa2U+PGZvbnQgY29sb3I9J3Jl ZCc+aXQ8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJz5zaGU8L2Zv bnQ+PC9zdHJvbmc+IG11c3Qgbm90CiAgIGhhdmUgYWNjZXNzIDxzdHJvbmc+PGZvbnQgY29sb3I9 J2dyZWVuJz50bzwvZm9udD48L3N0cm9uZz4gdGhhdCBjb250ZW50IHZpYSBOb3RpZmljYXRpb25z LiAgSWYgYSB1c2VyIGlzIG5vdAogICBwZXJtaXR0ZWQgdG8gdmlldyBvbmUgZWxlbWVudCBpbiB0 aGUgY29udGVudCBvZiB0aGUgbm90aWZpY2F0aW9uLCB0aGUKICAgbm90aWZpY2F0aW9uIGlzIG5v dCBzZW50IHRvIHRoYXQgdXNlci4KCiAgIElmIGEgc3Vic2NyaXB0aW9uIGlzIGNyZWF0ZWQgd2l0 aCBhICZsdDtzdG9wVGltZSZndDssIHRoZSBORVRDT05GIHNlc3Npb24KICAgd2lsbCByZXR1cm4g dG8gYmVpbmcgYSBub3JtYWwgY29tbWFuZC1yZXNwb25zZSBORVRDT05GIHNlc3Npb24gd2hlbgog ICB0aGUgcmVwbGF5IGlzIGNvbXBsZXRlZC4gIEl0IGlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiB0 aGUgTkVUQ09ORgogICBjbGllbnQgdG8gY2xvc2UgdGhpcyBzZXNzaW9uIHdoZW4gaXQgaXMgbm8g bG9uZ2VyIG9mIHVzZS4KCjguICBJQU5BIENvbnNpZGVyYXRpb25zCgogICAtLSBFZGl0b3Igbm90 ZSB0byBJQU5BL1JGQy1FZGl0b3I6IHdlIHJlcXVlc3QgdGhhdCB5b3UgbWFrZSB0aGVzZQogICBh c3NpZ25tZW50cywgaW4gd2hpY2ggY2FzZSBpdCBpcyB0byBiZSBkb2N1bWVudGVkIGFzIGJlbG93 CgogICBUaGlzIGRvY3VtZW50IHJlZ2lzdGVycyB0aHJlZSBVUklzIGZvciB0aGUgTkVUQ09ORiBY TUwgbmFtZXNwYWNlIGluCiAgIHRoZSBJRVRGIFhNTCByZWdpc3RyeSBbUkZDMzY4OF0uCgogICBG b2xsb3dpbmcgdGhlIGZvcm1hdCBpbiBSRkMgMzY4OCwgSUFOQSBoYXMgbWFkZSB0aGUgZm9sbG93 aW5nCiAgIHJlZ2lzdHJhdGlvbi4gIE5vdGUgdGhhdCB0aGUgY2FwYWJpbGl0eSB1cm5zIGFzIGFs c28gY29tcGxpYW50IHRvCiAgIFtORVRDT05GXSBzZWN0aW9uIDEwLjMuCgogICArLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsKICAgfCBJbmRleCAgICAgICAgICAgICAgfCBDYXBhYmlsaXR5IElkZW50aWZpZXIgICAgICAg ICAgICAgICAgICAgICAgICB8CiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogICB8IDpub3RpZmljYXRpb24gICAg ICB8IHVybjppZXRmOnBhcmFtczpuZXRjb25mOmNhcGFiaWxpdHk6ICAgICAgICAgIHwKICAgfCAg ICAgICAgICAgICAgICAgICAgfCBub3RpZmljYXRpb246MS4wICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8CiAgIHwgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfAogICB8IDppbnRlcmxlYXZlICAgICAgICB8IHVybjpp ZXRmOnBhcmFtczpuZXRjb25mOmNhcGFiaWxpdHk6ICAgICAgICAgIHwKICAgfCAgICAgICAgICAg ICAgICAgICAgfCBpbnRlcmxlYXZlOjEuMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 CiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKwoKICAgVVJJOiB1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldG1vZDpu b3RpZmljYXRpb24KCiAgIFVSSTogdXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOm5vdGlm aWNhdGlvbjoxLjAKCiAgIFJlZ2lzdHJhbnQgQ29udGFjdDogVGhlIElFU0cuCgogICBYTUw6IE4v QSwgdGhlIHJlcXVlc3RlZCBVUkkgaXMgYW4gWE1MIG5hbWVzcGFjZS4KCiAgIEluIGFkZGl0aW9u LCBJQU5BIHJlZ2lzdGVyZWQgdGhlIGZvbGxvd2luZyBYTUwgU2NoZW1hLCB0aGUgZGVmaW5pdGlv bgogICBvZiB3aGljaCBjYW4gYmUgZm91bmQgaW4gU2VjdGlvbiA0OgogICBodHRwOi8vd3d3Lmlh bmEub3JnL2Fzc2lnbm1lbnRzL3htbC1yZWdpc3RyeS9zY2hlbWEvbm90aWZpY2F0aW9uLnhzZAoK OS4gIEFja25vd2xlZGdlbWVudHMKCiAgIFRoYW5rcyB0byBHaWxiZXJ0IEdhZ25vbiwgR3JlZyBX aWxidXIgYW5kIEtpbSBDdXJyYW4gZm9yIHByb3ZpZGluZwogICB0aGVpciBpbnB1dCBpbnRvIHRo ZSBlYXJseSB3b3JrIG9uIHRoaXMgZG9jdW1lbnQuICBJbiBhZGRpdGlvbiwgdGhlCiAgIGVkaXRv cnMgd291bGQgbGlrZSB0byBhY2tub3dsZWRnZSBpbnB1dCBhdCB0aGUgVmFuY291dmVyIGVkaXRp bmcKICAgc2Vzc2lvbiBmcm9tIHRoZSBmb2xsb3dpbmcgcGVvcGxlOiBPcmx5IE5pY2tsYXNzLCBK YW1lcyBCYWxlc3RyaWVyZSwKICAgWW9zaGlmdW1pIEF0YXJhc2hpLCBHbGVubiBXYXRlcnMsIEFs ZXhhbmRlciBDbGVtbSwgRGF2ZSBIYXJyaW5ndG9uLAogICBEYXZlIFBhcnRhaW4sIFJheSBBdGFy YXNoaSBhbmQgRGF2aWQgUGVya2lucyBhbmQgdGhlIGZvbGxvd2luZwogICBhZGRpdGlvbmFsIHBl b3BsZSBmcm9tIHRoZSBNb250cmVhbCBlZGl0aW5nIHNlc3Npb246IEJhbGF6cyBMZW5neWVsLAog ICBQaGlsIFNoYWZlciwgUm9iIEVubnMsIEFuZHkgQmllcm1hbiwgRGFuIFJvbWFzY2FudSwgQmVy dCBXaWpuZW4sCiAgIFNpbW9uIExlaW5lbiwgSnVlcmdlbiBTY2hvZW53YWVsZGVyLCBIaWRla2kg T2tpdGEsIFZpbmNlbnQgQ3JpZGxpZywKICAgTWFydGluIEJqb3JrbHVuZCwgT2xpdmllciBGZXN0 b3IsIFJhZHUgU3RhdGUsIEJyaWFuIFRyYW1tZWxsLCBXaWxsaWFtCiAgIENob3cuICBXZSB3b3Vs ZCBhbHNvIGxpa2UgdG8gdGhhbmsgTGkgWWFuIGZvciBoaXMgbnVtZXJvdXMgcmV2aWV3cyBhcwog ICB3ZWxsIGFzIFN1cmVzaCBLcmlzaG5hbiBmb3IgaGlzIGdlbi1hcnQgcmV2aWV3IG9mIHRoZSBk b2N1bWVudC4KCjEwLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIDxzdHJvbmc+PGZvbnQgY29s b3I9J2dyZWVuJz5bSVNPLjg2MDEuMTk4OF0KICAgICAgICAgICAgICBJbnRlcm5hdGlvbmFsIE9y Z2FuaXphdGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCAiRGF0YQogICAgICAgICAgICAgIGVsZW1l bnRzIGFuZCBpbnRlcmNoYW5nZSBmb3JtYXRzIC0gSW5mb3JtYXRpb24gaW50ZXJjaGFuZ2UKICAg ICAgICAgICAgICAtIFJlcHJlc2VudGF0aW9uIG9mIGRhdGVzIGFuZCB0aW1lcyIsIElTTyBTdGFu ZGFyZCA4NjAxLAogICAgICAgICAgICAgIEp1bmUgMTk4OC48L2ZvbnQ+PC9zdHJvbmc+CgogICBb TkVUQ09ORl0gIEVubnMsIFIuLCAiTkVUQ09ORiBDb25maWd1cmF0aW9uIFByb3RvY29sIiwgUkZD IDQ3NDEsCiAgICAgICAgICAgICAgRGVjZW1iZXIgMjAwNi4KCiAgIFtSRkMyMTE5XSAgQnJhZG5l ciwgcy4sICJLZXkgd29yZHMgZm9yIFJGQ3MgdG8gSW5kaWNhdGUgUmVxdWlyZW1lbnRzCiAgICAg ICAgICAgICAgTGV2ZWxzIiwgUkZDIDIxMTksIE1hcmNoIDE5OTcuCgogICA8c3Ryb25nPjxmb250 IGNvbG9yPSdncmVlbic+W1JGQzMzMzldICBLbHluZSwgRy4sIEVkLiBhbmQgQy4gTmV3bWFuLCAi RGF0ZSBhbmQgVGltZSBvbiB0aGUKICAgICAgICAgICAgICBJbnRlcm5ldDogVGltZXN0YW1wcyIs IFJGQyAzMzM5LCBKdWx5IDIwMDIuPC9mb250Pjwvc3Ryb25nPgoKICAgW1JGQzM2ODhdICBCcmFk bmVyLCBzLiwgIlRoZSBJRVRGIFhNTCBSZWdpc3RyeSIsIFJGQyAzNjg4LCBKYW51YXJ5CiAgICAg ICAgICAgICAgIDIwMDQuCgogICBbWE1MXSAgICAgIFdvcmxkIFdpZGUgV2ViIENvbnNvcnRpdW0s ICJFeHRlbnNpYmxlIE1hcmt1cCBMYW5ndWFnZQogICAgICAgICAgICAgIChYTUwpIDEuMCIsIFcz QyBYTUwsIEZlYnJ1YXJ5IDE5OTgsCiAgICAgICAgICAgICAgJmx0O2h0dHA6Ly93d3cudzMub3Jn L1RSLzE5OTgvUkVDLXhtbC0xOTk4MDIxMCZndDsuCgogICBbWE1MIFNjaGVtYV0KICAgICAgICAg ICAgICBUaG9tcHNvbiwgSC4sIEJlZWNoLCBELiwgTWFsb25leSwgTS4sIGFuZCBOLiBNZW5kZWxz b2huLAogICAgICAgICAgICAgICJYTUwgU2NoZW1hIFBhcnQgMTogU3RydWN0dXJlcyBTZWNvbmQg RWRpdGlvbiIsIFczQyBodHRwOi8KICAgICAgICAgICAgICAvd3d3LnczLm9yZy9UUi8yMDA0L1JF Qy14bWxzY2hlbWEtMS0yMDA0MTAyOC8KICAgICAgICAgICAgICBzdHJ1Y3R1cmVzLmh0bWwsIE9j dG9iZXIgMjAwNC4KCiAgIFtYUEFUSF0gICAgQ2xhcmssIEouIGFuZCBTLiBEZVJvc2UsICJYTUwg UGF0aCBMYW5ndWFnZSAoWFBhdGgpCiAgICAgICAgICAgICAgVmVyc2lvbiAxLjAiLAogICAgICAg ICAgICAgIFczQyBodHRwOi8vd3d3LnczLm9yZy9UUi8xOTk5L1JFQy14cGF0aC0xOTk5MTExNiwK ICAgICAgICAgICAgICBOb3ZlbWJlciAxOTk5LgoKQXBwZW5kaXggQS4gIENoYW5nZSBMb2cKCiAg IC0tIEVkaXRvciBub3RlIHRvIFJGQy1FZGl0b3I6IHdlIHJlcXVlc3QgdGhhdCB5b3UgcmVtb3Zl IHRoaXMgc2VjdGlvbgogICBiZWZvcmUgcHVibGlzaGluZy4KCkEuMS4gIFZlcnNpb24gLTA4Cgog ICAxLiAgIFJlbW92ZWQgbmFtZWQgcHJvZmlsZXMKCiAgIDIuICAgUmVtb3ZlZCBldmVudENsYXNz IHRoYXQgd2FzIGFjY2lkZW50YWxseSBpbmNsdWRlZCBpbiB0aGUKICAgICAgICBkZWZpbml0aW9u IG9mIHRoZSByZXBsYXlDb21wbGV0ZSBub3RpZmljYXRpb24KCiAgIDMuICAgRGVsZXRlZCBkYXRh IHdyYXBwZXIgZnJvbSBub3RpZmljYXRpb24KCiAgIDQuICAgQ2hhbmdlZCByZXBsYXlMb2dTdGFy dFRpbWUgdG8gaGF2ZSBhIG1pbk9jY3VycyBvZiAwLiAgSXQgd2lsbAogICAgICAgIG9ubHkgYmUg dGhlcmUgd2hlbiByZXBsYXkgaXMgc3VwcG9ydGVkLiAgVmVyaWZ5IGV4YW1wbGVzIGluCiAgICAg ICAgc2VjdGlvbiAzLjIuNS4xIGFyZSBjb3JyZWN0IHdpdGggcmVzcGVjdCB0byB0aGlzIGVsZW1l bnQuCgogICA1LiAgIEVycm9yIGNvZGVzIGluIHNlY3Rpb24gMi4xLjEsIGZpeGVkIGZvcm1hdHRp bmcgaXNzdWUKCiAgIDYuICAgTW92ZWQgcmVwbGF5Q29tcGxldGUgdG8gbm90IGJlIHVuZGVyICZs dDtuZXRjb25mJmd0OwoKICAgNy4gICBTZWN0aW9uIDIuMSwgZml4ZWQgY2FwaXRhbGl6YXRpb24K CiAgIDguICAgSW4gZmlndXJlIDQsIHRoZSBsaW5lIHdhcyBwdXNoZWQgb3V0IGJ5ICdzeXN0ZW0g Y29tcG9uZW50cycsCiAgICAgICAgZml4ZWQgdGhpcy4KCiAgIDkuICAgT24gcGFnZSA4LCByZXBs YWNlZCAiSWYgdGhlIHN0YXJ0VGltZSBzcGVjaWZpZWQgaXMgZWFybGllciB0aGVuCiAgICAgICAg dGhlIiB3aXRoICdJZiB0aGUgc3RhcnRUaW1lIHNwZWNpZmllZCBpcyBlYXJsaWVyIHRoYW4gdGhl IgoKICAgMTAuICBVcGRhdGVkIHNvbWUgbmFtZSBzcGFjZXMgYW5kIHNjaGVtYUxvY2F0aW9ucyBh cyBwZXIgQW5keSdzIEp1bmUKICAgICAgICAzcmQgZW1haWwuCgogICAxMS4gIEFkZGVkIGRpc2N1 c3Npb24gb2YgcmVwbGF5TG9nU3RhcnRUaW1lIHRvIGRyYWZ0IGluIHNlY3Rpb24gMy4zLjEKICAg ICAgICBhcyBmb2xsb3dzICJXaGV0aGVyIG9yIG5vdCBhIHN0cmVhbSBzdXBwb3J0cyByZXBsYXkg Y2FuIGJlCiAgICAgICAgZGlzY292ZXJlZCBieSBkb2luZyBhICZsdDtnZXQmZ3Q7IG9wZXJhdGlv biBvbiB0aGUgJmx0O3N0cmVhbXMmZ3Q7IGVsZW1lbnRzCiAgICAgICAgb2YgdGhlIE5vdGlmaWNh dGlvbiBNYW5hZ2VtZW50IFNjaGVtYS4gIFRoaXMgc2NoZW1hIGFsc28KICAgICAgICBwcm92aWRl cyB0aGUgcmVwbGF5TG9nU3RhcnRUaW1lIGVsZW1lbnQgdG8gaW5kaWNhdGUgdGhlIGVhcmxpZXN0 CiAgICAgICAgYXZhaWxhYmxlIGxvZ2dlZCBub3RpZmljYXRpb24uIgoKICAgMTIuICBSZW1vdmVk IG1vc3Qgb2YgdGhlIHVzZXMgb2YgdGhlIHBocmFzZSAnTm90ZSB0aGF0Jy4gIEkga2VwdCB0d28K ICAgICAgICB1c2VzIHRoYXQgcHJldmVudCBzZW50ZW5jZXMgZnJvbSBzdGFydGluZyB3aXRoIGVp dGhlciBhIGxvd2VyCiAgICAgICAgY2FzZSBsZXR0ZXIgb3IgYW4gYW5nbGUgYnJhY2tldC4KCiAg IDEzLiAgSW4gc2VjdGlvbiAzLjYgcmVwbGFjZWQgIml0IHdpbGwgYmUgZmlsdGVyZWQgb3V0IiB3 aXRoICJ0aGUKICAgICAgICBub3RpZmljYXRpb24gd2lsbCBiZSBmaWx0ZXJlZCBvdXQiCiAgIDE0 LiAgSW4gc2VjdGlvbiAzLjQsIHJlcGxhY2VkICJhbmQgdGhlIHF1ZXJ5IiB3aXRoICJhbmQgdG8g cXVlcnkiCgogICAxNS4gIFJlcGxhY2VkIDMgaW5zdGFuY2VzIG9mICJyZXBsYXkgY29tcGxldGUg bm90aWZpY2F0aW9uIiB3aXRoCiAgICAgICAgInJlcGxheUNvbXBsZXRlIG5vdGlmaWNhdGlvbiIK CiAgIDE2LiAgSW4gc2VjdGlvbiAzLjMuMiwgcmVwbGFjZWQgIm5vcm1hbCBORVRDT05GIHNlc3Np b24iIHdpdGggIm5vcm1hbAogICAgICAgIGNvbW1hbmQtcmVzcG9uc2UgTkVUQ09ORiBzZXNzaW9u IgoKICAgMTcuICBJbiBzZWN0aW9uIDMuMy4xLCByZXBsYWNlZCAiY3JlYXRlIGFuIGV2ZW50IHN1 YnNjcmlwdGlvbiB0aGF0CiAgICAgICAgd2lsbCByZXNlbmQgcmVjZW50bHkgZ2VuZXJhdGVkIG5v dGlmaWNhdGlvbiIgd2l0aCAiY3JlYXRlIGFuCiAgICAgICAgZXZlbnQgc3Vic2NyaXB0aW9uIHRo YXQgd2lsbCByZXNlbmQgcmVjZW50bHkgZ2VuZXJhdGVkCiAgICAgICAgbm90aWZpY2F0aW9uLCBv ciBpcyBzb21lIGNhc2VzIHNlbmQgdGhlbSBmb3IgdGhlIGZpcnN0IHRpbWUgdG8gYQogICAgICAg IHBhcnRpY3VsYXIgTkVUQ09ORiBjbGllbnQuIgoKICAgMTguICBJbiBzZWN0aW9uIDMuMi41LjIs IHMvYXZhaWxhYmxlIGV2ZW50IHN0cmVhbXMgdG8vZXZlbnQgc3RyZWFtcwogICAgICAgIGF2YWls YWJsZSB0by8KCiAgIDE5LiAgSW4gb25lIHNwb3QsIGNoYW5nZWQgc25tcCB0byBTTk1QICh0aGUg b3RoZXIgZ2V0cyBkZWxldGVkKQoKICAgMjAuICBJbiBzZWN0aW9uIDMuMi41LjEgcy93aGVyZSAm bHQ7bmFtZSZndDsgZWxlbWVudCBpcy93aGVyZSB0aGUgJmx0O25hbWUmZ3Q7CiAgICAgICAgZWxl bWVudCBpcy8KCiAgIDIxLiAgSW4gc2VjdGlvbiAzLjIuNS4xLCBjbGFyaWZpZWQgdGhhdCAidmFs dWUgaXMgdW5pcXVlIiAtIHdpdGhpbgogICAgICAgIHRoZSBzY29wZSBvZiBhIE5FVENPTkYgc2Vy dmVyLgoKICAgMjIuICBJbiBzZWN0aW9uIDIuMS4xLCBjbGFyaWZpZWQgdGhhdCBzdG9wVGltZSBj YW5ub3QgcHJlY2VkZWQgc3RhcnQKICAgICAgICB0aW1lLgoKICAgMjMuICBJbiBzZWN0aW9uIDIu MS4xLCBpbiBTdGFydCBUaW1lIHMvaW5kaWNhdGVzL2luZGljYXRlLwoKICAgMjQuICBJbiBzZWN0 aW9uIDIuMS4xLCBpbiBGaWx0ZXI6IHMvVGhpcyBpcyBtdXR1YWxseSBleGNsdXNpdmUvVGhlCiAg ICAgICAgZmlsdGVyIHBhcmFtZXRlciBpcyBtdXR1YWxseSBleGNsdXNpdmUvICgidGhpcyIgY291 bGQgcmVmZXIgdG8KICAgICAgICB0aGUgYmVoYXZpb3VyIGRlc2NyaWJlZCBpbiB0aGUgcHJldmlv dXMgc2VudGVuY2UuKQoKICAgMjUuICBJbiBzZWN0aW9uIDEuNCwgdGhpcmQgYnVsbGV0LCByZXBs YWNlZCAic3lzbG9nIGFuZCBTTk1QIGFyZQogICAgICAgIHJhdGhlciBjb25zdHJhaW5lZCBpbiB0 ZXJtcyBvZiBtZXNzYWdlIHNpemVzKSIgd2l0aCAoaWUsIG5vdCB0b28KICAgICAgICBzaG9ydCkK CiAgIDI2LiAgSW4gc2VjdGlvbiAxLjQsIG1hZGUgYWxsIGJ1bGxldHMgc3RhcnQgd2l0aCBjYXBp dGFsIGxldHRlcnMuCgogICAyNy4gIEFkZGVkIGRlZmluaXRpb24gb2YgRmlsdGVyIHRvIHNlY3Rp b24gMS4xCgogICAyOC4gIEluIHNlY3Rpb24gMS4xLCBpbXByb3ZlZCB0aGUgZGVmaW5pdGlvbiBv ZiBzdWJzY3JpcHRpb24gd2l0aCAiQW4KICAgICAgICBhZ3JlZW1lbnQgYW5kIG1ldGhvZCB0byBy ZWNlaXZlIGV2ZW50IG5vdGlmaWNhdGlvbnMgb3ZlciBhCiAgICAgICAgTkVUQ09ORiBzZXNzaW9u LiIKCiAgIDI5LiAgSW4gc2VjdGlvbiAxLjEsIGluIHRoZSBkZWZpbml0aW9uIG9mIG9wZXJhdGlv biwgYWRkZWQgYQogICAgICAgIHJlZmVyZW5jZSB0byBbTkVUQ09ORl0uCgogICAzMC4gIENyZWF0 ZWQgYSBjaGFuZ2UgbG9nIHNlY3Rpb24KCiAgIDMxLiAgRml4ZWQgcmVmZXJlbmNlIHRvIElFVEYg WE1MIFJlZ2lzdHJ5IGluIElBTkEgQ29uc2lkZXJhdGlvbnMKICAgICAgICBzZWN0aW9uLgoKICAg MzIuICBJbiBzZWN0aW9uIDMuMy4zLCBkZWxldGVkICJUaGlzIG5vdGlmaWNhdGlvbiB3aWxsIG9u bHkgYmUgc2VudAogICAgICAgIGlmIGEgJ3N0b3BUaW1lJyB3YXMgc3BlY2lmaWVkIHdoZW4gdGhl IHJlcGxheSBzdWJzY3JpcHRpb24gd2FzCiAgICAgICAgY3JlYXRlZC4iCgogICAzMy4gIEFkZGVk IHRleHQgdG8gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gdGhhdCBzYXlzICJJ ZgogICAgICAgIGEgc3Vic2NyaXB0aW9uIGlzIGNyZWF0ZWQgd2l0aCBhIHN0b3BUaW1lLCB0aGUg TkVUQ09ORiBzZXNzaW9uCiAgICAgICAgd2lsbCByZXR1cm4gdG8gYmVpbmcgYSBub3JtYWwgY29t bWFuZC1yZXNwb25zZSBORVRDT05GIHNlc3Npb24KICAgICAgICB3aGVuIHRoZSByZXBsYXkgaXMg Y29tcGxldGVkLiAgSXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZQogICAgICAgIE5FVENP TkYgY2xpZW50IHRvIGNsb3NlIG9mZiB0aGlzIHNlc3Npb24gd2hlbiBpdCBpcyBubyBsb25nZXIg b2YKICAgICAgICB1c2UiLgoKICAgMzQuICBVcGRhdGUgZXhhbXBsZXMgaW4gc2VjdGlvbiA1IHRv IGdldCByaWQgb2YgZXh0cmEgd3JhcHBlciB0YWcuCgogICAzNS4gIEluIHNlY3Rpb24gMi4xLCBy ZXBsYWNlICJBIE5FVENPTkYgc2VydmVyIGlzIG5vdCByZXF1aXJlZCB0bwogICAgICAgIHByb2Nl c3MgUlBDIHJlcXVlc3RzIG9uIHRoZSBzZXNzaW9uIGFzc29jaWF0ZWQgd2l0aCB0aGUKICAgICAg ICBzdWJzY3JpcHRpb24gdW50aWwgdGhlIG5vdGlmaWNhdGlvbiBzdWJzY3JpcHRpb24gaXMgZG9u ZSBhbmQgbWF5CiAgICAgICAgc2lsZW50bHkgZGlzY2FyZCB0aGVzZSByZXF1ZXN0cy4iIHdpdGgg IkEgTkVUQ09ORiBzZXJ2ZXIgaXMgd2lsbAogICAgICAgIG5vdCByZWFkIFJQQyByZXF1ZXN0cywg YnkgZGVmYXVsdCwgb24gdGhlIHNlc3Npb24gYXNzb2NpYXRlZAogICAgICAgIHdpdGggdGhlIHN1 YnNjcmlwdGlvbiB1bnRpbCB0aGUgbm90aWZpY2F0aW9uIHN1YnNjcmlwdGlvbiBpcwogICAgICAg IGRvbmUuCgogICAzNi4gIFVwZGF0ZWQgdGhlIG5vdGlmaWNhdGlvbiBkZWZpbml0aW9uIGFuZCB0 aGUgcmVwbHlDb21wbGV0ZQogICAgICAgIG5vdGlmaWNhdGlvbiBkZWZpbml0aW9uIHRvIHVzZSBh IHN1YnN0aXR1dGlvbiBncm91cC4KCkEuMi4gIFZlcnNpb24gLTA5CgogICAxLiAgIEluIHNlY3Rp b24gNS4xICJsb2dpY2FsIE9SIG9wZXJhdGlvbiIgLSZndDsgImFwcGxpY2F0aW9uIG9mIHRoZQog ICAgICAgIGxvZ2ljYWwgT1Igb3BlcmF0b3IiCgogICAyLiAgIEluIHNlY3Rpb24gNiAiZW5zdXJl IHRoZSBzZWN1cmUgb3BlcmF0aW9uIG9mIHRoZSBmb2xsb3dpbmcKICAgICAgICBjb21tYW5kcyIg LSZndDsgInNlY3VyZSBleGVjdXRpb24iCgogICAzLiAgIFJlbW92ZWQgYSBjb3VwbGUgcmVtYWlu aW5nIHJlZmVyZW5jZXMgdG8gbmFtZWQgcHJvZmlsZXMuCgogICA0LiAgIFVwZGF0ZWQgbmFtZSBk YXRhdHlwZSBpbiBldmVudFN0cmVhbXMgZWxlbWVudC4KCiAgIDUuICAgTW9kaWZpZWQgdGhlIGNh cmRpbmFsaXR5IG9mIGV2ZW50U3RyZWFtcyB0byByZWZsZWN0IHRoYXQgdGhlcmUKICAgICAgICB3 aWxsIGFsd2F5cyBiZSBhdCBsZWFzdCBvbmUgZXZlbnQgc3RyZWFtLgoKICAgNi4gICBGaXhlZCBk ZXNjcmlwdGlvbiBvZiBleGFtcGxlcyB0byByZW1vdmUgcmVmZXJlbmNlIHRvIGV2ZW50RW50cnks CiAgICAgICAgd2hpY2ggaXMgbm8gbG9uZ2VyIHBhcnQgb2YgdGhlIGFjdHVhbCBleGFtcGxlLgoK ICAgNy4gICBJbiBleGFtcGxlcywgZm9yIGNvbnNpc3RlbmN5IGNoYW5nZWQgc29tZSByZWZlcmVu Y2VzIHRvCiAgICAgICAgcmVwb3J0aW5nRWxlbWVudCB0byBiZSByZXBvcnRpbmdFbnRpdHkKCiAg IDguICAgRml4ZWQgc2VjdGlvbiAzLjIsIHRoaXJkIHBhcmFncmFwaCB0byB0YWxrIGFib3V0IGZp bHRlciBlbGVtZW50cwogICAgICAgIGluc3RlYWQgb2YgZmlsdGVycy4KCiAgIDkuICAgTWVyZ2Ug c2VjdGlvbiAzLjMuMiBhbmQgc2VjdGlvbiAzLjMuMy4gIERlbGV0ZSB0aGUgZmlyc3QKICAgICAg ICBwYXJhZ3JhcGggaW4gKG9sZCkgc2VjdGlvbiAzLjMuMyBzaW5jZSBpdCBib3RoIGR1cGxpY2F0 ZXMgYW5kCiAgICAgICAgY29udHJhZGljdHMgdGV4dCBpbiBzZWN0aW9uIDMuMy4yCgogICAxMC4g IEluIHNlY3Rpb24gMy4yLjUuMi4xLCBhZGRlZCBjbGFyaWZpY2F0aW9uIHRvIGZpcnN0IHBhcmFn cmFwaAogICAgICAgIHRoYXQgIkVpdGhlciBzdWJ0cmVlIG9yIFhQQVRIIGZpbHRlcmluZyBjYW4g YmUgdXNlZC4gICIKCiAgIDExLiAgUmVtb3ZlZCBkaXNjdXNzaW9uIG9mIG5vdCBhbGxvd2luZyB0 aGUgcmV0dXJuIG9mIHN0cmVhbSBuYW1lcwogICAgICAgIGZvciB3aGljaCB0aGUgdXNlciBkb2Vz IG5vdCBoYXZlIHBlcm1pc3Npb25zIGZyb20gdGhlIGJvZHkgb2YKICAgICAgICB0aGUgZG9jdW1l bnQgdG8gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24uCgogICAxMi4gIEZpeGVk IHR5cG9zIGFuZCBkaWQgd29yZHNtaXRoaW5nIGluIHZhcmlvdXMgcGFydHMgb2YgdGhlCiAgICAg ICAgZG9jdW1lbnQuCgogICAxMy4gIEluIHNlY3Rpb24gMi4xLCBleHBsaWNpdGx5IHN0YXRlZCB0 aGF0IGEgc3Vic2NyaXB0aW9uIGlzIGJvdW5kCiAgICAgICAgdG8gYSBzaW5nbGUgc3RyZWFtIGZv ciB0aGUgbGlmZXRpbWUgb2YgdGhlIHN1YnNjcmlwdGlvbi4KCiAgIDE0LiAgcmVtb3ZlZCBzaW5n bGUgcXVvdGVzIGFyb3VuZCBzb21lIGluc3RhbmNlcyBvZiBzdG9wVGltZSBhbmQKICAgICAgICBz dGFydFRpbWUgZm9yIGNvbnNpc3RlbmN5LiAgV2hlbiBhcHByb3ByaWF0ZSwgcHV0IGJldHdlZW4g YW5nbGUKICAgICAgICBicmFja2V0cy4KCiAgIDE1LiAgSW4gc2VjdGlvbiAyLjEuMSwgY2hhbmdl ZCAiRXJyb3ItaW5mbzogJmx0O2JhZEVsZW1lbnQmZ3Q7OiBzdGFydFRpbWUiCiAgICAgICAgdG8g dXNlIGJhZC1lbGVtZW50LgoKICAgMTYuICBJbiBzZWN0aW9uIDIuMi4xLCB1bmRlciB0aGUgcGFy YW1ldGVyIHRhZywgcmVwbGFjZWQgIkNvbnRhaW5zCiAgICAgICAgbm90aWZpY2F0aW9uLXNwZWNp ZmljIHRhZ2dlZCBjb250ZW50LiIgd2l0aCAiQ29udGFpbnMKICAgICAgICBub3RpZmljYXRpb24t c3BlY2lmaWMgdGFnZ2VkIGNvbnRlbnQsIGlmIGFueS4gICIKCiAgIDE3LiAgQ2xhcmlmaWVkIHNv bWUgdGV4dCBpbiBzZWN0aW9uIDMuMiwgcGFyYWdyYXBoIDMgYXJvdW5kIHNlbmRpbmcKICAgICAg ICBvZiBmaWx0ZXJzIGZyb20gY2xpZW50IGFuZCB0aGUgZmlsdGVycyBsYXRlciBiZWluZyBhcHBs aWVkIHRvCiAgICAgICAgdGhlIG5vdGlmaWNhdGlvbnMuCgogICAxOC4gIEZpeGVkIHRhcmdldCBu YW1lc3BhY2UgaW4gc2VjdGlvbiA0LgoKICAgMTkuICBBZGRlZCBtaXNzaW5nIGxhbmcgYW5kIHZl cnNpb24gaW5mb3JtYXRpb24gdG8gc2NoZW1hIGluIHNlY3Rpb24KICAgICAgICAzLjQKCiAgIDIw LiAgQ2xhcmlmaWVkIHRoYXQgdGhlIGV4YW1wbGVzIGluIHNlY3Rpb24gNSBhbGwgdXNlZCB0aGUg c2FtZQogICAgICAgIGV4YW1wbGUgZXZlbnQgbGlzdC4KCiAgIDIxLiAgQ2xlYW5lZCB1cCBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLgoKICAgMjIuICBJbiBzZWN0aW9uIDMuNCwgY2xh cmlmaWVkIHRoZSBkZWZpbml0aW9uIG9mIHJlcGxheUxvZ1N0YXJ0IHRpbWUKICAgICAgICB0byBi ZSB0aGUgdGltZXN0YW1wIG9mIHRoZSBlYXJsaWVzdCBhdmFpbGFibGUgbm90aWZpY2F0aW9uIGlu CiAgICAgICAgdGhlIGxvZyB1c2VkIHRvIHN1cHBvcnQgdGhlIHJlcGxheSBmdW5jdGlvbiBpbiB0 aGUgZGVzY3JpcHRpb24KICAgICAgICB0YWcgZm9yIHRoZSBvYmplY3QgZGVmaW5pdGlvbi4KCiAg IDIzLiAgSW4gc2VjdGlvbiAzLjMuMiwgY2xhcmlmaWVkIHRoYXQgdGhlIHRpbWUgYW4gZXZlbnQg d2FzIGdlbmVyYXRlZAogICAgICAgIGJ5IHRoZSBzeXN0ZW0gbWVhbnMgdGltZSBhbiBldmVudCB3 YXMgZ2VuZXJhdGVkIGJ5IHRoZSBldmVudAogICAgICAgIHNvdXJjZS4KCiAgIDI0LiAgSW4gc2Vj dGlvbiAzLjUsIGRlbGV0ZWQgZGlzY3Vzc2lvbiBhYm91dCBwb3NzaWJseSBkZWZpbmluZwogICAg ICAgIHN1YnNjcmlwdGlvbnMgaW4gWE1MIFNjaGVtYS4KCiAgIDI1LiAgSW4gc2VjdGlvbiAzLjYs IGRlbGV0ZWQgZGlzY3Vzc2lvbiBhYm91dCBmaWx0ZXIgZWxlbWVudAogICAgICAgIGV4ZWN1dGlv biBvcmRlciBub3QgbWF0dGVyaW5nLgoKICAgMjYuICBGaXhlZCBleGFtcGxlcyBpbiBzZWN0aW9u IDUgdG8gYWRkICZsdDtuZXRjb25mJmd0OyB0YWcgYW5kIHRvIG1ha2UKICAgICAgICBvdGhlciBj b3JyZWN0aW9ucwoKICAgMjcuICBBZGRlZCBYTUwgU2NoZW1hIGRlZmluaXRpb24gZm9yIGV4YW1w bGVzIGluIHNlY3Rpb24gNSBhbmQgc2hvd2VkCiAgICAgICAgdGhlIGV2ZW50IGxpc3Qgd2l0aCAm bHQ7bm90aWZpY2F0aW9uJmd0OyB3cmFwcGVycy4KCiAgIDI4LiAgQWRkZWQgJmx0O25vdGlmaWNh dGlvbkNvbXBsZXRlJmd0OyBub3RpZmljYXRpb24KCiAgIDI5LiAgUmVtb3ZlZCBzdXBwb3J0IG9m IHN0YXJ0VGltZSBhbmQgc3RvcFRpbWUgaW4gdGhlIGZ1dHVyZS4KCiAgIDMwLiAgUmVwbGFjZWQg cmVwbGF5TG9nU3RhcnRUaW1lIHdpdGggcmVwbGF5TG9nQ3JlYXRpb25UaW1lIGFuZAogICAgICAg IHJlcGxheUxvZ0FnZWRUaW1lLgoKQS4zLiAgVmVyc2lvbiAtMTAKCiAgIDEuICBDaGFuZ2VkIHRo ZSBkZXNjcmlwdGlvbiBvZiBzdG9wVGltZSB0byBhbGxvdyBzdG9wVGltZXMgaW4gdGhlCiAgICAg ICBmdXR1cmUuCgogICAyLiAgQWRkZWQgaW50ZXJsZWF2ZSBjYXBhYmlsaXR5CgogICAzLiAgQ2xh cmlmaWVkIGNyZWF0ZS1zdWJzY3JpcHRpb24gZXJyb3IgbWVzc2FnZXMuCgogICA0LiAgQ29ycmVj dGVkIHRhcmdldE5hbWVzcGFjZSBpbiBOZXRjb25mIE5vdGlmaWNhdGlvbiBYU0QKCiAgIDUuICBG aXhlZCB0eXBvcyBhbmQgbWFkZSBtaW5vciBlZGl0cy4KCkEuNC4gIFZlcnNpb24gLTExCgogICAx LiAgRml4ZWQgbmFtZXNwYWNlcwoKICAgMi4gIEluIHNlY3Rpb24gNi41LCBmaXhlZCBlcnJvciBt ZXNzYWdlIEVycm9yLWluZm8KICAgMy4gIEluIHNlY3Rpb24gNi4xIGNsYXJpZnkgdGhhdCBpZiB0 aGUgaW50ZXJsZWF2ZSBjYXBhYmlsaXR5IGlzCiAgICAgICBzdXBwb3J0ZWQsIHRoZW4gdGhlIHNl cnZlciBtdXN0IHJlc3BvbmQgdG8gcmVxdWVzdHMuCgpBLjUuICA8c3RyaWtlPjxmb250IGNvbG9y PSdyZWQnPlZlc3Jpb248L2ZvbnQ+PC9zdHJpa2U+ICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVl bic+VmVyc2lvbjwvZm9udD48L3N0cm9uZz4gLTEyCgogICAxLiAgQWRkIHRvIHNlY3Rpb24gMS4z IHRoZSBjbGFyaWZpY2F0aW9uICJOb3RlIHRoYXQgYSBzdWJzY3JpcHRpb24KICAgICAgIGNhbm5v dCBiZSBtb2RpZmllZCBvbmNlIGNyZWF0ZWQuIgoKICAgMi4gIEluIHNlY3Rpb24gMi4yLjEsIGlu IHRoZSBkZXNjcmlwdGlvbiBvZiBldmVudFRpbWUsIGFkZGVkIHRoZQogICAgICAgZm9sbG93aW5n IHRleHQ6ICJUaGlzIHBhcmFtZXRlciBpcyBvZiB0eXBlIGRhdGVUaW1lLiIKCiAgIDMuICBGaXhl ZCBzZXZlcmFsIHR5cG9zLgoKICAgNC4gIEFkZGVkIHRoZSBmb2xsb3dpbmcgdGV4dCB0byB0aGUg SUFOQSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uOiAiLS0KICAgICAgIEVkaXRvciBub3RlIHRvIElB TkEvUkZDLUVkaXRvcjogd2UgcmVxdWVzdCB0aGF0IHlvdSBtYWtlIHRoZXNlCiAgICAgICBhc3Np Z25tZW50cywgaW4gd2hpY2ggY2FzZSBpdCBpcyB0b3AgYmUgZG9jdW1lbnRlZCBhcyBiZWxvdyIg IgoKICAgNS4gIFJlcGxhY2VkL1VwZGF0ZWQgWE1MIFNjaGVtYSByZWZlcmVuY2UgdG8gYmUgIiBb WE1MIFNjaGVtYV0KICAgICAgIFRob21wc29uLCBILiwgQmVlY2gsIEQuLCBNYWxvbmV5LCBNLiwg TWVuZGVsc29obiwgTi4sICJYTUwgU2NoZW1hCiAgICAgICBQYXJ0IDE6IFN0cnVjdHVyZXMgU2Vj b25kIEVkaXRpb24iLCBXM0MgUmVjb21tZW5kYXRpb24sIDI4CiAgICAgICBPY3RvYmVyIDIwMDQg Jmx0O2h0dHA6Ly93d3cudzMub3JnL1RSLzIwMDQvUkVDLXhtbHNjaGVtYS0xLTIwMDQxMDI4Lwog ICAgICAgc3RydWN0dXJlcy5odG1sJmd0OyAiCgogICA2LiAgQWRkIGluc3RydWN0aW9ucyB0byBS RkMgZWRpdG9yIHRvIHJlbW92ZSBjaGFuZ2UgbG9nIGJlZm9yZQogICAgICAgcHVibGljYXRpb24K CiAgIDcuICBBZGRlZCBJQU5BIHJlZ2lzdHJhdGlvbiBpdGVtIGZvciBodHRwOi8vd3d3LmlhbmEu b3JnL2Fzc2lnbm1lbnRzLwogICAgICAgeG1sLXJlZ2lzdHJ5L3NjaGVtYS9ub3RpZmljYXRpb24u eHNkCgogICA4LiAgQ2xhcmlmaWVkIGluIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24g dGhhdCB0aGUgY2FwYWJpbGl0eQogICAgICAgVVJJcyB3ZXJlIGNvbXBsYWludCB0byBSRkM0NzQx IHNlY3Rpb24gMTAuMwoKPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nPkEuNi4gIFZlcnNpb24g LTEzCgogICAxLiAgIEluIHNlY3Rpb24gMi4xLjEsIGZvciBib3RoIGluc3RhbmNlcyBhbmQgaW4g c2VjdGlvbiAyLjIuMSwKICAgICAgICByZXBsYWNlZCAiVGhpcyBwYXJhbWV0ZXIgaXMgb2YgdHlw ZSBkYXRlVGltZS4iICBXaXRoICJUaGlzCiAgICAgICAgcGFyYW1ldGVyIGlzIG9mIHR5cGUgZGF0 ZVRpbWUgYW5kIGNvbXBsaWFudCB0byBbUkZDMzMzOV0gYW5kCiAgICAgICAgW0lTTy44NjAxLjE5 ODhdLiIKCiAgIDIuICAgSW4gdGhlIG5vcm1hdGl2ZSByZWZlcmVuY2Ugc2VjdGlvbiwgYWRkZWQg dGhlIGZvbGxvd2luZyB0d28KICAgICAgICByZWZlcmVuY2VzIFtJU08uODYwMS4xOTg4XSBJbnRl cm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IKICAgICAgICBTdGFuZGFyZGl6YXRpb24sICJEYXRh IGVsZW1lbnRzIGFuZCBpbnRlcmNoYW5nZSBmb3JtYXRzIC0KICAgICAgICBJbmZvcm1hdGlvbiBp bnRlcmNoYW5nZSAtIFJlcHJlc2VudGF0aW9uIG9mIGRhdGVzIGFuZCB0aW1lcyIsCiAgICAgICAg SVNPIFN0YW5kYXJkIDg2MDEsIEp1bmUgMTk4OC4gIFtSRkMzMzM5XSBLbHluZSwgRy4sIEVkLiBh bmQgQy4KICAgICAgICBOZXdtYW4sICJEYXRlIGFuZCBUaW1lIG9uIHRoZSBJbnRlcm5ldDogVGlt ZXN0YW1wcyIsIFJGQyAzMzM5LAogICAgICAgIEp1bHkgMjAwMi4KCiAgIDMuICAgSW4gc2VjdGlv biAyLjEuMSwgZm9yIGJvdGggaW5zdGFuY2VzIGFuZCBpbiBzZWN0aW9uIDIuMi4xLCBhZGRlZAog ICAgICAgIHRoZSBmb2xsb3dpbmcgYWZ0ZXIgdGhlIHRleHQgaW5kaWNhdGluZyB0aGF0IHRoZSB0 aW1lIGZpZWxkcyBhcmUKICAgICAgICBkYXRlVGltZSAodGhpcyBjb3ZlcnMgZXZlbnRUaW1lLCBz dGFydFRpbWUgYW5kIHN0b3BUaW1lKS4KICAgICAgICAiSW1wbGVtZW50YXRpb25zIG11c3Qgc3Vw cG9ydCB0aW1lIHpvbmVzLiIKCiAgIDQuICAgSW4gU2VjdGlvbiAzLjYuMSAicGFyYW1ldGVyLiAg QSBGaWx0ZXIgb25seSBleGlzdCBhcyBhIHBhcmFtZXRlcgogICAgICAgIHRvIHRoZSBzdWJzY3Jp cHRpb24uIiBzL2V4aXN0L2V4aXN0cy8KCiAgIDUuICAgSW4gU2VjdGlvbiA3OiAidGhhdCBpdCBp cyB2aWV3ZWQgb25seSBieSBhdXRob3JpemVkIHVzZXJzLiAgSWYgYQogICAgICAgIHVzZXIgZG9l cyBub3QgaGF2ZSBwZXJtaXNzaW9uIHRvIHZpZXcgY29udGVudCB2aWEgb3RoZXIgTkVUQ09ORgog ICAgICAgIG9wZXJhdGlvbnMsIGl0IG11c3Qgbm90IGhhdmUgYWNjZXNzIHRoYXQgY29udGVudCB2 aWEKICAgICAgICBOb3RpZmljYXRpb25zLiIgcy9pdC9zaGUvIHMvYWNjZXNzIHRoYXQvYWNjZXNz IHRvIHRoYXQvCgogICA2LiAgIEluIHNlY3Rpb24gMy4zLjIsIHJlcGxhY2VkICJUaGUgTkVUQ09O RiBzZXJ2ZXIgd2lsbCB0aGVuIGFjY2VwdAogICAgICAgICZsdDtycGMmZ3Q7IG9wZXJhdGlvbnMu IiAgV2l0aCAiVGhlIE5FVENPTkYgc2VydmVyIHdpbGwgdGhlbiBhY2NlcHQKICAgICAgICAmbHQ7 cnBjJmd0OyBvcGVyYXRpb25zIGV2ZW4gaWYgdGhlIHNlcnZlciBkaWQgbm90IHByZXZpb3VzbHkg YWNjZXB0CiAgICAgICAgc3VjaCBvcGVyYXRpb25zIGR1ZSB0byBsYWNrIG9mIGludGVybGVhdmUg c3VwcG9ydC4iCgogICA3LiAgIEluIHNlY3Rpb24gMy4zLjIsIHJlcGxhY2VkICJBICZsdDtyZXBs YXlDb21wbGV0ZSZndDsgbm90aWZpY2F0aW9uIGlzCiAgICAgICAgc2VudCB0byBpbmRpY2F0ZSB0 aGF0IGFsbCBvZiB0aGUgcmVwbGF5IG5vdGlmaWNhdGlvbnMgaGF2ZSBiZWVuCiAgICAgICAgc2Vu dC4gIElmIHRoaXMgc3Vic2NyaXB0aW9uIGhhcyBhIHN0b3AgdGltZSwgdGhlbiB0aGlzIHNlc3Np b24KICAgICAgICBiZWNvbWVzIGEgbm9ybWFsIE5FVENPTkYgc2Vzc2lvbiBhZ2Fpbi4gIFdoZW4g YSAmbHQ7c3RvcFRpbWUmZ3Q7IGhhcwogICAgICAgIGJlZW4gc3BlY2lmaWVkLCAmbHQ7bm90aWZp Y2F0aW9uQ29tcGxldGUmZ3Q7IG5vdGlmaWNhdGlvbiBpcyB0aGUgbGFzdAogICAgICAgIG5vdGlm aWNhdGlvbiBzZW50IG9uIHRoZSBzdWJzY3JpcHRpb24gYmVmb3JlIGl0IHRlcm1pbmF0ZXMgYW5k CiAgICAgICAgdGhlIE5FVENPTkYgc2Vzc2lvbiByZXR1cm5zIHRvIGJlaW5nIGEgbm9ybWFsIE5F VENPTkYgc2Vzc2lvbi4iCiAgICAgICAgV2l0aCAiQSAmbHQ7cmVwbGF5Q29tcGxldGUmZ3Q7IG5v dGlmaWNhdGlvbiBpcyBzZW50IHRvIGluZGljYXRlIHRoYXQKICAgICAgICBhbGwgb2YgdGhlIHJl cGxheSBub3RpZmljYXRpb25zIGhhdmUgYmVlbiBzZW50LiAgV2hlbiBhCiAgICAgICAgJmx0O3N0 b3BUaW1lJmd0OyBoYXMgYmVlbiBzcGVjaWZpZWQsICZsdDtub3RpZmljYXRpb25Db21wbGV0ZSZn dDsKICAgICAgICBub3RpZmljYXRpb24gaXMgdGhlIGxhc3Qgbm90aWZpY2F0aW9uIHNlbnQgb24g dGhlIHN1YnNjcmlwdGlvbgogICAgICAgIGJlZm9yZSBpdCB0ZXJtaW5hdGVzIGFuZCB0aGUgTkVU Q09ORiBzZXNzaW9uIHJldHVybnMgdG8gYmVpbmcgYQogICAgICAgIG5vcm1hbCBORVRDT05GIHNl c3Npb24uICIKCiAgIDguICAgSW4gc2VjdGlvbiAzLjMuMiwgcmVwbGFjZWQsICJBICZsdDtyZXBs YXlDb21wbGV0ZSZndDsgbm90aWZpY2F0aW9uIGlzCiAgICAgICAgc2VudCB0byBpbmRpY2F0ZSB0 aGF0IGFsbCBvZiB0aGUgcmVwbGF5IG5vdGlmaWNhdGlvbnMgaGF2ZSBiZWVuCiAgICAgICAgc2Vu dC4iICBXaXRoICJBICZsdDtyZXBsYXlDb21wbGV0ZSZndDsgbm90aWZpY2F0aW9uIGlzIHNlbnQg dG8KICAgICAgICBpbmRpY2F0ZSB0aGF0IGFsbCBvZiB0aGUgcmVwbGF5IG5vdGlmaWNhdGlvbnMg aGF2ZSBiZWVuIHNlbnQgYW5kCiAgICAgICAgbXVzdCBub3QgYmUgc2VudCBmb3IgYW55IG90aGVy IHJlYXNvbi4iCgogICA5LiAgIEluIHNlY3Rpb24gMy4zLjEsIHJlcGxhY2VkICJBIG5vdGlmaWNh dGlvbiBzdHJlYW0gdGhhdCBzdXBwb3J0cwogICAgICAgIHJlcGxheSBpcyBub3QgZXhwZWN0ZWQg dG8gaGF2ZSBhbiB1bmxpbWl0ZWQgc3VwcGx5IG9mIHNhdmVkCiAgICAgICAgbm90aWZpY2F0aW9u cyBhdmFpbGFibGUgdG8gYWNjb21tb2RhdGUgYW55IHJlcGxheSByZXF1ZXN0LiIKICAgICAgICBX aXRoICJBIG5vdGlmaWNhdGlvbiBzdHJlYW0gdGhhdCBzdXBwb3J0cyByZXBsYXkgaXMgbm90IGV4 cGVjdGVkCiAgICAgICAgdG8gaGF2ZSBhbiB1bmxpbWl0ZWQgc3VwcGx5IG9mIHNhdmVkIG5vdGlm aWNhdGlvbnMgYXZhaWxhYmxlIHRvCiAgICAgICAgYWNjb21tb2RhdGUgYW55IHJlcGxheSByZXF1 ZXN0LiAgQ2xpZW50cyBjYW4gcXVlcnkKICAgICAgICAmbHQ7cmVwbGF5TG9nQ3JlYXRpb25UaW1l Jmd0OyBhbmQgJmx0O3JlcGxheUxvZ0FnZWRUaW1lJmd0OyB0byBsZWFybiBhYm91dAogICAgICAg IHRoZSBhdmFpbGFiaWxpdHkgb2Ygbm90aWZpY2F0aW9ucyBmb3IgcmVwbGF5LiIKICAgMTAuICBJ biBzZWN0aW9uIDMuMiwgcmVwbGFjZWQgIkZpZ3VyZSAyIGlsbHVzdHJhdGVzIHRoZSBub3RpZmlj YXRpb24KICAgICAgICBmbG93IGFuZCBjb25jZXB0cyBpZGVudGlmaWVkIGluIHRoaXMgZG9jdW1l bnQuIiAgV2l0aCAiRmlndXJlIDIKICAgICAgICBpbGx1c3RyYXRlcyB0aGUgbm90aWZpY2F0aW9u IGZsb3cgYW5kIGNvbmNlcHRzIGlkZW50aWZpZWQgaW4KICAgICAgICB0aGlzIGRvY3VtZW50LiAg SXQgZG9lcyBub3QgbWFuZGF0ZSBhbmQvb3IgcHJlY2x1ZGUgYW4KICAgICAgICBpbXBsZW1lbnRh dGlvbi4iCgogICAxMS4gIEluIHNlY3Rpb24gNi4xLCBhZGRlZCB0aGUgZm9sbG93aW5nIHRleHQg IlRoaXMgY2FwYWJpbGl0eSBoZWxwcwogICAgICAgIHNjYWxhYmlsaXR5IGJ5IHJlZHVjaW5nIHRo ZSB0b3RhbCBudW1iZXIgb2YgTkVUQ09ORiBzZXNzaW9ucwogICAgICAgIHJlcXVpcmVkIGJ5IGEg Z2l2ZW4gb3BlcmF0b3Igb3IgbWFuYWdlbWVudCBhcHBsaWNhdGlvbi4iCgogICAxMi4gIEluIHNl Y3Rpb24gMy42LCBkZWxldGVkICJXaGVuIG11bHRpcGxlIGZpbHRlciBlbGVtZW50cyBhcmUKICAg ICAgICBzcGVjaWZpZWQsIHRoZXkgYXJlIGFwcGxpZWQgY29sbGVjdGl2ZWx5LCBzbyBldmVudCBu b3RpZmljYXRpb25zCiAgICAgICAgbmVlZCB0byBwYXNzIGFsbCBzcGVjaWZpZWQgZmlsdGVyIGVs ZW1lbnRzIGluIG9yZGVyIHRvIGJlIHNlbnQKICAgICAgICB0byB0aGUgc3Vic2NyaWJlci4gIgoK ICAgMTMuICBJbiBzZWN0aW9uIDcgKFNlY3VyaXR5IENvbnNpZGVyYXRpb25zKSBhZnRlciB0aGUg YnVsbGV0cyBhZGRlZAogICAgICAgIHRoZSBmb2xsb3dpbmc6IFNlY3VyZSBleGVjdXRpb24gbWVh bnMgZW5zdXJpbmcgdGhhdCBhIHNlY3VyZQogICAgICAgIHRyYW5zcG9ydCBpcyB1c2VkIGFzIHdl bGwgYXMgZW5zdXJpbmcgdGhhdCB0aGUgdXNlciBoYXMKICAgICAgICBzdWZmaWNpZW50IGF1dGhv cml6YXRpb24gdG8gcGVyZm9ybSB0aGUgZnVuY3Rpb24gdGhleSBhcmUKICAgICAgICByZXF1ZXN0 aW5nIGFnYWluc3QgdGhlIHNwZWNpZmljIHBpZWNlIG9mIE5FVENPTkYgY29udGVudAogICAgICAg IGludm9sdmVkLiAgV2hlbiBhICZsdDtnZXQmZ3Q7IGlzIHJlY2VpdmVkIGFnYWluc3QgdGhlIGNv bnRlbnQgZGVmaW5lZAogICAgICAgIGluIHRoaXMgbWVtbywgY2xpZW50cyBzaG91bGQgb25seSBi ZSBhYmxlIHRvIHZpZXcgdGhlIGNvbnRlbnQKICAgICAgICBmb3Igd2hpY2ggdGhleSBoYXZlIHN1 ZmZpY2llbnQgcHJpdmlsZWdlcy4gIEEgY3JlYXRlICZsdDtjcmVhdGUtCiAgICAgICAgc3Vic2Ny aXB0aW9uJmd0OyBvcGVyYXRpb24gY2FuIGJlIGNvbnNpZGVyZWQgbGlrZSBhIGRlZmVycmVkICZs dDtnZXQmZ3Q7LAogICAgICAgIGFuZCB0aGUgY29udGVudCB0aGF0IGRpZmZlcmVudCB1c2VycyBj YW4gYWNjZXNzIG1heSB2YXJ5LiAgVGhpcwogICAgICAgIGRpZmZlcmVudCBhY2Nlc3MgaXMgcmVm bGVjdGVkIGluIHRoZSAmbHQ7bm90aWZpY2F0aW9uJmd0OyB0aGF0CiAgICAgICAgZGlmZmVyZW50 IHVzZXJzIGFyZSBhYmxlIHRvIHN1YnNjcmliZSB0by4KCiAgIDE0LiAgVXBkYXRlZCBpbXBvcnQg c3RhdGVtZW50cyB0byBub3QgdXNlZCBmdWxseSBxdWFsaWZpZWQgVVJMcy48L2ZvbnQ+PC9zdHJv bmc+CgpBdXRob3JzJyBBZGRyZXNzZXMKCiAgIFNoYXJvbiBDaGlzaG9sbQogICBOb3J0ZWwKICAg MzUwMCBDYXJsaW5nIEF2ZQogICBOZXBlYW4sIE9udGFyaW8gIEsySCA4RTkKICAgQ2FuYWRhCgog ICBFbWFpbDogc2NoaXNob2xAbm9ydGVsLmNvbQoKICAgSGVjdG9yIFRyZXZpbm8KICAgQ2lzY28K ICAgU3VpdGUgNDAwCiAgIDkxNTUgRS4gTmljaG9scyBBdmUKICAgRW5nbGV3b29kLCBDTyAgODAx MTIKICAgVVNBCgogICBFbWFpbDogaHRyZXZpbm9AY2lzY28uY29tCgpGdWxsIENvcHlyaWdodCBT dGF0ZW1lbnQKCiAgIENvcHlyaWdodCAoQykgVGhlIElFVEYgVHJ1c3QgKDIwMDgpLgoKICAgVGhp cyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmlj dGlvbnMKICAgY29udGFpbmVkIGluIEJDUCA3OCwgYW5kIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhl cmVpbiwgdGhlIGF1dGhvcnMKICAgcmV0YWluIGFsbCB0aGVpciByaWdodHMuCgogICBUaGlzIGRv Y3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQg b24gYW4KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFU SU9OIEhFL1NIRSBSRVBSRVNFTlRTCiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhF IElOVEVSTkVUIFNPQ0lFVFksIFRIRSBJRVRGIFRSVVNUIEFORAogICBUSEUgSU5URVJORVQgRU5H SU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUwogICBP UiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFU IFRIRSBVU0UgT0YKICAgVEhFIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBB TlkgUklHSFRTIE9SIEFOWSBJTVBMSUVECiAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZ IE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLgoKSW50ZWxsZWN0dWFsIFByb3Bl cnR5CgogICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5 IG9yIHNjb3BlIG9mIGFueQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVy IHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8KICAgcGVydGFpbiB0byB0aGUgaW1wbGVt ZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbgogICB0aGlzIGRv Y3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdo dHMKICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVz ZW50IHRoYXQgaXQgaGFzCiAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlm eSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbgogICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRo IHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlCiAgIGZvdW5kIGluIEJD UCA3OCBhbmQgQkNQIDc5LgoKICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRo ZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkKICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBi ZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbgogICBhdHRlbXB0IG1hZGUgdG8g b2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YKICAg c3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMK ICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQ UiByZXBvc2l0b3J5IGF0CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLgoKICAgVGhlIElFVEYg aW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFu eQogICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVy IHByb3ByaWV0YXJ5CiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5 IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudAogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJl c3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0CiAgIGlldGYtaXByQGlldGYub3JnLgoK QWNrbm93bGVkZ21lbnQKCiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlz IHByb3ZpZGVkIGJ5IHRoZSBJRVRGCiAgIEFkbWluaXN0cmF0aXZlIFN1cHBvcnQgQWN0aXZpdHkg KElBU0EpLgo8L3ByZT4KPC9ib2R5PjwvaHRtbD4K ------_=_NextPart_001_01C8A62E.7F0483AA Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------_=_NextPart_001_01C8A62E.7F0483AA-- From netconf-bounces@ietf.org Thu Apr 24 10:27:05 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93EB03A6B02; Thu, 24 Apr 2008 10:27:05 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C27F3A6C0C for ; Thu, 24 Apr 2008 10:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeTkScrKsoCf for ; Thu, 24 Apr 2008 10:26:50 -0700 (PDT) Received: from zrtps0kp.us.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 841C928C260 for ; Thu, 24 Apr 2008 10:26:25 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3OHQOu19854; Thu, 24 Apr 2008 17:26:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Apr 2008 13:26:15 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4143A22D5@zcarhxm2.corp.nortel.com> In-Reply-To: <019501c8a5b7$d76c0d00$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues Thread-Index: AcilcZR/jISHmqM8QyGNyxNHmQZSAAARDK6gAB5Yr7A= References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> <019501c8a5b7$d76c0d00$0600a8c0@china.huawei.com> From: "Sharon Chisholm" To: "David B Harrington" , Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Inline -----Original Message----- From: David B Harrington [mailto:dbharrington@comcast.net] Sent: Wednesday, April 23, 2008 11:04 PM To: Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org Subject: RE: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues Hi, > D. In Section 7: > >> that it is viewed only by authorized users. If a user does not > have > >> permission to view content via other NETCONF operations, it must > not > >> 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 or a configuration? 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. you might want to change "it" to "he/she", or "the user" There is an edit later on that does it. > G. In section 3.3.2 > Replace > A notification is sent to indicate that all of the > replay notifications have been sent. > With > A notification is sent to indicate that all of the > replay notifications have been sent and must not be sent for any > other reason. Is the replay cache session-specific? Could another session request a replay of the same information? No. It is stream specific. Anyone can access the cache. > 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. I don't understand this new sentence. I would hope the illustration would not preclude an implementation; that would seem counter-productive. Someone wanted that clarified. No harm in clarifying. > 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. This is still part of the design, right? Is this specified clearly someplace? 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. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Apr 24 10:27:05 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93EB03A6B02; Thu, 24 Apr 2008 10:27:05 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C27F3A6C0C for ; Thu, 24 Apr 2008 10:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeTkScrKsoCf for ; Thu, 24 Apr 2008 10:26:50 -0700 (PDT) Received: from zrtps0kp.us.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 841C928C260 for ; Thu, 24 Apr 2008 10:26:25 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3OHQOu19854; Thu, 24 Apr 2008 17:26:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Apr 2008 13:26:15 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4143A22D5@zcarhxm2.corp.nortel.com> In-Reply-To: <019501c8a5b7$d76c0d00$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues Thread-Index: AcilcZR/jISHmqM8QyGNyxNHmQZSAAARDK6gAB5Yr7A= References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> <019501c8a5b7$d76c0d00$0600a8c0@china.huawei.com> From: "Sharon Chisholm" To: "David B Harrington" , Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Inline -----Original Message----- From: David B Harrington [mailto:dbharrington@comcast.net] Sent: Wednesday, April 23, 2008 11:04 PM To: Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org Subject: RE: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues Hi, > D. In Section 7: > >> that it is viewed only by authorized users. If a user does not > have > >> permission to view content via other NETCONF operations, it must > not > >> 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 or a configuration? 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. you might want to change "it" to "he/she", or "the user" There is an edit later on that does it. > G. In section 3.3.2 > Replace > A notification is sent to indicate that all of the > replay notifications have been sent. > With > A notification is sent to indicate that all of the > replay notifications have been sent and must not be sent for any > other reason. Is the replay cache session-specific? Could another session request a replay of the same information? No. It is stream specific. Anyone can access the cache. > 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. I don't understand this new sentence. I would hope the illustration would not preclude an implementation; that would seem counter-productive. Someone wanted that clarified. No harm in clarifying. > 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. This is still part of the design, right? Is this specified clearly someplace? 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. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Apr 24 10:50:30 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69FC03A6BA9; Thu, 24 Apr 2008 10:50:30 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 850A73A6C87 for ; Thu, 24 Apr 2008 10:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.754 X-Spam-Level: X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZeRbyBSk3nT for ; Thu, 24 Apr 2008 10:50:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C67493A6C3A for ; Thu, 24 Apr 2008 10:50:17 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 60E27C0002; Thu, 24 Apr 2008 19:50:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RcGA4cndAIY7; Thu, 24 Apr 2008 19:50:16 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 039C2C000B; Thu, 24 Apr 2008 19:50:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E6B815474DE; Thu, 24 Apr 2008 19:50:14 +0200 (CEST) Date: Thu, 24 Apr 2008 19:50:14 +0200 From: Juergen Schoenwaelder To: Per Hedeland Message-ID: <20080424175014.GB17532@elstar.local> Mail-Followup-To: Per Hedeland , Phil Shafer , netconf@ietf.org References: <200804241333.m3ODXHFI056605@idle.juniper.net> <4810AD65.7090708@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4810AD65.7090708@tail-f.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Thu, Apr 24, 2008 at 05:55:17PM +0200, Per Hedeland wrote: > On 2008-04-24 15:33, Phil Shafer wrote: > > Juergen Schoenwaelder writes: > >> 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 other hand a > >> timezone is not know, then a timezone it MUST NOT be included. > > > > 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. > > 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...). Exactly. No timezone means the value is ambiguous. But timestamps are still meaningful relative to other timestamps from the same box. > 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? 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). > 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? 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. > 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). 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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Apr 24 10:50:30 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69FC03A6BA9; Thu, 24 Apr 2008 10:50:30 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 850A73A6C87 for ; Thu, 24 Apr 2008 10:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.754 X-Spam-Level: X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZeRbyBSk3nT for ; Thu, 24 Apr 2008 10:50:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C67493A6C3A for ; Thu, 24 Apr 2008 10:50:17 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 60E27C0002; Thu, 24 Apr 2008 19:50:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RcGA4cndAIY7; Thu, 24 Apr 2008 19:50:16 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 039C2C000B; Thu, 24 Apr 2008 19:50:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E6B815474DE; Thu, 24 Apr 2008 19:50:14 +0200 (CEST) Date: Thu, 24 Apr 2008 19:50:14 +0200 From: Juergen Schoenwaelder To: Per Hedeland Message-ID: <20080424175014.GB17532@elstar.local> Mail-Followup-To: Per Hedeland , Phil Shafer , netconf@ietf.org References: <200804241333.m3ODXHFI056605@idle.juniper.net> <4810AD65.7090708@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4810AD65.7090708@tail-f.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Thu, Apr 24, 2008 at 05:55:17PM +0200, Per Hedeland wrote: > On 2008-04-24 15:33, Phil Shafer wrote: > > Juergen Schoenwaelder writes: > >> 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 other hand a > >> timezone is not know, then a timezone it MUST NOT be included. > > > > 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. > > 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...). Exactly. No timezone means the value is ambiguous. But timestamps are still meaningful relative to other timestamps from the same box. > 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? 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). > 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? 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. > 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). 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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 25 03:25:31 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CC093A6ABF; Fri, 25 Apr 2008 03:25:31 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BA7A3A6D13 for ; Fri, 25 Apr 2008 03:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C723hSXy9ru5 for ; Fri, 25 Apr 2008 03:25:25 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 3EF963A6851 for ; Fri, 25 Apr 2008 03:25:23 -0700 (PDT) Received: (qmail 20684 invoked from network); 25 Apr 2008 10:25:20 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 25 Apr 2008 10:25:20 -0000 From: "Bert Wijnen - IETF" To: "Andy Bierman" , "Sharon Chisholm" Date: Fri, 25 Apr 2008 12:25:18 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <480F882B.5090700@andybierman.com> Importance: Normal Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve DiscussIssues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I believe that in the pre-13 document that Sharon posted she changed them all. Agreed? Bert Wijnen > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > Andy Bierman > Verzonden: woensdag 23 april 2008 21:04 > Aan: Sharon Chisholm > CC: netconf@ietf.org > Onderwerp: Re: [Netconf] Notifications: Proposed Edits to Resolve > DiscussIssues > > > Sharon Chisholm wrote: > > 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. > > > > This list looks fine, except M should list 3 imports > (missing the 1 in the 2nd XSD). > > Andy > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 25 03:25:31 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CC093A6ABF; Fri, 25 Apr 2008 03:25:31 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BA7A3A6D13 for ; Fri, 25 Apr 2008 03:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C723hSXy9ru5 for ; Fri, 25 Apr 2008 03:25:25 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 3EF963A6851 for ; Fri, 25 Apr 2008 03:25:23 -0700 (PDT) Received: (qmail 20684 invoked from network); 25 Apr 2008 10:25:20 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 25 Apr 2008 10:25:20 -0000 From: "Bert Wijnen - IETF" To: "Andy Bierman" , "Sharon Chisholm" Date: Fri, 25 Apr 2008 12:25:18 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <480F882B.5090700@andybierman.com> Importance: Normal Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve DiscussIssues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I believe that in the pre-13 document that Sharon posted she changed them all. Agreed? Bert Wijnen > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > Andy Bierman > Verzonden: woensdag 23 april 2008 21:04 > Aan: Sharon Chisholm > CC: netconf@ietf.org > Onderwerp: Re: [Netconf] Notifications: Proposed Edits to Resolve > DiscussIssues > > > Sharon Chisholm wrote: > > 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. > > > > This list looks fine, except M should list 3 imports > (missing the 1 in the 2nd XSD). > > Andy > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 25 03:25:31 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 437C43A6D75; Fri, 25 Apr 2008 03:25:31 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 241C83A6851 for ; Fri, 25 Apr 2008 03:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnTBViKh0Ayv for ; Fri, 25 Apr 2008 03:25:29 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 8D7D13A6D06 for ; Fri, 25 Apr 2008 03:25:28 -0700 (PDT) Received: (qmail 20891 invoked from network); 25 Apr 2008 10:25:22 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 25 Apr 2008 10:25:22 -0000 From: "Bert Wijnen - IETF" To: "David B Harrington" , "'Sharon Chisholm'" , Date: Fri, 25 Apr 2008 12:25:21 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <019601c8a5b8$bd8b7d20$0600a8c0@china.huawei.com> Importance: Normal Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve DiscussIssues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dave, are you ahppy now with the document Sharon posted? Bert Wijnen > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > David B Harrington > Verzonden: donderdag 24 april 2008 5:10 > Aan: 'David B Harrington'; 'Sharon Chisholm'; netconf@ietf.org > Onderwerp: Re: [Netconf] Notifications: Proposed Edits to Resolve > DiscussIssues > > > Hi, > > a little bit further thought on this one: > > > > D. In Section 7: > > > >> that it is viewed only by authorized users. If a user does > not > > > have > > > >> permission to view content via other NETCONF > > operations, it must > > > not > > > >> 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 or 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@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 25 03:25:31 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 437C43A6D75; Fri, 25 Apr 2008 03:25:31 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 241C83A6851 for ; Fri, 25 Apr 2008 03:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnTBViKh0Ayv for ; Fri, 25 Apr 2008 03:25:29 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 8D7D13A6D06 for ; Fri, 25 Apr 2008 03:25:28 -0700 (PDT) Received: (qmail 20891 invoked from network); 25 Apr 2008 10:25:22 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 25 Apr 2008 10:25:22 -0000 From: "Bert Wijnen - IETF" To: "David B Harrington" , "'Sharon Chisholm'" , Date: Fri, 25 Apr 2008 12:25:21 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <019601c8a5b8$bd8b7d20$0600a8c0@china.huawei.com> Importance: Normal Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve DiscussIssues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dave, are you ahppy now with the document Sharon posted? Bert Wijnen > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > David B Harrington > Verzonden: donderdag 24 april 2008 5:10 > Aan: 'David B Harrington'; 'Sharon Chisholm'; netconf@ietf.org > Onderwerp: Re: [Netconf] Notifications: Proposed Edits to Resolve > DiscussIssues > > > Hi, > > a little bit further thought on this one: > > > > D. In Section 7: > > > >> that it is viewed only by authorized users. If a user does > not > > > have > > > >> permission to view content via other NETCONF > > operations, it must > > > not > > > >> 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 or 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@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 25 03:26:52 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03C4B28C28E; Fri, 25 Apr 2008 03:26:52 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBD593A6DC3 for ; Fri, 25 Apr 2008 03:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Cso9FU0qdkQ for ; Fri, 25 Apr 2008 03:26:43 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id A36E228C25D for ; Fri, 25 Apr 2008 03:26:42 -0700 (PDT) Received: (qmail 22526 invoked from network); 25 Apr 2008 10:26:46 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 25 Apr 2008 10:26:46 -0000 From: "Bert Wijnen - IETF" To: "Sharon Chisholm" , Date: Fri, 25 Apr 2008 12:26:46 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4143A2275@zcarhxm2.corp.nortel.com> Importance: Normal Subject: [Netconf] Quick WG Last Call on new draft update for notifications - close date May 1st. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org 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 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 > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > Sharon Chisholm > Verzonden: donderdag 24 april 2008 19:13 > Aan: netconf@ietf.org > Onderwerp: Re: [Netconf] Notifications: Proposed Edits to Resolve > DiscussIssues > > > hi > > Attached is the promised draft update. > > Sharon > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Chisholm, Sharon (CAR:ZZ00) > Sent: Wednesday, April 23, 2008 2:41 PM > To: netconf@ietf.org > Subject: [Netconf] Notifications: Proposed Edits to Resolve Discuss > Issues > > 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 > >> 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 operations. > With > The NETCONF server will then accept 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 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 has been specified, 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 notification is sent to indicate that all of the > replay notifications have been sent. When > a has been specified, 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 notification is sent to indicate that all of the > replay notifications have been sent. > With > A 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 and > > 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 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 > operation can be considered like a deferred , and the content that > different users can access may vary. This different access is reflected > in the that different users are able to subscribe to. > > M. Replace > > schemaLocation= > "http://www.iana.org/assignments/xml-registry/schema/netconf.xsd"/> > "urn:ietf:params:xml:ns:netconf:notification:1.0" > schemaLocation= > "http://www.iana.org/assignments/xml-registry/schema/notification.xsd"/> > > With > > schemaLocation="netconf.xsd"/> > "urn:ietf:params:xml:ns:netconf:notification:1.0" > schemaLocation="notification.xsd"/> > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 25 03:26:52 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03C4B28C28E; Fri, 25 Apr 2008 03:26:52 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBD593A6DC3 for ; Fri, 25 Apr 2008 03:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Cso9FU0qdkQ for ; Fri, 25 Apr 2008 03:26:43 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id A36E228C25D for ; Fri, 25 Apr 2008 03:26:42 -0700 (PDT) Received: (qmail 22526 invoked from network); 25 Apr 2008 10:26:46 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 25 Apr 2008 10:26:46 -0000 From: "Bert Wijnen - IETF" To: "Sharon Chisholm" , Date: Fri, 25 Apr 2008 12:26:46 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4143A2275@zcarhxm2.corp.nortel.com> Importance: Normal Subject: [Netconf] Quick WG Last Call on new draft update for notifications - close date May 1st. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org 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 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 > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > Sharon Chisholm > Verzonden: donderdag 24 april 2008 19:13 > Aan: netconf@ietf.org > Onderwerp: Re: [Netconf] Notifications: Proposed Edits to Resolve > DiscussIssues > > > hi > > Attached is the promised draft update. > > Sharon > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Chisholm, Sharon (CAR:ZZ00) > Sent: Wednesday, April 23, 2008 2:41 PM > To: netconf@ietf.org > Subject: [Netconf] Notifications: Proposed Edits to Resolve Discuss > Issues > > 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 > >> 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 operations. > With > The NETCONF server will then accept 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 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 has been specified, 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 notification is sent to indicate that all of the > replay notifications have been sent. When > a has been specified, 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 notification is sent to indicate that all of the > replay notifications have been sent. > With > A 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 and > > 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 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 > operation can be considered like a deferred , and the content that > different users can access may vary. This different access is reflected > in the that different users are able to subscribe to. > > M. Replace > > schemaLocation= > "http://www.iana.org/assignments/xml-registry/schema/netconf.xsd"/> > "urn:ietf:params:xml:ns:netconf:notification:1.0" > schemaLocation= > "http://www.iana.org/assignments/xml-registry/schema/notification.xsd"/> > > With > > schemaLocation="netconf.xsd"/> > "urn:ietf:params:xml:ns:netconf:notification:1.0" > schemaLocation="notification.xsd"/> > > Sharon Chisholm > Nortel > Ottawa, Ontario > Canada > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 25 04:30:00 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75DC728C155; Fri, 25 Apr 2008 04:30:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F02928C155 for ; Fri, 25 Apr 2008 04:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNNoKo6dvZYU for ; Fri, 25 Apr 2008 04:29:57 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 83FA33A6D13 for ; Fri, 25 Apr 2008 04:29:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,707,1199660400"; d="scan'208";a="7320269" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 25 Apr 2008 13:29:58 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3PBTwhK026543; Fri, 25 Apr 2008 13:29:58 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp521.cisco.com [10.61.66.9]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3PBTvB8016821; Fri, 25 Apr 2008 11:29:58 GMT Message-ID: <4811C0B5.7010907@cisco.com> Date: Fri, 25 Apr 2008 13:29:57 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B4143A2275@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4143A2275@zcarhxm2.corp.nortel.com> X-Enigmail-Version: 0.95.6 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=998; t=1209122998; x=1209986998; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Netconf]=20Notifications=3A=20Proposed =20Edits=20to=20Resolve=20Discuss=09Issues |Sender:=20; bh=aMuVYe58ec2mP3pSlEsUKH2s+seEWemmC9n+d9U7M0M=; b=Tee5HHvCEzT21imA/rLTeSzXM0RWX2c/irNrNxvBked2GqjD4dKCHfwVeo LfNQWBenigJGBO8S/NM9+lDCA626b83biTPZJEnD6DoykZgJwd8LNg5Lfi02 58ilYHDO+F; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Sharon, This comment is largely bureaucratic: > 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]. > RFC 3339 specifically uses a subset of ISO.8601.1988. As this discussion illustrates it is possible to construct times that are From netconf-bounces@ietf.org Fri Apr 25 04:30:00 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75DC728C155; Fri, 25 Apr 2008 04:30:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F02928C155 for ; Fri, 25 Apr 2008 04:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNNoKo6dvZYU for ; Fri, 25 Apr 2008 04:29:57 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 83FA33A6D13 for ; Fri, 25 Apr 2008 04:29:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,707,1199660400"; d="scan'208";a="7320269" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 25 Apr 2008 13:29:58 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3PBTwhK026543; Fri, 25 Apr 2008 13:29:58 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp521.cisco.com [10.61.66.9]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3PBTvB8016821; Fri, 25 Apr 2008 11:29:58 GMT Message-ID: <4811C0B5.7010907@cisco.com> Date: Fri, 25 Apr 2008 13:29:57 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Sharon Chisholm References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B4143A2275@zcarhxm2.corp.nortel.com> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4143A2275@zcarhxm2.corp.nortel.com> X-Enigmail-Version: 0.95.6 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=998; t=1209122998; x=1209986998; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Netconf]=20Notifications=3A=20Proposed =20Edits=20to=20Resolve=20Discuss=09Issues |Sender:=20; bh=aMuVYe58ec2mP3pSlEsUKH2s+seEWemmC9n+d9U7M0M=; b=Tee5HHvCEzT21imA/rLTeSzXM0RWX2c/irNrNxvBked2GqjD4dKCHfwVeo LfNQWBenigJGBO8S/NM9+lDCA626b83biTPZJEnD6DoykZgJwd8LNg5Lfi02 58ilYHDO+F; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Sharon, This comment is largely bureaucratic: > 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]. > 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 25 04:44:15 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED9863A6D1A; Fri, 25 Apr 2008 04:44:14 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D7C228C252 for ; Fri, 25 Apr 2008 04:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyTR3arHa5YJ for ; Fri, 25 Apr 2008 04:44:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BE0C128C0F3 for ; Fri, 25 Apr 2008 04:44:09 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D08C6C0016; Fri, 25 Apr 2008 13:44:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1H-PfzokQkhg; Fri, 25 Apr 2008 13:44:08 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 447A6C0015; Fri, 25 Apr 2008 13:44:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 54D03548952; Fri, 25 Apr 2008 13:44:07 +0200 (CEST) Date: Fri, 25 Apr 2008 13:44:07 +0200 From: Juergen Schoenwaelder To: Eliot Lear Message-ID: <20080425114407.GC19025@elstar.local> Mail-Followup-To: Eliot Lear , Sharon Chisholm , netconf@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B4143A2275@zcarhxm2.corp.nortel.com> <4811C0B5.7010907@cisco.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4811C0B5.7010907@cisco.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Fri, Apr 25, 2008 at 01:29:57PM +0200, Eliot Lear wrote: > Hi Sharon, > > This comment is largely bureaucratic: > > > 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]. > > > > RFC 3339 specifically uses a subset of ISO.8601.1988. As this > discussion illustrates it is possible to construct times that 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. 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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 25 04:44:15 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED9863A6D1A; Fri, 25 Apr 2008 04:44:14 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D7C228C252 for ; Fri, 25 Apr 2008 04:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyTR3arHa5YJ for ; Fri, 25 Apr 2008 04:44:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BE0C128C0F3 for ; Fri, 25 Apr 2008 04:44:09 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D08C6C0016; Fri, 25 Apr 2008 13:44:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1H-PfzokQkhg; Fri, 25 Apr 2008 13:44:08 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 447A6C0015; Fri, 25 Apr 2008 13:44:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 54D03548952; Fri, 25 Apr 2008 13:44:07 +0200 (CEST) Date: Fri, 25 Apr 2008 13:44:07 +0200 From: Juergen Schoenwaelder To: Eliot Lear Message-ID: <20080425114407.GC19025@elstar.local> Mail-Followup-To: Eliot Lear , Sharon Chisholm , netconf@ietf.org References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com> <713043CE8B8E1348AF3C546DBE02C1B4143A2275@zcarhxm2.corp.nortel.com> <4811C0B5.7010907@cisco.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4811C0B5.7010907@cisco.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve Discuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Fri, Apr 25, 2008 at 01:29:57PM +0200, Eliot Lear wrote: > Hi Sharon, > > This comment is largely bureaucratic: > > > 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]. > > > > RFC 3339 specifically uses a subset of ISO.8601.1988. As this > discussion illustrates it is possible to construct times that 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. 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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 25 05:24:00 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6543A6C7D; Fri, 25 Apr 2008 05:24:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A13F93A6C2B for ; Fri, 25 Apr 2008 05:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joq+kYbdkdKA for ; Fri, 25 Apr 2008 05:23:58 -0700 (PDT) Received: from zrtps0kp.us.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 0B2713A6959 for ; Fri, 25 Apr 2008 05:23:57 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3PCNwE29521; Fri, 25 Apr 2008 12:23:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 25 Apr 2008 08:23:10 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4143A2BEF@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Notifications: Proposed Edits to Resolve DiscussIssues Thread-Index: AcimvrN7XooGdL7zRCGJpnNq4/KDAAAEGD8A References: <480F882B.5090700@andybierman.com> From: "Sharon Chisholm" To: "Bert Wijnen - IETF" , "Andy Bierman" Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve DiscussIssues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Actually, I changed it in 4 places since I found another while editing. Sharon -----Original Message----- From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] Sent: Friday, April 25, 2008 6:25 AM To: Andy Bierman; Chisholm, Sharon (CAR:ZZ00) Cc: netconf@ietf.org 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 > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > Andy Bierman > Verzonden: woensdag 23 april 2008 21:04 > Aan: Sharon Chisholm > CC: netconf@ietf.org > Onderwerp: Re: [Netconf] Notifications: Proposed Edits to Resolve > DiscussIssues > > > Sharon Chisholm wrote: > > 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. > > > > This list looks fine, except M should list 3 imports (missing the 1 in > the 2nd XSD). > > Andy > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 25 05:24:00 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6543A6C7D; Fri, 25 Apr 2008 05:24:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A13F93A6C2B for ; Fri, 25 Apr 2008 05:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joq+kYbdkdKA for ; Fri, 25 Apr 2008 05:23:58 -0700 (PDT) Received: from zrtps0kp.us.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 0B2713A6959 for ; Fri, 25 Apr 2008 05:23:57 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3PCNwE29521; Fri, 25 Apr 2008 12:23:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 25 Apr 2008 08:23:10 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B4143A2BEF@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Notifications: Proposed Edits to Resolve DiscussIssues Thread-Index: AcimvrN7XooGdL7zRCGJpnNq4/KDAAAEGD8A References: <480F882B.5090700@andybierman.com> From: "Sharon Chisholm" To: "Bert Wijnen - IETF" , "Andy Bierman" Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to Resolve DiscussIssues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Actually, I changed it in 4 places since I found another while editing. Sharon -----Original Message----- From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] Sent: Friday, April 25, 2008 6:25 AM To: Andy Bierman; Chisholm, Sharon (CAR:ZZ00) Cc: netconf@ietf.org 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 > -----Oorspronkelijk bericht----- > Van: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org]Namens > Andy Bierman > Verzonden: woensdag 23 april 2008 21:04 > Aan: Sharon Chisholm > CC: netconf@ietf.org > Onderwerp: Re: [Netconf] Notifications: Proposed Edits to Resolve > DiscussIssues > > > Sharon Chisholm wrote: > > 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. > > > > This list looks fine, except M should list 3 imports (missing the 1 in > the 2nd XSD). > > Andy > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 25 12:04:09 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C4BB28C0E5; Fri, 25 Apr 2008 12:04:09 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE6C828C331 for ; Fri, 25 Apr 2008 12:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AyJCOdUB93q for ; Fri, 25 Apr 2008 12:03:58 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id D830F28C39C for ; Fri, 25 Apr 2008 12:02:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qxI4hZXBVC56gpHzr5SMbMHCjLPHRBVY07lYS8SXgOD0HhbTDgNjX2hbbGj1gzg6; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.78.77] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JpTBv-0005wd-Lh for netconf@ietf.org; Fri, 25 Apr 2008 15:02:40 -0400 Message-ID: <001001c8a6fe$90944800$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com><713043CE8B8E1348AF3C546DBE02C1B4143A2275@zcarhxm2.corp.nortel.com><4811C0B5.7010907@cisco.com> <20080425114407.GC19025@elstar.local> Date: Fri, 25 Apr 2008 12:02:44 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc8911706267feb8e32d9cc71570c9b28247d65350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.78.77 Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi - > From: "Juergen Schoenwaelder" > To: "Eliot Lear" > Cc: > Sent: Friday, April 25, 2008 5:44 AM > Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues .... > 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. ... If the device truly doesn't know its timezone, wouldn't RFC 3339 section 4.3 apply anyway? Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 25 12:04:09 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C4BB28C0E5; Fri, 25 Apr 2008 12:04:09 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE6C828C331 for ; Fri, 25 Apr 2008 12:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AyJCOdUB93q for ; Fri, 25 Apr 2008 12:03:58 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id D830F28C39C for ; Fri, 25 Apr 2008 12:02:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qxI4hZXBVC56gpHzr5SMbMHCjLPHRBVY07lYS8SXgOD0HhbTDgNjX2hbbGj1gzg6; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.78.77] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JpTBv-0005wd-Lh for netconf@ietf.org; Fri, 25 Apr 2008 15:02:40 -0400 Message-ID: <001001c8a6fe$90944800$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com><713043CE8B8E1348AF3C546DBE02C1B4143A2275@zcarhxm2.corp.nortel.com><4811C0B5.7010907@cisco.com> <20080425114407.GC19025@elstar.local> Date: Fri, 25 Apr 2008 12:02:44 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc8911706267feb8e32d9cc71570c9b28247d65350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.78.77 Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi - > From: "Juergen Schoenwaelder" > To: "Eliot Lear" > Cc: > Sent: Friday, April 25, 2008 5:44 AM > Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues .... > 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. ... If the device truly doesn't know its timezone, wouldn't RFC 3339 section 4.3 apply anyway? Randy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 25 12:28:12 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0067228C1EB; Fri, 25 Apr 2008 12:28:12 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE54C28C1D6 for ; Fri, 25 Apr 2008 12:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgVBtBjeQ0t9 for ; Fri, 25 Apr 2008 12:28:09 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 83AE928C1B1 for ; Fri, 25 Apr 2008 12:28:09 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B0ED0C0012; Fri, 25 Apr 2008 21:28:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ucfvThqiA+V4; Fri, 25 Apr 2008 21:28:02 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 66BC7C000E; Fri, 25 Apr 2008 21:28:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 82F30549647; Fri, 25 Apr 2008 21:28:01 +0200 (CEST) Date: Fri, 25 Apr 2008 21:28:01 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20080425192801.GA20496@elstar.local> Mail-Followup-To: Randy Presuhn , netconf@ietf.org References: <20080425114407.GC19025@elstar.local> <001001c8a6fe$90944800$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <001001c8a6fe$90944800$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org 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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 25 12:28:12 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0067228C1EB; Fri, 25 Apr 2008 12:28:12 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE54C28C1D6 for ; Fri, 25 Apr 2008 12:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgVBtBjeQ0t9 for ; Fri, 25 Apr 2008 12:28:09 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 83AE928C1B1 for ; Fri, 25 Apr 2008 12:28:09 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B0ED0C0012; Fri, 25 Apr 2008 21:28:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ucfvThqiA+V4; Fri, 25 Apr 2008 21:28:02 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 66BC7C000E; Fri, 25 Apr 2008 21:28:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 82F30549647; Fri, 25 Apr 2008 21:28:01 +0200 (CEST) Date: Fri, 25 Apr 2008 21:28:01 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20080425192801.GA20496@elstar.local> Mail-Followup-To: Randy Presuhn , netconf@ietf.org References: <20080425114407.GC19025@elstar.local> <001001c8a6fe$90944800$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <001001c8a6fe$90944800$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org 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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 25 12:59:59 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C26A28C214; Fri, 25 Apr 2008 12:59:59 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395AB28C1C2 for ; Fri, 25 Apr 2008 12:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZQxa9gzFqwl for ; Fri, 25 Apr 2008 12:59:57 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 4A1463A6D74 for ; Fri, 25 Apr 2008 12:59:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=rF0c2vQ15KC9YX2R7LDgyMpol4sN/ku6RLBEr+WRBCdhPjWhfFSFVb5u9z05DKgN; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.78.77] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JpU5R-0002GW-My for netconf@ietf.org; Fri, 25 Apr 2008 16:00:02 -0400 Message-ID: <000401c8a706$95430960$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20080425114407.GC19025@elstar.local> <001001c8a6fe$90944800$6801a8c0@oemcomputer> <20080425192801.GA20496@elstar.local> Date: Fri, 25 Apr 2008 13:00:08 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117fdb9ee9ff7f5a73d30c36874adbaebc0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.78.77 Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Friday, April 25, 2008 1:28 PM > Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues > > 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." ... 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Apr 25 12:59:59 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C26A28C214; Fri, 25 Apr 2008 12:59:59 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395AB28C1C2 for ; Fri, 25 Apr 2008 12:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZQxa9gzFqwl for ; Fri, 25 Apr 2008 12:59:57 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 4A1463A6D74 for ; Fri, 25 Apr 2008 12:59:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=rF0c2vQ15KC9YX2R7LDgyMpol4sN/ku6RLBEr+WRBCdhPjWhfFSFVb5u9z05DKgN; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.78.77] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JpU5R-0002GW-My for netconf@ietf.org; Fri, 25 Apr 2008 16:00:02 -0400 Message-ID: <000401c8a706$95430960$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20080425114407.GC19025@elstar.local> <001001c8a6fe$90944800$6801a8c0@oemcomputer> <20080425192801.GA20496@elstar.local> Date: Fri, 25 Apr 2008 13:00:08 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117fdb9ee9ff7f5a73d30c36874adbaebc0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.78.77 Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Friday, April 25, 2008 1:28 PM > Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues > > 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." ... 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 28 04:18:54 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A7013A6E70; Mon, 28 Apr 2008 04:18:54 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 066233A6E78 for ; Mon, 28 Apr 2008 04:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGX8ZxGIbQYc for ; Mon, 28 Apr 2008 04:18:52 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id B25543A6E20 for ; Mon, 28 Apr 2008 04:18:50 -0700 (PDT) X-Trace: 69944461/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-temporary-group/213.116.52.235 X-SBRS: None X-RemoteIP: 213.116.52.235 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEAPpPFUjVdDTr/2dsb2JhbACLR55JBA X-IP-Direction: IN Received: from 1cust235.tnt102.lnd4.gbr.da.uu.net (HELO allison) ([213.116.52.235]) by smtp.pipex.tiscali.co.uk with SMTP; 28 Apr 2008 12:18:48 +0100 Message-ID: <034801c8a918$af98e000$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" References: <480D6187.7070406@andybierman.com><007101c8a47f$28ff4900$0600a8c0@china.huawei.com> <480DF1CC.1060708@andybierman.com> Date: Mon, 28 Apr 2008 12:13:23 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netconf@ietf.org Subject: Re: [Netconf] Holding Notifications Document X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org ---- Original Message ----- From: "Andy Bierman" To: "David B Harrington" Cc: Sent: Tuesday, April 22, 2008 4:10 PM Subject: Re: [Netconf] Holding Notifications Document > > The WGLC thread ended already -- remove the schemaLocation attribute > and publish seems to be the consensus. > > All IANA is supposed to do here is maintain a list > of URIs assigned to namespaces. A simple text document > like for port numbers would be sufficient for this purpose. > (Does anyone know if this file exists?) > > Instead, IANA is extracting XSDs and storing them online, but > it does not want applications to know about it. This is neither > a registry or a repository. (Let's just keep doing > this a few more years and it will become a 'long-standing' tradition > that cannot be changed ;-) > To quote from RFC3688, The IETF XML Registry, " The IANA will also maintain a file server available via at least HTTP and FTP that contains all of the registered elements in some publicly accessible file space in the same way that all of the IANA's registered elements arFrom netconf-bounces@ietf.org Mon Apr 28 04:18:54 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A7013A6E70; Mon, 28 Apr 2008 04:18:54 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 066233A6E78 for ; Mon, 28 Apr 2008 04:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGX8ZxGIbQYc for ; Mon, 28 Apr 2008 04:18:52 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id B25543A6E20 for ; Mon, 28 Apr 2008 04:18:50 -0700 (PDT) X-Trace: 69944461/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-temporary-group/213.116.52.235 X-SBRS: None X-RemoteIP: 213.116.52.235 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcEAPpPFUjVdDTr/2dsb2JhbACLR55JBA X-IP-Direction: IN Received: from 1cust235.tnt102.lnd4.gbr.da.uu.net (HELO allison) ([213.116.52.235]) by smtp.pipex.tiscali.co.uk with SMTP; 28 Apr 2008 12:18:48 +0100 Message-ID: <034801c8a918$af98e000$0601a8c0@allison> From: "tom.petch" To: "Andy Bierman" References: <480D6187.7070406@andybierman.com><007101c8a47f$28ff4900$0600a8c0@china.huawei.com> <480DF1CC.1060708@andybierman.com> Date: Mon, 28 Apr 2008 12:13:23 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netconf@ietf.org Subject: Re: [Netconf] Holding Notifications Document X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org ---- Original Message ----- From: "Andy Bierman" To: "David B Harrington" Cc: Sent: Tuesday, April 22, 2008 4:10 PM Subject: Re: [Netconf] Holding Notifications Document > > The WGLC thread ended already -- remove the schemaLocation attribute > and publish seems to be the consensus. > > All IANA is supposed to do here is maintain a list > of URIs assigned to namespaces. A simple text document > like for port numbers would be sufficient for this purpose. > (Does anyone know if this file exists?) > > Instead, IANA is extracting XSDs and storing them online, but > it does not want applications to know about it. This is neither > a registry or a repository. (Let's just keep doing > this a few more years and it will become a 'long-standing' tradition > that cannot be changed ;-) > To quote from RFC3688, The IETF XML Registry, " The IANA will also maintain a file server available via at least HTTP and FTP that contains all of the registered elements in some publicly accessible file space in the same way that all of the IANA's registered elements are avaie available via http://www.iana.org/assignments/. While the directory structure of this server is up to the IANA, it is suggested that the files be organized by the and the individual files have the as their filename." so while I appreciate the semantic distinction between repository and registry, it seems clear to me that IANA are maintaining a readily accessible filestore of the XSD source. I note too the recent announcement that IANA are converting all their registries to XML and inviting us to check that the contents have not been inadvertently changed in doing so:-) Tom Petch > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf lable via http://www.iana.org/assignments/. While the directory structure of this server is up to the IANA, it is suggested that the files be organized by the and the individual files have the as their filename." so while I appreciate the semantic distinction between repository and registry, it seems clear to me that IANA are maintaining a readily accessible filestore of the XSD source. I note too the recent announcement that IANA are converting all their registries to XML and inviting us to check that the contents have not been inadvertently changed in doing so:-) Tom Petch > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 28 10:28:42 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB42328C2A4; Mon, 28 Apr 2008 10:28:41 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B61A28C2AD for ; Mon, 28 Apr 2008 10:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWoyMeBbO9z5 for ; Mon, 28 Apr 2008 10:28:40 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id E2A9F28C2BC for ; Mon, 28 Apr 2008 10:28:39 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA04.westchester.pa.mail.comcast.net with comcast id K3iW1Z00C0ldTLk540E000; Mon, 28 Apr 2008 17:26:36 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA04.westchester.pa.mail.comcast.net with comcast id K5Ui1Z0044HwxpC3Q00100; Mon, 28 Apr 2008 17:28:42 +0000 X-Authority-Analysis: v=1.0 c=1 a=9znimkgQoYwA:10 a=R8LCDrCiFMwA:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=ikJVuN7XhKxtAQ8cAhwA:9 a=pWplE8AepR7KMg9Gf-gA:7 a=YFeaNsZU-uvul1EKIHgnGQnm3AwA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=gi0PWCVxevcA:10 From: "David B Harrington" To: , "'Eliot Lear'" References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com><713043CE8B8E1348AF3C546DBE02C1B4143A2275@zcarhxm2.corp.nortel.com><4811C0B5.7010907@cisco.com> <20080425114407.GC19025@elstar.local> Date: Mon, 28 Apr 2008 13:28:20 -0400 Message-ID: <002101c8a955$4e0565b0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080425114407.GC19025@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcimybQVJEZ5iqdXTweyEournL26jgABBQJg Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I believe we should follow RFC3339 section 4.4 David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Friday, April 25, 2008 7:44 AM > To: Eliot Lear > Cc: netconf@ietf.org > Subject: Re: [Netconf] Notifications: Proposed Edits to > ResolveDiscuss Issues > > On Fri, Apr 25, 2008 at 01:29:57PM +0200, Eliot Lear wrote: > > Hi Sharon, > > > > This comment is largely bureaucratic: > > > > > 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.From netconf-bounces@ietf.org Mon Apr 28 10:28:42 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB42328C2A4; Mon, 28 Apr 2008 10:28:41 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B61A28C2AD for ; Mon, 28 Apr 2008 10:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWoyMeBbO9z5 for ; Mon, 28 Apr 2008 10:28:40 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id E2A9F28C2BC for ; Mon, 28 Apr 2008 10:28:39 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA04.westchester.pa.mail.comcast.net with comcast id K3iW1Z00C0ldTLk540E000; Mon, 28 Apr 2008 17:26:36 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA04.westchester.pa.mail.comcast.net with comcast id K5Ui1Z0044HwxpC3Q00100; Mon, 28 Apr 2008 17:28:42 +0000 X-Authority-Analysis: v=1.0 c=1 a=9znimkgQoYwA:10 a=R8LCDrCiFMwA:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=ikJVuN7XhKxtAQ8cAhwA:9 a=pWplE8AepR7KMg9Gf-gA:7 a=YFeaNsZU-uvul1EKIHgnGQnm3AwA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=gi0PWCVxevcA:10 From: "David B Harrington" To: , "'Eliot Lear'" References: <713043CE8B8E1348AF3C546DBE02C1B41435D6BF@zcarhxm2.corp.nortel.com><713043CE8B8E1348AF3C546DBE02C1B4143A2275@zcarhxm2.corp.nortel.com><4811C0B5.7010907@cisco.com> <20080425114407.GC19025@elstar.local> Date: Mon, 28 Apr 2008 13:28:20 -0400 Message-ID: <002101c8a955$4e0565b0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080425114407.GC19025@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcimybQVJEZ5iqdXTweyEournL26jgABBQJg Cc: netconf@ietf.org Subject: Re: [Netconf] Notifications: Proposed Edits to ResolveDiscuss Issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I believe we should follow RFC3339 section 4.4 David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Friday, April 25, 2008 7:44 AM > To: Eliot Lear > Cc: netconf@ietf.org > Subject: Re: [Netconf] Notifications: Proposed Edits to > ResolveDiscuss Issues > > On Fri, Apr 25, 2008 at 01:29:57PM +0200, Eliot Lear wrote: > > Hi Sharon, > > > > This comment is largely bureaucratic: > > > > > 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]. > > > > > > > RFC 3339 specifically uses a subset of ISO.8601.1988. As this > > discussion illustrates it is possible to construct times that 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. > > 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 > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf 1988]. > > > > > > > RFC 3339 specifically uses a subset of ISO.8601.1988. As this > > discussion illustrates it is possible to construct times that 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. > > 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 > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 28 10:28:47 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3364B28C1CD; Mon, 28 Apr 2008 10:28:47 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B48D228C2C1 for ; Mon, 28 Apr 2008 10:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGWwvBNeQ83L for ; Mon, 28 Apr 2008 10:28:40 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 20F0728C2A0 for ; Mon, 28 Apr 2008 10:28:40 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA01.westchester.pa.mail.comcast.net with comcast id K3lf1Z0020ldTLk510Dl00; Mon, 28 Apr 2008 17:28:43 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA04.westchester.pa.mail.comcast.net with comcast id K5Ui1Z0044HwxpC3Q00000; Mon, 28 Apr 2008 17:28:42 +0000 X-Authority-Analysis: v=1.0 c=1 a=v4OeW0sIvcMA:10 a=b5_5Ced8XyHLp_88UhYA:9 a=xq_yvSI4WAx3lCmlqaEA:7 a=xlE9zQ8d_f_Vor_ENAoMZ15OFB0A:4 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Bert Wijnen - IETF'" , "'Sharon Chisholm'" , References: <019601c8a5b8$bd8b7d20$0600a8c0@china.huawei.com> Date: Mon, 28 Apr 2008 13:28:20 -0400 Message-ID: <002001c8a955$4de644f0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcimvrMrXzXOTnPHR/aAHTaGvW08kQAD0Ekg Subject: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org 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 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 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 28 10:28:47 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3364B28C1CD; Mon, 28 Apr 2008 10:28:47 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B48D228C2C1 for ; Mon, 28 Apr 2008 10:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGWwvBNeQ83L for ; Mon, 28 Apr 2008 10:28:40 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 20F0728C2A0 for ; Mon, 28 Apr 2008 10:28:40 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA01.westchester.pa.mail.comcast.net with comcast id K3lf1Z0020ldTLk510Dl00; Mon, 28 Apr 2008 17:28:43 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA04.westchester.pa.mail.comcast.net with comcast id K5Ui1Z0044HwxpC3Q00000; Mon, 28 Apr 2008 17:28:42 +0000 X-Authority-Analysis: v=1.0 c=1 a=v4OeW0sIvcMA:10 a=b5_5Ced8XyHLp_88UhYA:9 a=xq_yvSI4WAx3lCmlqaEA:7 a=xlE9zQ8d_f_Vor_ENAoMZ15OFB0A:4 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Bert Wijnen - IETF'" , "'Sharon Chisholm'" , References: <019601c8a5b8$bd8b7d20$0600a8c0@china.huawei.com> Date: Mon, 28 Apr 2008 13:28:20 -0400 Message-ID: <002001c8a955$4de644f0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcimvrMrXzXOTnPHR/aAHTaGvW08kQAD0Ekg Subject: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org 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 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 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 28 10:30:56 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1430C28C27F; Mon, 28 Apr 2008 10:30:56 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9CE128C19C for ; Mon, 28 Apr 2008 10:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQAqFFaQwgoY for ; Mon, 28 Apr 2008 10:30:51 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id AEE3A28C27F for ; Mon, 28 Apr 2008 10:30:50 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA10.westchester.pa.mail.comcast.net with comcast id K1YA1Z00A0Fqzac5A0LU00; Mon, 28 Apr 2008 17:29:36 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.westchester.pa.mail.comcast.net with comcast id K5Wg1Z00V4HwxpC3U00000; Mon, 28 Apr 2008 17:30:41 +0000 X-Authority-Analysis: v=1.0 c=1 a=fMkSFrdB5yTfGNJ-wusA:9 a=2xMMEDdL0i_SUL03kVMA:7 a=yWJnOvZmId1ipRgrm5FK5IMWV2wA:4 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Bert Wijnen - IETF'" , "'Sharon Chisholm'" , References: <019601c8a5b8$bd8b7d20$0600a8c0@china.huawei.com> Date: Mon, 28 Apr 2008 13:30:40 -0400 Message-ID: <002601c8a955$94b1be50$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcimvrMrXzXOTnPHR/aAHTaGvW08kQAFu8fQ Subject: [Netconf] Issue X: replaying replay X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 28 10:30:56 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1430C28C27F; Mon, 28 Apr 2008 10:30:56 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9CE128C19C for ; Mon, 28 Apr 2008 10:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQAqFFaQwgoY for ; Mon, 28 Apr 2008 10:30:51 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id AEE3A28C27F for ; Mon, 28 Apr 2008 10:30:50 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA10.westchester.pa.mail.comcast.net with comcast id K1YA1Z00A0Fqzac5A0LU00; Mon, 28 Apr 2008 17:29:36 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.westchester.pa.mail.comcast.net with comcast id K5Wg1Z00V4HwxpC3U00000; Mon, 28 Apr 2008 17:30:41 +0000 X-Authority-Analysis: v=1.0 c=1 a=fMkSFrdB5yTfGNJ-wusA:9 a=2xMMEDdL0i_SUL03kVMA:7 a=yWJnOvZmId1ipRgrm5FK5IMWV2wA:4 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Bert Wijnen - IETF'" , "'Sharon Chisholm'" , References: <019601c8a5b8$bd8b7d20$0600a8c0@china.huawei.com> Date: Mon, 28 Apr 2008 13:30:40 -0400 Message-ID: <002601c8a955$94b1be50$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcimvrMrXzXOTnPHR/aAHTaGvW08kQAFu8fQ Subject: [Netconf] Issue X: replaying replay X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 28 23:41:46 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E4403A687D; Mon, 28 Apr 2008 23:41:46 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06F413A6809 for ; Mon, 28 Apr 2008 23:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0JETup1P9XD for ; Mon, 28 Apr 2008 23:41:41 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 66FBB3A6CEB for ; Mon, 28 Apr 2008 23:41:20 -0700 (PDT) Received: (qmail 24432 invoked from network); 29 Apr 2008 06:41:23 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 29 Apr 2008 06:41:23 -0000 From: "Bert Wijnen - IETF" To: "David B Harrington" , "'Sharon Chisholm'" , Date: Tue, 29 Apr 2008 08:41:25 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <002601c8a955$94b1be50$0600a8c0@china.huawei.com> Importance: Normal Subject: Re: [Netconf] Issue X: replaying replay X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Inline Bert Wijnen > -----Oorspronkelijk bericht----- > Van: David B Harrington [mailto:dbharrington@comcast.net] > Verzonden: maandag 28 april 2008 19:31 > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > Onderwerp: Issue X: replaying replay > > > 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." > 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. > -- > 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? > 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 netconf-bounces@ietf.org Mon Apr 28 23:41:46 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E4403A687D; Mon, 28 Apr 2008 23:41:46 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06F413A6809 for ; Mon, 28 Apr 2008 23:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0JETup1P9XD for ; Mon, 28 Apr 2008 23:41:41 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 66FBB3A6CEB for ; Mon, 28 Apr 2008 23:41:20 -0700 (PDT) Received: (qmail 24432 invoked from network); 29 Apr 2008 06:41:23 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 29 Apr 2008 06:41:23 -0000 From: "Bert Wijnen - IETF" To: "David B Harrington" , "'Sharon Chisholm'" , Date: Tue, 29 Apr 2008 08:41:25 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <002601c8a955$94b1be50$0600a8c0@china.huawei.com> Importance: Normal Subject: Re: [Netconf] Issue X: replaying replay X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Inline Bert Wijnen > -----Oorspronkelijk bericht----- > Van: David B Harrington [mailto:dbharrington@comcast.net] > Verzonden: maandag 28 april 2008 19:31 > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > Onderwerp: Issue X: replaying replay > > > 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." > 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. > -- > 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? > 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. > -- > I sent a separate mail discussing the access control CLR issue I > raised. > Answered that separately. Bert > dbh > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf 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. > -- > I sent a separate mail discussing the access control CLR issue I > raised. > Answered that separately. Bert > dbh > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 28 23:41:47 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFFC23A6CDC; Mon, 28 Apr 2008 23:41:46 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BC503A694B for ; Mon, 28 Apr 2008 23:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXBgo2R-QHj7 for ; Mon, 28 Apr 2008 23:41:41 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 6700C3A6CF8 for ; Mon, 28 Apr 2008 23:41:20 -0700 (PDT) Received: (qmail 24426 invoked from network); 29 Apr 2008 06:41:22 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 29 Apr 2008 06:41:22 -0000 From: "Bert Wijnen - IETF" To: "David B Harrington" , "'Sharon Chisholm'" , Date: Tue, 29 Apr 2008 08:41:25 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <002001c8a955$4de644f0$0600a8c0@china.huawei.com> Importance: Normal Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org 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 > -----Oorspronkelijk bericht----- > Van: David B Harrington [mailto:dbharrington@comcast.net] > Verzonden: maandag 28 april 2008 19:28 > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > Onderwerp: Issue X: access to notification content > > > 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 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 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 > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Apr 28 23:41:47 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFFC23A6CDC; Mon, 28 Apr 2008 23:41:46 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BC503A694B for ; Mon, 28 Apr 2008 23:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXBgo2R-QHj7 for ; Mon, 28 Apr 2008 23:41:41 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 6700C3A6CF8 for ; Mon, 28 Apr 2008 23:41:20 -0700 (PDT) Received: (qmail 24426 invoked from network); 29 Apr 2008 06:41:22 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 29 Apr 2008 06:41:22 -0000 From: "Bert Wijnen - IETF" To: "David B Harrington" , "'Sharon Chisholm'" , Date: Tue, 29 Apr 2008 08:41:25 +0200 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <002001c8a955$4de644f0$0600a8c0@china.huawei.com> Importance: Normal Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org 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 > -----Oorspronkelijk bericht----- > Van: David B Harrington [mailto:dbharrington@comcast.net] > Verzonden: maandag 28 april 2008 19:28 > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > Onderwerp: Issue X: access to notification content > > > 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 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 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 > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 29 07:25:00 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B703D28C138; Tue, 29 Apr 2008 07:25:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B750A3A6DEA for ; Tue, 29 Apr 2008 07:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QunyeEwBfdX for ; Tue, 29 Apr 2008 07:24:58 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 9BD0E3A6D75 for ; Tue, 29 Apr 2008 07:24:58 -0700 (PDT) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA03.westchester.pa.mail.comcast.net with comcast id KP6h1Z00F16LCl0530Rl00; Tue, 29 Apr 2008 14:23:08 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA06.westchester.pa.mail.comcast.net with comcast id KSR01Z00K4HwxpC3S00000; Tue, 29 Apr 2008 14:25:01 +0000 X-Authority-Analysis: v=1.0 c=1 a=HHmwR-jtwyEA:10 a=Vu4nIF-vJQAA:10 a=94IfysCOt7px_EQVONgA:9 a=2jTIe2YjqetfkOSSeQIA:7 a=weyvZQErtZUKTdcU9lmKUExfpXkA:4 a=jFPUFpGHtmAA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Bert Wijnen - IETF'" , "'Sharon Chisholm'" , References: <002001c8a955$4de644f0$0600a8c0@china.huawei.com> Date: Tue, 29 Apr 2008 10:25:00 -0400 Message-ID: <008001c8aa04$cf575f60$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcipxBH0kMvr5BmcS5aFraZBNk9y+wAP94mQ Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org 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 > -----Original Message----- > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > Sent: Tuesday, April 29, 2008 2:41 AM > To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > Subject: RE: Issue X: access to notification content > > 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 > > > -----Oorspronkelijk bericht----- > > Van: David B Harrington [mailto:dbharrington@comcast.net] > > Verzonden: maandag 28 april 2008 19:28 > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > > Onderwerp: Issue X: access to notification content > > > > > > 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 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 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 > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 29 07:25:00 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B703D28C138; Tue, 29 Apr 2008 07:25:00 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B750A3A6DEA for ; Tue, 29 Apr 2008 07:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QunyeEwBfdX for ; Tue, 29 Apr 2008 07:24:58 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 9BD0E3A6D75 for ; Tue, 29 Apr 2008 07:24:58 -0700 (PDT) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA03.westchester.pa.mail.comcast.net with comcast id KP6h1Z00F16LCl0530Rl00; Tue, 29 Apr 2008 14:23:08 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA06.westchester.pa.mail.comcast.net with comcast id KSR01Z00K4HwxpC3S00000; Tue, 29 Apr 2008 14:25:01 +0000 X-Authority-Analysis: v=1.0 c=1 a=HHmwR-jtwyEA:10 a=Vu4nIF-vJQAA:10 a=94IfysCOt7px_EQVONgA:9 a=2jTIe2YjqetfkOSSeQIA:7 a=weyvZQErtZUKTdcU9lmKUExfpXkA:4 a=jFPUFpGHtmAA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Bert Wijnen - IETF'" , "'Sharon Chisholm'" , References: <002001c8a955$4de644f0$0600a8c0@china.huawei.com> Date: Tue, 29 Apr 2008 10:25:00 -0400 Message-ID: <008001c8aa04$cf575f60$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcipxBH0kMvr5BmcS5aFraZBNk9y+wAP94mQ Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org 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 > -----Original Message----- > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > Sent: Tuesday, April 29, 2008 2:41 AM > To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > Subject: RE: Issue X: access to notification content > > 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 > > > -----Oorspronkelijk bericht----- > > Van: David B Harrington [mailto:dbharrington@comcast.net] > > Verzonden: maandag 28 april 2008 19:28 > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > > Onderwerp: Issue X: access to notification content > > > > > > 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 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 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 > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 29 08:22:13 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADA9B3A6DB2; Tue, 29 Apr 2008 08:22:13 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445EB3A6CA7 for ; Tue, 29 Apr 2008 08:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRpfHKyo0Fr0 for ; Tue, 29 Apr 2008 08:22:05 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 3505C3A6DC8 for ; Tue, 29 Apr 2008 08:21:28 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA05.westchester.pa.mail.comcast.net with comcast id KSs21Z0020mv7h05503W00; Tue, 29 Apr 2008 15:21:13 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA11.westchester.pa.mail.comcast.net with comcast id KTLb1Z00G4HwxpC3X00000; Tue, 29 Apr 2008 15:20:36 +0000 X-Authority-Analysis: v=1.0 c=1 a=Y2KlB1hrfYlHyuVdO8YA:9 a=0_WgCLgKrFB2NWH1HekA:7 a=Ic8gAFT6ON1Z5rKzLhyT9c_6D18A:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=jFPUFpGHtmAA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Bert Wijnen - IETF'" , "'Sharon Chisholm'" , References: <002601c8a955$94b1be50$0600a8c0@china.huawei.com> Date: Tue, 29 Apr 2008 11:20:35 -0400 Message-ID: <008701c8aa0c$932cb7d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcipxAtmTByoMh7kRWixEY666/5Y9gAQTULA Subject: Re: [Netconf] Issue X: replaying replay X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org 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 dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > Sent: Tuesday, April 29, 2008 2:41 AM > To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > Subject: RE: Issue X: replaying replay > > Inline > > Bert Wijnen > > > -----Oorspronkelijk bericht----- > > Van: David B Harrington [mailto:dbharrington@comcast.net] > > Verzonden: maandag 28 april 2008 19:31 > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > > Onderwerp: Issue X: replaying replay > > > > > > 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." > > > > 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. > > > -- > > 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? > > > > 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 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. > > > -- > > I sent a separate mail discussing the access control CLR issue I > > raised. > > > Answered that separately. > > Bert > > dbh > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 29 08:22:13 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADA9B3A6DB2; Tue, 29 Apr 2008 08:22:13 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445EB3A6CA7 for ; Tue, 29 Apr 2008 08:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRpfHKyo0Fr0 for ; Tue, 29 Apr 2008 08:22:05 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 3505C3A6DC8 for ; Tue, 29 Apr 2008 08:21:28 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA05.westchester.pa.mail.comcast.net with comcast id KSs21Z0020mv7h05503W00; Tue, 29 Apr 2008 15:21:13 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA11.westchester.pa.mail.comcast.net with comcast id KTLb1Z00G4HwxpC3X00000; Tue, 29 Apr 2008 15:20:36 +0000 X-Authority-Analysis: v=1.0 c=1 a=Y2KlB1hrfYlHyuVdO8YA:9 a=0_WgCLgKrFB2NWH1HekA:7 a=Ic8gAFT6ON1Z5rKzLhyT9c_6D18A:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=jFPUFpGHtmAA:10 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Bert Wijnen - IETF'" , "'Sharon Chisholm'" , References: <002601c8a955$94b1be50$0600a8c0@china.huawei.com> Date: Tue, 29 Apr 2008 11:20:35 -0400 Message-ID: <008701c8aa0c$932cb7d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcipxAtmTByoMh7kRWixEY666/5Y9gAQTULA Subject: Re: [Netconf] Issue X: replaying replay X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org 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 dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > Sent: Tuesday, April 29, 2008 2:41 AM > To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > Subject: RE: Issue X: replaying replay > > Inline > > Bert Wijnen > > > -----Oorspronkelijk bericht----- > > Van: David B Harrington [mailto:dbharrington@comcast.net] > > Verzonden: maandag 28 april 2008 19:31 > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > > Onderwerp: Issue X: replaying replay > > > > > > 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." > > > > 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. > > > -- > > 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? > > > > 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 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. > > > -- > > I sent a separate mail discussing the access control CLR issue I > > raised. > > > Answered that separately. > > Bert > > dbh > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 29 23:33:54 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C377828C254; Tue, 29 Apr 2008 23:33:54 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 257D93A69E3; Tue, 29 Apr 2008 23:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEbJZRYXWbGH; Tue, 29 Apr 2008 23:33:50 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 836503A685A; Tue, 29 Apr 2008 23:33:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,726,1199682000"; d="scan'208";a="124194023" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 30 Apr 2008 02:33:52 -0400 X-IronPort-AV: E=Sophos;i="4.25,726,1199682000"; d="scan'208";a="195252973" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 Apr 2008 02:33:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 08:33:49 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Action: NETCONF Data Modeling Language (netmod) Thread-Index: AciqbCHbEpEMLNvIQ4ab2dxmTV6NJQAHlgAg From: "Romascanu, Dan (Dan)" To: Cc: NETCONF Goes On , netconf@ietf.org, ops-area@ietf.org Subject: [Netconf] FW: WG Action: NETCONF Data Modeling Language (netmod) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Please see below the announcement of the formation of the NETMOD Working Group. Congratulations and thanks to all the folks who worked hard and contributed to the formation of the Working Group. David Harrington and David Partain are the co-chairs of the WG, let us congratulate them and help them in their ambitious task. This team and this community has now the challenge of proving that the development of a data modeling language for management is possible in the IETF and that lessons of the past were well learned for the benefit of the network operators and of the devices and management applications developers. We have created the netmod@ietf.org list. Please subscribe to this list and move all discussions from the ngo and yang lists that fall under the scope of netmod to the new list. I suggest that we keep ngo@ietf.org for future not-chartered NETCONF discussions and that we shut down the yang list in the next few weeks. Regards, Dan -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Wednesday, April 30, 2008 5:44 AM To: IETF Announcement list Cc: dbharrington@comcast.net; david.partain@ericsson.com; netmod@ietf.org Subject: WG Action: NETCONF Data Modeling Language (netmod) A new IETF working group has been formed in the Operations and Management Area. For additional information, please contact the Area Directors or the WG Chairs. NETCONF Data Modeling Language (netmod) --------------------------------------------- Chair(s): David Harrington David Partain Operations and Management Area Director(s): Dan Romascanu Ronald Bonica >rbonica@juniper.net> Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: netmod@ietf.org To Subscribe: netmod-request@ietf.org In Body: in msg body: subscribe Archive: http://www.ietf.org/mail-archive/web/netmod/ Description: The NETCONF Working Group has completed a base protocol to be used for configuration management. However, the NETCONF protocol does not include a standard content layer. The specifications do not include a modeling language or accompanying rules that can be used to model the management information that is to be configured using NETCONF. This has resulted in inconsistent syntax and interoperability problems. The purpose of NETMOD is to support the ongoing development of IETF and vendor-defined data models for NETCONF. NETMOD's requirements are drawn from the RCDML requirements draft (draft-presuhn-rcdml) and documents referenced therein. The WG will define a "human-friendly" modeling language defining the semantics of operational data, configuration data, notifications, and operations. This language will focus on readability and ease of use. This language must be able to serve as the normative description of NETCONF data models. The WG will use YANG (draft-bjorklund-yang) as its starting point for this language. Language abstractions that facilitate model extensibility and reuse have been identified as a work area and will be considered as a work item or may be integrated into the YANG document based on WG consensus. The WG will define a canonical mapping of this language to NETCONF XML instance documents, the on-the-wire format of YANG-defined XML content. Only data models defined in YANG will have to adhere to this on-the-wire format. In order to leverage existing XML tools for validating NETCONF data in various contexts and also facilitate exchange of data models and schemas with other IETF working groups, the WG will define standard mapping rules from YANG to the DSDL data modeling framework (ISO/IEC 19757) with additional annotations to preserve semantics. The initial YANG mapping rules specifications are expressly defined for NETCONF modeling. However, there may be future areas of applicability beyond NETCONF, and the WG must provide suitable language extensibility mechanisms to allow for such future work. The NETMOD WG will only address modeling NETCONF devices and the language extensibility mechanisms. Any application of YANG to other protocols is future work. The WG will consult with the NETCONF WG to ensure that NETMOD's decision do not conflict with planned work in NETCONF (e.g., locking, notifications). While it is desirable to provide a migration path from existing MIB modules to YANG data models (modules), it is not a requirement to provide full compatibility between SMIv2 and YANG. The Working Group will determine which constructs (e.g., conformance statements) are not relevant for translation from SMIv2 to YANG. YANG is also permitted to introduce constructs that cannot be expressed in SMIv2. However, all basic types that can be represented in SMIv2 must be expressible in YANG. Initial deliverables are below. The working group may choose to combine multiple deliverables into a single document where deemed appropriate. 1. An architecture document explaining the relationship between YANG and its inputs and outputs. (informational) 2. The YANG data modeling language and semantics (proposed standard) 3. Mapping rules of YANG to XML instance data in NETCONF (proposed standard) 4. YIN, a semantically equivalent fully reversible mapping to an XML-based syntax for YANG. YIN is simply the data model in an XML syntax that can be manipulated using existing XML tools (e.g., XSLT) (proposed standard) 5. Mapping rules of YANG to DSDL data modeling framework (ISO/IEC 19757), including annotations for DSDL to preserve top-level semantics during translation (proposed standard). 6. A standard type library for use by YANG (proposed standard) Goals and Milestones: Jun 2008 - All _individual_ drafts available that will be used as input into the WG documents (draft-bjorklund-yang, architecture draft, YIN draft, YANG standard library draft, DSDL mapping rules draft) Aug 2008 - Initial set of WG drafts: architecture, YANG, YIN, YANG standard library, DSDL mapping rules (if there is one/more individual draft), based on WG decisions in Dublin Sep 2008 - Initial DSDL mapping rules document Oct 2008 - 01 of YANG, DSDL, architecture, YIN, and standard library draft. If split out, -00 of on-the-wire XML draft. Feb 2009 - WGLC for architecture doc Mar 2009 - Submit the architecture doc to the IESG for publication as an Informational RFC Aug 2009 - WGLC for YANG, YIN, XML on-the-wire (if split out), YANG standard library, DSDL mapping rules Sep 2009 - Submit YANG, YIN, XML on-the-wire (if split out), YANG standard library, DSDL mapping rules to the IESG for publication as a Proposed Standard _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Apr 29 23:33:54 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C377828C254; Tue, 29 Apr 2008 23:33:54 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 257D93A69E3; Tue, 29 Apr 2008 23:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEbJZRYXWbGH; Tue, 29 Apr 2008 23:33:50 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 836503A685A; Tue, 29 Apr 2008 23:33:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,726,1199682000"; d="scan'208";a="124194023" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 30 Apr 2008 02:33:52 -0400 X-IronPort-AV: E=Sophos;i="4.25,726,1199682000"; d="scan'208";a="195252973" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 Apr 2008 02:33:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 08:33:49 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Action: NETCONF Data Modeling Language (netmod) Thread-Index: AciqbCHbEpEMLNvIQ4ab2dxmTV6NJQAHlgAg From: "Romascanu, Dan (Dan)" To: Cc: NETCONF Goes On , netconf@ietf.org, ops-area@ietf.org Subject: [Netconf] FW: WG Action: NETCONF Data Modeling Language (netmod) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Please see below the announcement of the formation of the NETMOD Working Group. Congratulations and thanks to all the folks who worked hard and contributed to the formation of the Working Group. David Harrington and David Partain are the co-chairs of the WG, let us congratulate them and help them in their ambitious task. This team and this community has now the challenge of proving that the development of a data modeling language for management is possible in the IETF and that lessons of the past were well learned for the benefit of the network operators and of the devices and management applications developers. We have created the netmod@ietf.org list. Please subscribe to this list and move all discussions from the ngo and yang lists that fall under the scope of netmod to the new list. I suggest that we keep ngo@ietf.org for future not-chartered NETCONF discussions and that we shut down the yang list in the next few weeks. Regards, Dan -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Wednesday, April 30, 2008 5:44 AM To: IETF Announcement list Cc: dbharrington@comcast.net; david.partain@ericsson.com; netmod@ietf.org Subject: WG Action: NETCONF Data Modeling Language (netmod) A new IETF working group has been formed in the Operations and Management Area. For additional information, please contact the Area Directors or the WG Chairs. NETCONF Data Modeling Language (netmod) --------------------------------------------- Chair(s): David Harrington David Partain Operations and Management Area Director(s): Dan Romascanu Ronald Bonica >rbonica@juniper.net> Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: netmod@ietf.org To Subscribe: netmod-request@ietf.org In Body: in msg body: subscribe Archive: http://www.ietf.org/mail-archive/web/netmod/ Description: The NETCONF Working Group has completed a base protocol to be used for configuration management. However, the NETCONF protocol does not include a standard content layer. The specifications do not include a modeling language or accompanying rules that can be used to model the management information that is to be configured using NETCONF. This has resulted in inconsistent syntax and interoperability problems. The purpose of NETMOD is to support the ongoing development of IETF and vendor-defined data models for NETCONF. NETMOD's requirements are drawn from the RCDML requirements draft (draft-presuhn-rcdml) and documents referenced therein. The WG will define a "human-friendly" modeling language defining the semantics of operational data, configuration data, notifications, and operations. This language will focus on readability and ease of use. This language must be able to serve as the normative description of NETCONF data models. The WG will use YANG (draft-bjorklund-yang) as its starting point for this language. Language abstractions that facilitate model extensibility and reuse have been identified as a work area and will be considered as a work item or may be integrated into the YANG document based on WG consensus. The WG will define a canonical mapping of this language to NETCONF XML instance documents, the on-the-wire format of YANG-defined XML content. Only data models defined in YANG will have to adhere to this on-the-wire format. In order to leverage existing XML tools for validating NETCONF data in various contexts and also facilitate exchange of data models and schemas with other IETF working groups, the WG will define standard mapping rules from YANG to the DSDL data modeling framework (ISO/IEC 19757) with additional annotations to preserve semantics. The initial YANG mapping rules specifications are expressly defined for NETCONF modeling. However, there may be future areas of applicability beyond NETCONF, and the WG must provide suitable language extensibility mechanisms to allow for such future work. The NETMOD WG will only address modeling NETCONF devices and the language extensibility mechanisms. Any application of YANG to other protocols is future work. The WG will consult with the NETCONF WG to ensure that NETMOD's decision do not conflict with planned work in NETCONF (e.g., locking, notifications). While it is desirable to provide a migration path from existing MIB modules to YANG data models (modules), it is not a requirement to provide full compatibility between SMIv2 and YANG. The Working Group will determine which constructs (e.g., conformance statements) are not relevant for translation from SMIv2 to YANG. YANG is also permitted to introduce constructs that cannot be expressed in SMIv2. However, all basic types that can be represented in SMIv2 must be expressible in YANG. Initial deliverables are below. The working group may choose to combine multiple deliverables into a single document where deemed appropriate. 1. An architecture document explaining the relationship between YANG and its inputs and outputs. (informational) 2. The YANG data modeling language and semantics (proposed standard) 3. Mapping rules of YANG to XML instance data in NETCONF (proposed standard) 4. YIN, a semantically equivalent fully reversible mapping to an XML-based syntax for YANG. YIN is simply the data model in an XML syntax that can be manipulated using existing XML tools (e.g., XSLT) (proposed standard) 5. Mapping rules of YANG to DSDL data modeling framework (ISO/IEC 19757), including annotations for DSDL to preserve top-level semantics during translation (proposed standard). 6. A standard type library for use by YANG (proposed standard) Goals and Milestones: Jun 2008 - All _individual_ drafts available that will be used as input into the WG documents (draft-bjorklund-yang, architecture draft, YIN draft, YANG standard library draft, DSDL mapping rules draft) Aug 2008 - Initial set of WG drafts: architecture, YANG, YIN, YANG standard library, DSDL mapping rules (if there is one/more individual draft), based on WG decisions in Dublin Sep 2008 - Initial DSDL mapping rules document Oct 2008 - 01 of YANG, DSDL, architecture, YIN, and standard library draft. If split out, -00 of on-the-wire XML draft. Feb 2009 - WGLC for architecture doc Mar 2009 - Submit the architecture doc to the IESG for publication as an Informational RFC Aug 2009 - WGLC for YANG, YIN, XML on-the-wire (if split out), YANG standard library, DSDL mapping rules Sep 2009 - Submit YANG, YIN, XML on-the-wire (if split out), YANG standard library, DSDL mapping rules to the IESG for publication as a Proposed Standard _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 30 06:32:47 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12CDF3A6C18; Wed, 30 Apr 2008 06:32:47 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 846913A6B86 for ; Wed, 30 Apr 2008 06:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4wXx+pA+bGJ for ; Wed, 30 Apr 2008 06:24:55 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 053E63A6DE9 for ; Wed, 30 Apr 2008 06:24:54 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA10.westchester.pa.mail.comcast.net with comcast id KoB01Z00G0vyq2s5A07300; Wed, 30 Apr 2008 13:23:38 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA05.westchester.pa.mail.comcast.net with comcast id KpQw1Z0074HwxpC3R00000; Wed, 30 Apr 2008 13:24:56 +0000 X-Authority-Analysis: v=1.0 c=1 a=8jI9oDXYVr7kF9FuqWYA:9 a=9HLs96QzjXThmhUYVPNX2yiBfWcA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Wed, 30 Apr 2008 09:24:56 -0400 Message-ID: <013801c8aac5$953225b0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciqxZTh4vo937PbQ+OnQxdSzuLh5A== X-Mailman-Approved-At: Wed, 30 Apr 2008 06:32:46 -0700 Subject: [Netconf] review of monitoring-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, [This was stuck in my outgoing queue for a while; I've had a few problems with email delivery.] I have reviewed this document and have comments. First, kudos for including front matter that explained what the schema would contain. Thank you, thank you, thank you! 1) should session monitoring include logoutTime? It might be useful to operators to know what sessions existed, say, earlier in the day, when some configuration change occurred. How long could have a default value that could be manipulated by an administrator based on company policies or environmental conditions (e.g. location and sensitivity of the managed device) 2) configurations:lockStatus - will this support partially locked? 3) under subscriptions: s/ all notifications subscriptions/notification subscriptions/ I don't know if there are XML rules that would prohibit it, but I recommend putting any type definitions before the elements that use them, to avoid forward references. Since you might be importing types as well, this keeps all the type information together at the beginning of the schema. 4) in schema:location, what is the difference between a network device and a network location? I suggest that people writing proposals consider adding some comments to separate the portions of the schemas so people can find portions they want to find, without having to parse the XSD or use grep. Section 2 talks about a list of supported schemas, and includes a element. Is that element defined in this XSD someplace? Is the following valid XML syntax? s/netcponf/netconf/ 5) Throughout this (and any other data modeling document) it would be helpful to have reference clauses that indicate where the concept is defined in the Netconf RFC, or whatever. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 30 06:32:47 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12CDF3A6C18; Wed, 30 Apr 2008 06:32:47 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 846913A6B86 for ; Wed, 30 Apr 2008 06:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4wXx+pA+bGJ for ; Wed, 30 Apr 2008 06:24:55 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 053E63A6DE9 for ; Wed, 30 Apr 2008 06:24:54 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA10.westchester.pa.mail.comcast.net with comcast id KoB01Z00G0vyq2s5A07300; Wed, 30 Apr 2008 13:23:38 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA05.westchester.pa.mail.comcast.net with comcast id KpQw1Z0074HwxpC3R00000; Wed, 30 Apr 2008 13:24:56 +0000 X-Authority-Analysis: v=1.0 c=1 a=8jI9oDXYVr7kF9FuqWYA:9 a=9HLs96QzjXThmhUYVPNX2yiBfWcA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Wed, 30 Apr 2008 09:24:56 -0400 Message-ID: <013801c8aac5$953225b0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciqxZTh4vo937PbQ+OnQxdSzuLh5A== X-Mailman-Approved-At: Wed, 30 Apr 2008 06:32:46 -0700 Subject: [Netconf] review of monitoring-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, [This was stuck in my outgoing queue for a while; I've had a few problems with email delivery.] I have reviewed this document and have comments. First, kudos for including front matter that explained what the schema would contain. Thank you, thank you, thank you! 1) should session monitoring include logoutTime? It might be useful to operators to know what sessions existed, say, earlier in the day, when some configuration change occurred. How long could have a default value that could be manipulated by an administrator based on company policies or environmental conditions (e.g. location and sensitivity of the managed device) 2) configurations:lockStatus - will this support partially locked? 3) under subscriptions: s/ all notifications subscriptions/notification subscriptions/ I don't know if there are XML rules that would prohibit it, but I recommend putting any type definitions before the elements that use them, to avoid forward references. Since you might be importing types as well, this keeps all the type information together at the beginning of the schema. 4) in schema:location, what is the difference between a network device and a network location? I suggest that people writing proposals consider adding some comments to separate the portions of the schemas so people can find portions they want to find, without having to parse the XSD or use grep. Section 2 talks about a list of supported schemas, and includes a element. Is that element defined in this XSD someplace? Is the following valid XML syntax? s/netcponf/netconf/ 5) Throughout this (and any other data modeling document) it would be helpful to have reference clauses that indicate where the concept is defined in the Netconf RFC, or whatever. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 30 11:27:06 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 969283A6B5C; Wed, 30 Apr 2008 11:27:06 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324693A6B5C for ; Wed, 30 Apr 2008 11:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVOHflgN9isV for ; Wed, 30 Apr 2008 11:27:04 -0700 (PDT) Received: from zrtps0kn.us.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 317BA3A6AC8 for ; Wed, 30 Apr 2008 11:27:03 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3UIQuu18814; Wed, 30 Apr 2008 18:26:56 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 14:26:50 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41453A06A@zcarhxm2.corp.nortel.com> In-Reply-To: <002601c8a955$94b1be50$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue X: replaying replay Thread-Index: AcimvrMrXzXOTnPHR/aAHTaGvW08kQAFu8fQAQYPUpA= References: <019601c8a5b8$bd8b7d20$0600a8c0@china.huawei.com> <002601c8a955$94b1be50$0600a8c0@china.huawei.com> From: "Sharon Chisholm" To: "David B Harrington" , "Bert Wijnen - IETF" , Subject: Re: [Netconf] Issue X: replaying replay X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Inline -----Original Message----- From: David B Harrington [mailto:dbharrington@comcast.net] Sent: Monday, April 28, 2008 1:31 PM To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org Subject: Issue X: replaying replay 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." I'm fine with this change -- 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? 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 netconf-bounces@ietf.org Wed Apr 30 11:27:06 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 969283A6B5C; Wed, 30 Apr 2008 11:27:06 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324693A6B5C for ; Wed, 30 Apr 2008 11:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVOHflgN9isV for ; Wed, 30 Apr 2008 11:27:04 -0700 (PDT) Received: from zrtps0kn.us.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 317BA3A6AC8 for ; Wed, 30 Apr 2008 11:27:03 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3UIQuu18814; Wed, 30 Apr 2008 18:26:56 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 14:26:50 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41453A06A@zcarhxm2.corp.nortel.com> In-Reply-To: <002601c8a955$94b1be50$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue X: replaying replay Thread-Index: AcimvrMrXzXOTnPHR/aAHTaGvW08kQAFu8fQAQYPUpA= References: <019601c8a5b8$bd8b7d20$0600a8c0@china.huawei.com> <002601c8a955$94b1be50$0600a8c0@china.huawei.com> From: "Sharon Chisholm" To: "David B Harrington" , "Bert Wijnen - IETF" , Subject: Re: [Netconf] Issue X: replaying replay X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi Inline -----Original Message----- From: David B Harrington [mailto:dbharrington@comcast.net] Sent: Monday, April 28, 2008 1:31 PM To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org Subject: Issue X: replaying replay 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." I'm fine with this change -- 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? 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. -- I sent a separate mail discussing the access control CLR issue I raised. dbh _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ase protocol specifications. We could add some references to these documents if you feel it would help. -- I sent a separate mail discussing the access control CLR issue I raised. dbh _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 30 11:41:35 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABE9B3A6A3F; Wed, 30 Apr 2008 11:41:35 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABDD73A6C63 for ; Wed, 30 Apr 2008 11:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sonH4akw+isp for ; Wed, 30 Apr 2008 11:41:33 -0700 (PDT) Received: from zrtps0kn.us.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id A88E73A689D for ; Wed, 30 Apr 2008 11:41:11 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3UIf0u20395; Wed, 30 Apr 2008 18:41:01 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 14:39:08 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41453A0CF@zcarhxm2.corp.nortel.com> In-Reply-To: <008001c8aa04$cf575f60$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue X: access to notification content Thread-Index: AcipxBH0kMvr5BmcS5aFraZBNk9y+wAP94mQADtKvvA= References: <002001c8a955$4de644f0$0600a8c0@china.huawei.com> <008001c8aa04$cf575f60$0600a8c0@china.huawei.com> From: "Sharon Chisholm" To: "David B Harrington" , "Bert Wijnen - IETF" , Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org 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:dbharrington@comcast.net] Sent: Tuesday, April 29, 2008 10:25 AM To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org 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." This does not create a CLR. dbh > -----Original Message----- > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > Sent: Tuesday, April 29, 2008 2:41 AM > To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > Subject: RE: Issue X: access to notification content > > 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 > > > -----Oorspronkelijk bericht----- > > Van: David B Harrington [mailto:dbharrington@comcast.net] > > Verzonden: maandag 28 april 2008 19:28 > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > > Onderwerp: Issue X: access to notification content > > > > > > 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 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 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 > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 30 11:41:35 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABE9B3A6A3F; Wed, 30 Apr 2008 11:41:35 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABDD73A6C63 for ; Wed, 30 Apr 2008 11:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sonH4akw+isp for ; Wed, 30 Apr 2008 11:41:33 -0700 (PDT) Received: from zrtps0kn.us.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id A88E73A689D for ; Wed, 30 Apr 2008 11:41:11 -0700 (PDT) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m3UIf0u20395; Wed, 30 Apr 2008 18:41:01 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 14:39:08 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B41453A0CF@zcarhxm2.corp.nortel.com> In-Reply-To: <008001c8aa04$cf575f60$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue X: access to notification content Thread-Index: AcipxBH0kMvr5BmcS5aFraZBNk9y+wAP94mQADtKvvA= References: <002001c8a955$4de644f0$0600a8c0@china.huawei.com> <008001c8aa04$cf575f60$0600a8c0@china.huawei.com> From: "Sharon Chisholm" To: "David B Harrington" , "Bert Wijnen - IETF" , Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org 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:dbharrington@comcast.net] Sent: Tuesday, April 29, 2008 10:25 AM To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); netconf@ietf.org 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." This does not create a CLR. dbh > -----Original Message----- > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > Sent: Tuesday, April 29, 2008 2:41 AM > To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > Subject: RE: Issue X: access to notification content > > 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 > > > -----Oorspronkelijk bericht----- > > Van: David B Harrington [mailto:dbharrington@comcast.net] > > Verzonden: maandag 28 april 2008 19:28 > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > > Onderwerp: Issue X: access to notification content > > > > > > 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 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 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 > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Apr 30 14:53:02 2008 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20F03A6965; Wed, 30 Apr 2008 14:53:02 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 702C63A6903 for ; Wed, 30 Apr 2008 14:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAhCutrlGR0B for ; Wed, 30 Apr 2008 14:53:00 -0700 (PDT) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id 7DFD73A6965 for ; Wed, 30 Apr 2008 14:52:57 -0700 (PDT) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id Kv8A1Z00K0cQ2SLA30Fu00; Wed, 30 Apr 2008 21:49:51 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id Kxsl1Z0034HwxpC8W00000; Wed, 30 Apr 2008 21:52:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=HHmwR-jtwyEA:10 a=Vu4nIF-vJQAA:10 a=9dwUbw3urem4IJIprQ0A:9 a=HwLIhY-HGXWuSlw5A8QA:7 a=s4LvpjutM27kJXizfJdvxPnqDWYA:4 a=ZPn7O4N2MpQA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=jFPUFpGHtmAA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Sharon Chisholm'" , "'Bert Wijnen - IETF'" , References: <002001c8a955$4de644f0$0600a8c0@china.huawei.com> <008001c8aa04$cf575f60$0600a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B41453A0CF@zcarhxm2.corp.nortel.com> Date: Wed, 30 Apr 2008 17:52:45 -0400 Message-ID: <002401c8ab0c$86c4f0b0$6502a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41453A0CF@zcarhxm2.corp.nortel.com> Thread-Index: AcipxBH0kMvr5BmcS5aFraZBNk9y+wAP94mQADtKvvAABsEUIA== Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org 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 > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortel.com] > Sent: Wednesday, April 30, 2008 2:39 PM > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > Subject: RE: Issue X: access to notification content > > 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 netconf-bounces@ietf.org Wed Apr 30 14:53:02 2008 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20F03A6965; Wed, 30 Apr 2008 14:53:02 -0700 (PDT) X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 702C63A6903 for ; Wed, 30 Apr 2008 14:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAhCutrlGR0B for ; Wed, 30 Apr 2008 14:53:00 -0700 (PDT) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id 7DFD73A6965 for ; Wed, 30 Apr 2008 14:52:57 -0700 (PDT) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id Kv8A1Z00K0cQ2SLA30Fu00; Wed, 30 Apr 2008 21:49:51 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id Kxsl1Z0034HwxpC8W00000; Wed, 30 Apr 2008 21:52:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=HHmwR-jtwyEA:10 a=Vu4nIF-vJQAA:10 a=9dwUbw3urem4IJIprQ0A:9 a=HwLIhY-HGXWuSlw5A8QA:7 a=s4LvpjutM27kJXizfJdvxPnqDWYA:4 a=ZPn7O4N2MpQA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=jFPUFpGHtmAA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Sharon Chisholm'" , "'Bert Wijnen - IETF'" , References: <002001c8a955$4de644f0$0600a8c0@china.huawei.com> <008001c8aa04$cf575f60$0600a8c0@china.huawei.com> <713043CE8B8E1348AF3C546DBE02C1B41453A0CF@zcarhxm2.corp.nortel.com> Date: Wed, 30 Apr 2008 17:52:45 -0400 Message-ID: <002401c8ab0c$86c4f0b0$6502a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B41453A0CF@zcarhxm2.corp.nortel.com> Thread-Index: AcipxBH0kMvr5BmcS5aFraZBNk9y+wAP94mQADtKvvAABsEUIA== Subject: Re: [Netconf] Issue X: access to notification content X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org 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 > -----Original Message----- > From: Sharon Chisholm [mailto:schishol@nortel.com] > Sent: Wednesday, April 30, 2008 2:39 PM > To: David B Harrington; Bert Wijnen - IETF; netconf@ietf.org > Subject: RE: Issue X: access to notification content > > 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----- > Fro > From: David B Harrington [mailto:dbharrington@comcast.net] > Sent: Tuesday, April 29, 2008 10:25 AM > To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); > netconf@ietf.org > 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." > > This does not create a CLR. > > dbh > > > -----Original Message----- > > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > > Sent: Tuesday, April 29, 2008 2:41 AM > > To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > 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 > > > > > -----Oorspronkelijk bericht----- > > > Van: David B Harrington [mailto:dbharrington@comcast.net] > > > Verzonden: maandag 28 april 2008 19:28 > > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > > > Onderwerp: Issue X: access to notification content > > > > > > > > > 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 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 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 > > > > > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf m: David B Harrington [mailto:dbharrington@comcast.net] > Sent: Tuesday, April 29, 2008 10:25 AM > To: 'Bert Wijnen - IETF'; Chisholm, Sharon (CAR:ZZ00); > netconf@ietf.org > 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." > > This does not create a CLR. > > dbh > > > -----Original Message----- > > From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] > > Sent: Tuesday, April 29, 2008 2:41 AM > > To: David B Harrington; 'Sharon Chisholm'; netconf@ietf.org > > Subject: RE: Issue X: access to notification content > > > > 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 > > > > > -----Oorspronkelijk bericht----- > > > Van: David B Harrington [mailto:dbharrington@comcast.net] > > > Verzonden: maandag 28 april 2008 19:28 > > > Aan: 'Bert Wijnen - IETF'; 'Sharon Chisholm'; netconf@ietf.org > > > Onderwerp: Issue X: access to notification content > > > > > > > > > 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 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 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 > > > > > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf