Subject: [Netconf] comments on netconf-monitoring-03 draft

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Feb 2009 09:35:04 -0800

Hi,

I have some initial comments, not sure if they
are already resolved or not:

  1) bug: top of pg 16, example
     <rpc> start-tag paired with </rpc-reply> end-tag

  2) netconf container
     What about renaming it to 'netconf-state'?
     IMO this sets a clear and workable precedent.
     Use 1 top-level element with the same name as
     the YANG module.  It also solves the problem of
     a read-only vs. read-write /netconf container.

  3) <capabilities>
     Should this element be the exact capabilities given
     in the <hello> or should the netconf namespace be
     changed to the netconf-state namespace (as the draft
     defines now)? IMO it is confusing and code which
     understands the <hello> cannot be reused to handle
     the netconf-state data-model.

  4) static <configuration> elements
     I assume there will be always be an entry for each of the
     3 databases supported by the agent. I.e., at least one
     entry for <running>.  Adding and deleting these based
     on the current state of the locks would complicate things.

  5) empty <locks/> OK?
     It seems useful and convenient to be able to return
     an empty locks container, especially if there are
     lots of partial locks or a big database.
     An implementation should not need to search out all
     the partial locks twice (w/ added race condition) to
     make sure there really is at least 1 partial lock to report.

  6) session drops
     a) The inBadHellos object should mention that sessions
        dropped because a <hello> was never received are also
        included in this counter.
     b) should there be an 'abnormalTerminations' counter
        to count any sessions terminated for an abnormal
        reason (i.e., other than close-session, kill-session,
        already counted in inBadHellos)
     c) should transport connection drops by the manager be
        counted in any way?

  7) usage statistics
     There is no total bytes counters, only message counters.
     Is this on purpose?  Were usage statistics rejected?

  8) per-session statistics
     There are none.  Is it worth it to add them, perhaps
     as an additional capability?  Perhaps more than one session
     is active at the same time.  The global counters
     will not give a clean view of the problem, and be useless.

  9) get-schema RPC operation
     The positive and negative response parts of the template are
     missing.  What errors are to be expected?  Is it operation-failed
     if the module name/revision are not found?  What if the requested
     format is not available?

10) User name
     This field is fairly vague, which matches the NETCONF architecture
     wrt/ this subject.  What is the 'owner'?  Should there be
     some more text here?  This is going to show up later
     for access control work, so might as well get it correct now.

11) Documentation style
     I really like the 'info-model' style of documentation much
     better than the MIB style.  It is easy to read and easy to
     find stuff.  I hope all NETCONF data model drafts follow this style.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 28 Feb 2009 09:24:12 -0800

Hi,

Remove issue (5) from the list.
I realized that 'locks' is a non-presence container
so it must not be returned if it is empty.

3 more comments on counters:

14) The counter conditions are specific -- that's good,
     except inBadRpcs.  The words 'parsed correctly'
     implies well-formed XML.  If so, then another
     counter should be added for invalid XML messages received.

15) Is inRpcs == outRpcReplies always true?
     If not, why not?  (If yes, why do both counters exist?)

16) Is inBadRpcs == outRpcErrors always true?
     If not, why not?  (If yes, why do both counters exist?)

Andy

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
> 
> 

Date: Tue, 03 Feb 2009 21:18:32 +0100 (CET)
To: [email-masked]
From: Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] error info none

Juergen Schoenwaelder <[email-masked]> wrote:
> Appendix A defines the NETCONF error list and it sometimes says:
> 
>    Error-info:  none
> 
> What is the interpretation of this? Does it mean an implementation
> MUST not generate an error-info or does it mean an implementation MAY
> generate an error-info at its discretion but is not required to do so?

I hope it is the latter ;-)  I don't see how a MUST NOT could be
warranted, i.e. I don't see how including an error-info would hurt
interoperability.

Currently, the 'invalid-value' error says "Error-info: none".  In my
code, I generate a 'bad-element' error-info.  But maybe this should be
viewed as a bug in the spec - an 'invalid-value' error that does not
specify which element contains the invalid value is not very
useful...

I have never quite understood if an Appendix is non-normative or
normative if it isn't spelled out.  Shouldn't this list be normative?

/martin

Date: Tue, 03 Feb 2009 13:52:36 -0800
From: Andy Bierman <[email-masked]>
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] error info none

Martin Bjorklund wrote:
> Juergen Schoenwaelder <[email-masked]> wrote:
>> Appendix A defines the NETCONF error list and it sometimes says:
>>
>>    Error-info:  none
>>
>> What is the interpretation of this? Does it mean an implementation
>> MUST not generate an error-info or does it mean an implementation MAY
>> generate an error-info at its discretion but is not required to do so?
> 
> I hope it is the latter ;-)  I don't see how a MUST NOT could be
> warranted, i.e. I don't see how including an error-info would hurt
> interoperability.
> 
> Currently, the 'invalid-value' error says "Error-info: none".  In my
> code, I generate a 'bad-element' error-info.  But maybe this should be
> viewed as a bug in the spec - an 'invalid-value' error that does not
> specify which element contains the invalid value is not very
> useful...
> 
> I have never quite understood if an Appendix is non-normative or
> normative if it isn't spelled out.  Shouldn't this list be normative?
> 
> 

I can tell you that the intent of the WG at the time
was to specify which standard error-info elements
must be present.  The intent of the WG was always
that error-info was like SNMPv2 NOTIFICATION VARBINDS.
A vendor is free to add additional info to the end
of the standard list.

> /martin

Andy

From: IESG Secretary <[email-masked]>
To: IETF Announcement list <[email-masked]>
Date: Tue,  3 Feb 2009 14:17:27 -0800 (PST)
Cc: [email-masked]
Subject: [Netconf] WG Action: RECHARTER: Network Configuration (netconf)

The Network Configuration (netconf) working group in the Operations and
Management Area of the IETF has been rechartered.  For additional
information, please contact the Area Directors or the working group
Chairs.

Network Configuration (netconf) 
================================ 

Current Status: Active Working Group

Last Modified: 2008-12-16

Additional information is available at tools.ietf.org/wg/netconf

Chair(s):
Bert Wijnen <[email-masked]>
Mehmet Ersue <[email-masked]>

Operations and Management Area Director(s):
Dan Romascanu <[email-masked]>
Ronald Bonica <[email-masked]>

Operations and Management Area Advisor:
Dan Romascanu <[email-masked]>

Technical Advisor(s):
Charlie Kaufman <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked]
In Body: in msg body: subscribe
Archive: http://www.ietf.org/mail-archive/web/netconf/

Description of Working Group:
Charlie Kaufman is Technical Advisor for Security Matters

Configuration of networks of devices has become a critical requirement
for operators in today's highly interoperable networks. Operators from
large to small have developed their own mechanisms or used vendor
specific mechanisms to transfer configuration data to and from a
device, and for examining device state information which may impact
the configuration. Each of these mechanisms may be different in
various aspects, such as session establishment, user authentication,
configuration data exchange, and error responses.

The NETCONF Working Group is chartered to produce a protocol suitable
for network configuration, with the following characteristics:

- Provides retrieval mechanisms which can differentiate between
  configuration data and non-configuration data
- Is extensible enough so that vendors will provide access to all
  configuration data on the device using a single protocol
- Has a programmatic interface (avoids screen scraping and
  formatting-related changes between releases)
- Uses a textual data representation, that can be easily manipulated
  using non-specialized text manipulation tools.
- Supports integration with existing user authentication methods
- Supports integration with existing configuration database systems
- Supports network wide configuration transactions (with features such
  as locking and rollback capability)
- Is as transport-independent as possible
- Provides support for asynchronous notifications.

The NETCONF protocol is using XML for data encoding purposes, because
XML is a widely deployed standard which is supported by a large number
of applications.

The NETCONF protocol should be independent of the data definition
language and data models used to describe configuration and state
data.

However, the authorization model used in the protocol is dependent on
the data model. Although these issues must be fully addressed to
develop standard data models, only a small part of this work will be
initially addressed. This group will specify requirements for standard
data models in order to fully support the NETCONF protocol, such as:

- identification of principals, such as user names or distinguished names
- mechanism to distinguish configuration from non-configuration data
- XML namespace conventions
- XML usage guidelines

The initial work started in 2003 and has already been completed and was
restricted to following items:

  a) NETCONF Protocol Specification, which defines the operational model,

     protocol operations, transaction model, data model requirements,
     security requirements, and transport layer requirements.
  b) NETCONF over SSH Specification: Implementation Mandatory,
  c) NETCONF over BEEP Specification: Implementation Optional,
  d) NETCONF over SOAP Specification: Implementation Optional.

  These documents define how the NETCONF protocol is used with each
  transport protocol selected by the working group, and how it meets
  the security and transport layer requirements of the NETCONF Protocol
  Specification.

  e) NETCONF Notification Specification, which defines mechanisms that
     provide an asynchronous message notification delivery service for
     the NETCONF protocol.  NETCONF Notification is an optional
     capability built on top of the base NETCONF definition and
     provides the capabilities and operations necessary to support
     this service.

  The NETCONF notification specification has been finished now as well.

In the current phase of the incremental development of NETCONF the
workgroup will focus on following items:

1. Fine-grain locking: The base NETCONF protocol only provides a lock
   for the entire configuration datastore, which is not deemed to meet
   important operational and security requirements. The NETCONF working
   group will produce a standards-track RFC specifying a mechanism for
   fine-grain locking of the NETCONF configuration datastore.

2. NETCONF monitoring: It is considered best practice for IETF working
   groups to include management of their protocols within the scope of
   the solution they are providing. The NETCONF working group will
   produce a standards-track RFC with mechanisms allowing NETCONF
   itself to be used to monitor some aspects of NETCONF operation.

3. Schema advertisement: Currently the NETCONF protocol is able to
   advertise which protocol features are supported on a particular
   netconf-capable device. However, there is currently no way to discover
   which XML Schema are supported on the device. The NETCONF working
   group will produce a standards-track RFC with mechanisms making this
   discovery possible (this item may be merged with "NETCONF monitoring"
   into a single document).

   Note: The schema-advertisement material has been merged into the
   NETCONF monitoring document based on WG consensus.

4. NETCONF over TLS: Based on implementation experience there is a
   need for a standards track document to define NETCONF over TLS as an
   optional transport for the NETCONF protocol.

5. NETCONF default handling: NETCONF today does not define whether
   default values should be returned by the server in replies
   to requests for reading configuration and state data. Different
   clients have different needs to receive or not to receive
   default data. The NETCONF working group will produce a
   standards-track RFC defining a mechanism that allows
   NETCONF clients to control whether default data is returned
   by the netconf server.

6. NETCONF implementations have shown that the specification in RFC4741
   is not 100% clear and has lead to different interpretations and
implementations. 
   Also some errors have been uncovered. So the WG will do an rfc4741bis
with
   following constraints:

     - bug fixes are to be done
     - clarifications can be done
     - extensions can be done only when needed to fix bugs 
       or inconsistencies (i.e. we are not doing a NETCONF V2)
     - The work can be started based on the discussion in IETF #73 (see
        http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf).

   Note: A technical errata has been posted on rfc4742. If the work on
   rfc4741bis uncovers any additional fixes/clarifications that need
   to be made to rfc4742, the WG may consider to also do a rfc4742bis
   as part of this work-item.

The following items have been identified as important but are currently
not considered in scope for re-chartering and may be candidates for work
when there is community consensus to take them on:

- NETCONF Notification content
- Access Control requirements
- NETCONF access to SMI-based MIB data

Goals and Milestones:
Done   Working Group formed
Done   Submit initial Netconf Protocol draft
Done   Submit initial Netconf over (transport-TBD) draft
Done   Begin Working Group Last Call for the Netconf Protocol draft
Done   Begin Working Group Last Call for the Netconf over (transport-TBD)
            draft
Done Submit   final version of the Netconf Protocol draft to the IESG
Done   Submit final version of the Netconf over SOAP draft to the IESG
Done   Submit final version of the Netconf over BEEP draft to the IESG
Done   Submit final version of the Netconf over SSH draft to the IESG
Done   Update charter
Done   Submit first version of NETCONF Notifications document
Done   Begin WGLC of NETCONF Notifications document
Done   Submit final version of NETCONF Notifications document to IESG
            for consideration as Proposed Standard
Done   -00 draft for fine Grain Locking
Done   -00 draft for NETCONF over TLS
Done   -00 draft for NETCONF Monitoring
Done   -00 draft for Schema Advertisement
Done   Early Review of client authentication approach (for NETCONF over
            TLS) with the security community at IETF 71
N.A.     WG Last Call on Schema Advertisement after IETF72
            Schema Advertisement has been merged into Monitoring
Done    WG Last Call on NETCONF over TLS after IETF72
Done    Netconf over TLS to IESG for consideration as Proposed Standards
Dec 2008  WG Last Call on Fine Grain Locking after IETF73
Dec 2008  Send Partial Locking to IESG for consideration as Proposed
Standards
Jan 2009   Initial WG draft for with-defaults capability
Feb 2009   Initial WG draft for rfc4741bis
Mar 2009   WG Last Call on NETCONF Monitoring after IETF73
Apr 2009   WG Last Call on rfc4741bis
Apr 2009   WG Last Call on with-defaults
Jun 2009   rfc4741bis to IESG for considerations as Proposed Standard
Jun 2009   with-defaults capability to IESG for considerations as Proposed
Standard

From: "Bert Wijnen \(IETF\)" <[email-masked]>
To: "Netconf" <[email-masked]>
Date: Wed, 4 Feb 2009 12:07:40 +0100
Organization: Consultant
Subject: [Netconf] WGLC for draft-ietf-netconf-monitoring-03.txt

This is a multi-part message in MIME format.

------=_NextPart_000_0999_01C986C1.2D1AA1E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Over the last few weeks we have seen some comments psoted w.r.t. this =
draft.
However, we NEED more input from as many WG participants as possible.

So this is a WG Last Call fro this document. End of WGLC is 18 feb 2009.

The document is intended to go for standards track.

Bert and Mehmet
------=_NextPart_000_0999_01C986C1.2D1AA1E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6001.18183" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Over the last few weeks we have seen some comments =
psoted=20
w.r.t. this draft.</FONT></DIV>
<DIV><FONT size=3D2>However, we NEED more input from as many WG =
participants as=20
possible.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>So this is a WG Last Call fro this document. End of =
WGLC is 18=20
feb 2009.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>The document is intended to go for standards=20
track.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Bert and Mehmet</FONT></DIV></BODY></HTML>

------=_NextPart_000_0999_01C986C1.2D1AA1E0--

Content-class: urn:content-classes:message
Date: Wed, 4 Feb 2009 17:31:38 +0100
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: "Balazs Lengyel" <[email-masked]>, "Martin Bjorklund" <[email-masked]>
Cc: [email-masked]
Subject: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05

This is a multi-part message in MIME format.

------_=_NextPart_001_01C986E6.0D673EEA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Balazs, Martin,
=20
I'm sorry I couldn't come to the partial lock draft earlier.
=20
- The XSD is valid.
=20
But I have some questions concerning XML schema, though:
=20
- Why is the count of PartialLock targets is limited to '3' ?
AFAIK a Netconf client may also define new datastores other=20
than <running>, <candidate> and <startup>.
=20
- The "target" element in the "partial-lock" elements allows to=20
repeat 1 to 3 times any of the "startup"/"candidate"/"running",
so i.e. also 3 times the same. Is this a schema design issue?
=20
- I am not sure whether datastore names should be each=20
individually in a target node. The following XML snippet ...
=20
<partial-lock xmlns=3D"urn:ietf:params:xml:ns:netconf:partial-lock:1.0"=20

xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"=20

xsi:schemaLocation=3D"urn:ietf:params:xml:ns:netconf:partial-lock:1.0=20

C:\Partial_Lock_05.xsd">

            <target/>

                        <target>

                            <candidate/>

                        </target>

                        <target>

                            <candidate/>

                        </target>

            <select/>

</partial-lock>

is accepted by XMLSpy as valid with regard to the partial lock=20
schema.=20
OTOH the description says: "Each target element MUST contain=20
a different datastore name."

- The schema requires that in "startup"/"candidate"/"running"
elements belonging to "contentPartInPartialLockReplyType"
must containt at least one "locked-node" element.=20
But in the YANG module, the "locked-node" leaf lists inside=20
"startup"/"candidate"/"running" containers do not contain a=20
"min-elements 1;" statement, so the containers may be empty,
which differs from XSD.

Cheers,
Mehmet=20

=20

------_=_NextPart_001_01C986E6.0D673EEA
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D762250418-03022009><FONT =
face=3DVerdana=20
color=3D#0000ff size=3D2>Hi Balazs, Martin,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D762250418-03022009><FONT =
face=3DVerdana=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D762250418-03022009><FONT =
face=3DVerdana=20
color=3D#0000ff size=3D2>I'm sorry I couldn't come to the partial lock =
draft=20
earlier.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D762250418-03022009><FONT =
face=3DVerdana=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D762250418-03022009><FONT =
face=3DVerdana=20
color=3D#0000ff size=3D2>- The XSD is valid.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D762250418-03022009><FONT =
face=3DVerdana=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D762250418-03022009><FONT =
face=3DVerdana=20
color=3D#0000ff size=3D2>But I have some questions concerning XML =
schema,=20
though:</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D762250418-03022009><FONT =
face=3DVerdana=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D762250418-03022009><FONT =
face=3DVerdana=20
color=3D#0000ff size=3D2>- Why is the count of PartialLock targets is =
limited to '3'=20
?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D762250418-03022009><FONT =
face=3DVerdana=20
color=3D#0000ff size=3D2>AFAIK a Netconf client may also define new =
datastores=20
</FONT></SPAN><SPAN class=3D762250418-03022009><FONT =
color=3D#0000ff><FONT=20
face=3DVerdana size=3D2>other </FONT></FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D762250418-03022009><FONT =
color=3D#0000ff><FONT=20
face=3DVerdana size=3D2>than </FONT><FONT face=3DVerdana =
size=3D2>&lt;running&gt;,=20
&lt;candidate&gt; and &lt;startup&gt;.</FONT></FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D762250418-03022009><FONT =
face=3DVerdana=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D762250418-03022009><FONT =
face=3DVerdana=20
color=3D#0000ff size=3D2>- <FONT color=3D#0000ff size=3D2>The "target" =
element in the=20
"partial-lock" elements allows to </FONT></FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D762250418-03022009><FONT =
face=3DVerdana=20
color=3D#0000ff size=3D2><FONT color=3D#0000ff size=3D2>repeat 1 to 3 =
times any of the=20
"startup"/"candidate"/"running",</FONT></FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D762250418-03022009><FONT =
face=3DVerdana=20
color=3D#0000ff size=3D2><FONT color=3D#0000ff size=3D2>so i.e. also 3 =
times the same.=20
Is this </FONT></FONT></SPAN><SPAN class=3D762250418-03022009><FONT =
face=3DVerdana=20
color=3D#0000ff size=3D2><FONT color=3D#0000ff size=3D2>a schema=20
</FONT></FONT></SPAN><SPAN class=3D762250418-03022009><FONT =
face=3DVerdana=20
color=3D#0000ff size=3D2><FONT color=3D#0000ff size=3D2>design=20
issue?</FONT></FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D762250418-03022009><FONT =
face=3DVerdana=20
color=3D#0000ff size=3D2><FONT color=3D#0000ff=20
size=3D2></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D762250418-03022009><FONT =
face=3DVerdana=20
color=3D#0000ff size=3D2><FONT color=3D#0000ff size=3D2>- <FONT =
color=3D#0000ff size=3D2>I=20
am not sure </FONT></FONT></FONT></SPAN><SPAN =
class=3D762250418-03022009><FONT=20
face=3DVerdana color=3D#0000ff size=3D2><FONT color=3D#0000ff =
size=3D2><FONT color=3D#0000ff=20
size=3D2>whether datastore names should be each <BR>individually in=20
</FONT></FONT></FONT></SPAN><SPAN class=3D762250418-03022009><FONT=20
color=3D#0000ff><FONT color=3D#0000ff><FONT color=3D#0000ff><FONT =
face=3DVerdana=20
size=3D2>a target node. The following XML snippet=20
...</FONT></FONT></FONT></FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D762250418-03022009><FONT =
color=3D#0000ff><FONT=20
color=3D#0000ff><FONT color=3D#0000ff><FONT face=3DVerdana=20
size=3D2></FONT></FONT></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D762250418-03022009><FONT =
color=3D#0000ff><FONT=20
color=3D#0000ff><FONT color=3D#0000ff>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; mso-layout-grid-align: none"><FONT =
face=3DArial><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">&lt;</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: maroon; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">partial-lock</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: red; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">=20
xmlns</SPAN><SPAN lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">=3D"</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: black; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">urn:ietf:params:xml:ns:netconf:partial-lock:1.0</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">"</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: red; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">=20
</SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; mso-layout-grid-align: none"><FONT =
face=3DArial><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: red; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">xmlns:xsi</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">=3D"</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: black; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">http://www.w3.org/2001/XMLSchema-instance</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">"</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: red; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">=20
</SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; mso-layout-grid-align: none"><FONT =
face=3DArial><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: red; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">xsi:schemaLocation</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">=3D"</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: black; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">urn:ietf:params:xml:ns:netconf:partial-lock:1.0=20
</SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; mso-layout-grid-align: none"><FONT =
face=3DArial><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: black; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">C:\Partial_Lock_05.xsd</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">"&gt;</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: black; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE"><o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; mso-layout-grid-align: none"><FONT =
face=3DArial><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: black; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE"><SPAN=20
style=3D"mso-tab-count: =
1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN><SPAN lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">&lt;</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: maroon; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">target</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">/&gt;</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: black; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE"><o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; mso-layout-grid-align: none"><FONT =
face=3DArial><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: black; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE"><SPAN=20
style=3D"mso-tab-count: =
2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN><SPAN lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">&lt;</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: maroon; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">target</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">&gt;</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: black; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE"><o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; mso-layout-grid-align: none"><FONT =
face=3DArial><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: black; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN><SPAN=20
style=3D"mso-tab-count: =
2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></SPAN><SPAN =
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">&lt;</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: maroon; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">candidate</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">/&gt;</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: black; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE"><o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; mso-layout-grid-align: none"><FONT =
face=3DArial><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: black; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE"><SPAN=20
style=3D"mso-tab-count: =
2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN><SPAN lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">&lt;/</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: maroon; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">target</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">&gt;</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: black; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE"><o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; mso-layout-grid-align: none"><FONT =
face=3DArial><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: black; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE"><SPAN=20
style=3D"mso-tab-count: =
2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN><SPAN lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">&lt;</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: maroon; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">target</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">&gt;</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: black; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE"><o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; mso-layout-grid-align: none"><FONT =
face=3DArial><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: black; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE"><SPAN=20
style=3D"mso-tab-count: =
2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; =
</SPAN></SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">&lt;</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: maroon; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">candidate</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">/&gt;</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: black; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE"><o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; mso-layout-grid-align: none"><FONT =
face=3DArial><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: black; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE"><SPAN=20
style=3D"mso-tab-count: =
2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN><SPAN lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">&lt;/</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: maroon; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">target</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">&gt;</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: black; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE"><o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; mso-layout-grid-align: none"><FONT =
face=3DArial><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: black; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE"><SPAN=20
style=3D"mso-tab-count: =
1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN><SPAN lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">&lt;</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: maroon; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">select</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">/&gt;</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: black; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE"><o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; mso-layout-grid-align: none"><FONT =
face=3DArial><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">&lt;/</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: maroon; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">partial-lock</SPAN><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; BACKGROUND: white; COLOR: blue; =
mso-bidi-font-family: Arial; mso-highlight: white; mso-ansi-language: =
DE">&gt;</SPAN></FONT><SPAN=20
lang=3DDE=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; mso-bidi-font-family: Arial; =
mso-ansi-language: DE"><o:p></o:p></SPAN></P></DIV></FONT>
<P dir=3Dltr align=3Dleft><FONT face=3DVerdana><FONT size=3D2><SPAN=20
class=3D762250418-03022009>i</SPAN>s accepted by XMLSpy as valid with =
regard to=20
the partial lock <BR>schema.&nbsp;<BR><SPAN =
class=3D762250418-03022009>OTOH the=20
description says: "E</SPAN></FONT></FONT><FONT face=3DVerdana><FONT =
size=3D2>ach=20
target element MUST contain <BR>a different<SPAN =
class=3D762250418-03022009>=20
</SPAN>datastore name.<SPAN =
class=3D762250418-03022009>"</SPAN></FONT></FONT></P>
<P dir=3Dltr align=3Dleft><SPAN class=3D762250418-03022009><FONT =
face=3DVerdana size=3D2>-=20
The schema requires that in "startup"/"candidate"/"running"<BR>elements=20
belonging to "contentPartInPartialLockReplyType"<BR>must containt at =
least one=20
"locked-node" element. <BR></FONT></SPAN><SPAN =
class=3D762250418-03022009><FONT=20
face=3DVerdana size=3D2>But in the YANG module, the "locked-node" leaf =
lists inside=20
<BR></FONT></SPAN><SPAN class=3D762250418-03022009><FONT face=3DVerdana=20
size=3D2>"startup"/"candidate"/"running" containers do not contain a=20
<BR>"min-elements 1;" statement, so the containers may be =
empty,<BR>which=20
differs from XSD.<BR></FONT></SPAN><SPAN =
class=3D762250418-03022009><FONT=20
face=3DVerdana size=3D2><BR></P></FONT></SPAN></FONT></FONT></SPAN><!-- =
Converted from text/rtf format -->
<P><SPAN lang=3Dde><FONT face=3DVerdana color=3D#000080=20
size=3D2>Cheers,<BR>Mehmet</FONT></SPAN><SPAN lang=3Den-us></SPAN> </P>
<DIV><FONT face=3DVerdana color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C986E6.0D673EEA--

From: "Bert Wijnen \(IETF\)" <[email-masked]>
To: "Netconf" <[email-masked]>
Date: Wed, 4 Feb 2009 17:46:56 +0100
Organization: Consultant
Subject: [Netconf] Fw: [OPSAWG] start WGLC on draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt

This is a multi-part message in MIME format.

------=_NextPart_000_0A68_01C986F0.92A6AE80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Using my ietf user account, so the mailing list accepts my posting

Bert
----- Original Message -----=20
From: Bert Wijnen=20
To: Natale, Bob=20
Cc: [email-masked]=20
Sent: Wednesday, February 04, 2009 5:39 PM
Subject: Re: [OPSAWG] start WGLC on =
draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt

W.r.t. my second point, section 4 states:

   This document concerns only the SMI base datatypes -- i.e., the
   eleven "ObjectSyntax" datatypes defined in RFC2578.  These datatypes
   -- via tag values defined in the SMI to identify them in varbinds --
   constrain values carried "on-the-wire" in SNMP PDUs between SNMP
   management applications and SNMP agents:

And then after that colon, it lists the names of the dtaatypes as you =
define them in sect 4, namely
the names used in teh XSD.

If they refer to SMI datatype, then I would have expected OBJECT =
IDENTIFIER instead of
ObjectIdentifier and OCTET STRING instead of OctetString.

Not a big deal, but it had me put on the wrong leg at first.

By the way, in teh IANA considerations there is also text and URIs =
w.r.t.
"other 2 documents" in the "set of documents".

Bert
  ----- Original Message -----=20
  From: Natale, Bob=20
  To: Bert Wijnen (IETF)=20
  Cc: [email-masked]=20
  Sent: Wednesday, February 04, 2009 2:17 PM
  Subject: RE: [OPSAWG] start WGLC on =
draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt

  Hi Bert,

  =20

  Thanks for your comments and assessment.

  =20

  - The misspellings of "opaque" (with a "g") have been corrected.

  =20

  - The use of "datatypes" in the file name and title was, in fact, =
intended to refer to "SMI datatypes" as implied by the general usage in =
RFC 2578, Sec. 7.1, "Mapping of the Syntax Clause", to wit:

  =20

  "The SYNTAX clause, which must be present, defines the abstract data =
structure corresponding to that object.  The data structure must be one =
of the following: a base type, the BITS construct, or a textual =
convention.  (SEQUENCE OF and SEQUENCE are also possible for conceptual =
tables, see section 7.1.12).  The base types are those defined in the =
ObjectSyntax CHOICE.  A textual convention is a newly-defined type =
defined as a sub-type of a base type [3]."

  =20

  So, "datatypes" is used a bit loosely for "base types".would you =
prefer that the latter term be used?  (The document text currently makes =
it clear that it deals only with expressing the base types of RFC 2578 =
in XSD.)

  =20

  - Yes, the text that Juergen questioned is being removed (also had =
helpful guidance from David Harrington on this point), so that this =
"base types" document stands alone.

  =20

  Please confirm or clarify the second point.I will have the -05 =
version, reflecting final mods based on this last call round, ready =
immediately after expiration of the last call period (12-Feb-09).

  =20

  Cheers,

  BobN

  =20

  From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Bert Wijnen (IETF)
  Sent: Wednesday, February 04, 2009 4:57 AM
  To: [email-masked]
  Subject: Re: [OPSAWG] start WGLC =
ondraft-ietf-opsawg-smi-datatypes-in-xsd-04.txt

  =20

  My comments:

  =20

  - page 7, section 4

    - speaks about opague. I think you mean opaque (with a Q)

  =20

    You may also want to make an explicit statement that those are the =
datatype

    names as ytou specify them in XSD. I first though they were the =
datatypes

    as specified in SMIv2.

  =20

  =20

  - Opague (with a G) is again used in the 1st para of sect 5.3 and=20

     in the first bullet on page 12 and also 3rd bullet.

  =20

  I share/support Juergen Shoenwaelder's comment w.r.t. the discussion =
about 3 documents

  in a document set. Where, how is that otehr work scheduled/planned?

  =20

  Other than that, this document seems fine.

  =20

  Bert

    ----- Original Message -----=20

    From: Scott O. Bradner=20

    To: [email-masked]=20

    Sent: Friday, January 30, 2009 3:10 AM

    Subject: Re: [OPSAWG] start WGLC =
ondraft-ietf-opsawg-smi-datatypes-in-xsd-04.txt

    =20

    back on Nov 6th we sent out a WGLC on=20
    draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt

    there was no response to that last call that I can=20
    find in the mail list archive (or in my memory)

    we gotta see a bit more interest than that to proceed
    with this document. =20

    So, I'll try again=20

    this is a WGLC for draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt
    please comment (one way or the other) by Feb 12

    tnx

    Scott
    _______________________________________________
    OPSAWG mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/opsawg

------=_NextPart_000_0A68_01C986F0.92A6AE80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:x =3D=20
"urn:schemas-microsoft-com:office:excel" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:a =3D=20
"urn:schemas-microsoft-com:office:access" xmlns:dt =3D=20
"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s =3D=20
"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs =3D=20
"urn:schemas-microsoft-com:rowset" xmlns:z =3D "#RowsetSchema" xmlns:b =
=3D=20
"urn:schemas-microsoft-com:office:publisher" xmlns:ss =3D=20
"urn:schemas-microsoft-com:office:spreadsheet" xmlns:c =3D=20
"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc =3D=20
"urn:schemas-microsoft-com:office:odc" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:html =3D=20
"http://www.w3.org/TR/REC-html40" xmlns:q =3D=20
"http://schemas.xmlsoap.org/soap/envelope/" XMLNS:D =3D "DAV:" xmlns:x2 =
=3D=20
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois =3D=20
"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir =3D=20
"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds =3D=20
"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp =3D=20
"http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc =3D=20
"http://schemas.microsoft.com/data/udc" xmlns:xsd =3D=20
"http://www.w3.org/2001/XMLSchema" xmlns:sub =3D=20
"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec =
=3D=20
"http://www.w3.org/2001/04/xmlenc#" xmlns:sp =3D=20
"http://schemas.microsoft.com/sharepoint/" xmlns:sps =3D=20
"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi =3D=20
"http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs =3D=20
"http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf =3D=20
"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p =3D=20
"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf =3D=20
"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss =3D=20
"http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi =3D=20
"http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi =3D=20
"http://schemas.openxmlformats.org/package/2006/digital-signature" =
xmlns:mver =3D=20
"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m =
=3D=20
"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels =3D=20
"http://schemas.openxmlformats.org/package/2006/relationships" =
xmlns:spwp =3D=20
"http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t =3D=20
"http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m =
=3D=20
"http://schemas.microsoft.com/exchange/services/2006/messages" =
xmlns:pptsl =3D=20
"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl =
=3D=20
"http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksSe=
rvice"=20
XMLNS:Z =3D "urn:schemas-microsoft-com:" xmlns:st =3D "=01"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6001.18183" name=3DGENERATOR>
<STYLE>@font-face {
	font-family: Cambria Math;
}
@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: Verdana;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.0in 1.0in 1.0in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.EmailStyle17 {
	FONT-WEIGHT: normal; COLOR: maroon; FONT-STYLE: normal; FONT-FAMILY: =
"Verdana","sans-serif"; TEXT-DECORATION: none; mso-style-type: =
personal-reply
}
.MsoChpDefault {
	FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue bgColor=3Dwhite>
<DIV><FONT size=3D2>Using my ietf user account, so the mailing list =
accepts my=20
posting</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Bert</FONT></DIV>
<DIV style=3D"FONT: 10pt arial">----- Original Message -----=20
<DIV style=3D"BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> <A=20
title=[email-masked] href=3D"mailto:[email-masked]">Bert =
Wijnen</A>=20
</DIV>
<DIV><B>To:</B> <A title=[email-masked]=20
href=3D"mailto:[email-masked]">Natale, Bob</A> </DIV>
<DIV><B>Cc:</B> <A title=[email-masked]=20
href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
<DIV><B>Sent:</B> Wednesday, February 04, 2009 5:39 PM</DIV>
<DIV><B>Subject:</B> Re: [OPSAWG] start WGLC on=20
draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt</DIV></DIV>
<DIV><BR></DIV>
<DIV><FONT size=3D2>W.r.t. my second point, section 4 =
states:</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp; This document concerns only the SMI =
base=20
datatypes -- i.e., the<BR>&nbsp;&nbsp; eleven "ObjectSyntax" datatypes =
defined=20
in RFC2578.&nbsp; These datatypes<BR>&nbsp;&nbsp; -- via tag values =
defined in=20
the SMI to identify them in varbinds --<BR>&nbsp;&nbsp; constrain values =
carried=20
"on-the-wire" in SNMP PDUs between SNMP<BR>&nbsp;&nbsp; management =
applications=20
and SNMP agents:</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>And then after that colon, it lists the names of the =
dtaatypes=20
as you define them in sect 4, namely</FONT></DIV>
<DIV><FONT size=3D2>the names used in teh XSD.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>If they refer to SMI datatype, then I would have =
expected=20
OBJECT IDENTIFIER instead of</FONT></DIV>
<DIV><FONT size=3D2>ObjectIdentifier and OCTET STRING instead of=20
OctetString.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Not a big deal, but it had me put on the wrong leg =
at=20
first.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>By the way, in teh IANA considerations there is also =
text and=20
URIs w.r.t.</FONT></DIV>
<DIV><FONT size=3D2>"other 2 documents" in the "set of =
documents".</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Bert</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked] href=3D"mailto:[email-masked]">Natale, =
Bob</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">Bert Wijnen (IETF)</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, February 04, =
2009 2:17=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: [OPSAWG] start =
WGLC on=20
  draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt</DIV>
  <DIV><BR></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Verdana','sans-serif'">Hi=20
  Bert,<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Verdana','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Verdana','sans-serif'">Thanks=20
  for your comments and assessment.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Verdana','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Verdana','sans-serif'">-=20
  The misspellings of =93opaque=94 (with a =93g=94) have been=20
  corrected.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Verdana','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Verdana','sans-serif'">-=20
  The use of =93datatypes=94 in the file name and title was, in fact, =
intended to=20
  refer to =93SMI datatypes=94 as implied by the general usage in RFC =
2578, Sec.=20
  7.1, =93Mapping of the Syntax Clause=94, to wit:<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Verdana','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Verdana','sans-serif'">=93The=20
  SYNTAX clause, which must be present, defines the abstract data =
structure=20
  corresponding to that object.&nbsp; The data structure must be one of =
the=20
  following: a base type, the BITS construct, or a textual =
convention.&nbsp;=20
  (SEQUENCE OF and SEQUENCE are also possible for conceptual tables, see =
section=20
  7.1.12).&nbsp; The base types are those defined in the ObjectSyntax=20
  CHOICE.&nbsp; A textual convention is a newly-defined type defined as =
a=20
  sub-type of a base type [3].=94<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Verdana','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Verdana','sans-serif'">So,=20
  =93datatypes=94 is used a bit loosely for =93base types=94=85would you =
prefer that the=20
  latter term be used?&nbsp; (The document text currently makes it clear =
that it=20
  deals only with expressing the base types of RFC 2578 in=20
  XSD.)<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Verdana','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Verdana','sans-serif'">-=20
  Yes, the text that Juergen questioned is being removed (also had =
helpful=20
  guidance from David Harrington on this point), so that this =93base =
types=94=20
  document stands alone.<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Verdana','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Verdana','sans-serif'">Please=20
  confirm or clarify the second point=85I will have the -05 version, =
reflecting=20
  final mods based on this last call round, ready immediately after =
expiration=20
  of the last call period (12-Feb-09).<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Verdana','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Verdana','sans-serif'">Cheers,<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Verdana','sans-serif'">BobN<o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: =
'Verdana','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
  <DIV>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
#b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: =
medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><B><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">=20
  [email-masked] [mailto:[email-masked]] <B>On Behalf =
Of=20
  </B>Bert Wijnen (IETF)<BR><B>Sent:</B> Wednesday, February 04, 2009 =
4:57=20
  AM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> Re: [OPSAWG] start =
WGLC=20
  =
ondraft-ietf-opsawg-smi-datatypes-in-xsd-04.txt<o:p></o:p></SPAN></P></DI=
V></DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: =
0.5in"><o:p>&nbsp;</o:p></P>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><SPAN =
style=3D"FONT-SIZE: 10pt">My=20
  comments:</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: =
0.5in">&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><SPAN =
style=3D"FONT-SIZE: 10pt">-=20
  page 7, section 4</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp; - speaks about opague. I think you =
mean opaque=20
  (with a Q)</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: =
0.5in">&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp; You may also want to make an explicit =
statement=20
  that those are the datatype</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp; names as ytou specify them in XSD. I =
first=20
  though they were the datatypes</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp; as specified in=20
  SMIv2.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: =
0.5in">&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: =
0.5in">&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><SPAN =
style=3D"FONT-SIZE: 10pt">-=20
  Opague (with a G) is again used in the 1st para of sect 5.3=20
  and&nbsp;</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp; &nbsp;in the first bullet on page 12 =
and also=20
  3rd bullet.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: =
0.5in">&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><SPAN =
style=3D"FONT-SIZE: 10pt">I=20
  share/support Juergen Shoenwaelder's comment w.r.t. the discussion =
about 3=20
  documents</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><SPAN =
style=3D"FONT-SIZE: 10pt">in=20
  a document set. Where, how is that otehr work=20
  scheduled/planned?</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: =
0.5in">&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><SPAN=20
  style=3D"FONT-SIZE: 10pt">Other than that, this document seems=20
  fine.</SPAN><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: =
0.5in">&nbsp;<o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><SPAN=20
  style=3D"FONT-SIZE: 10pt">Bert</SPAN><o:p></o:p></P></DIV>
  <BLOCKQUOTE=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt =
3.75pt; BORDER-LEFT: black 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: =
medium none">
    <DIV>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">----- =
Original=20
    Message ----- <o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal style=3D"BACKGROUND: #e4e4e4; MARGIN-LEFT: =
0.5in"><B><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">From:</SPAN></B><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'"> <A=20
    title=[email-masked] href=3D"mailto:[email-masked]">Scott O. =
Bradner</A>=20
    <o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><B><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">To:</SPAN></B><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'"> <A=20
    title=[email-masked] =
href=3D"mailto:[email-masked]">[email-masked]</A>=20
    <o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><B><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">Sent:</SPAN></B><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'"> =
Friday, January=20
    30, 2009 3:10 AM<o:p></o:p></SPAN></P></DIV>
    <DIV>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><B><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">Subject:</SPAN></B><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'"> Re: =
[OPSAWG]=20
    start WGLC=20
    =
ondraft-ietf-opsawg-smi-datatypes-in-xsd-04.txt<o:p></o:p></SPAN></P></DI=
V>
    <DIV>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: =
0.5in"><o:p>&nbsp;</o:p></P></DIV>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><BR>back on Nov =
6th we sent=20
    out a WGLC on =
<BR>draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt<BR><BR>there=20
    was no response to that last call that I can <BR>find in the mail =
list=20
    archive (or in my memory)<BR><BR>we gotta see a bit more interest =
than that=20
    to proceed<BR>with this document.&nbsp; <BR><BR>So, I'll try again=20
    <BR><BR>this is a WGLC for=20
    draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt<BR>please comment (one =
way or=20
    the other) by Feb=20
    =
12<BR><BR>tnx<BR><BR>Scott<BR>___________________________________________=
____<BR>OPSAWG=20
    mailing list<BR><A =
href=3D"mailto:[email-masked]">[email-masked]</A><BR><A=20
    =
href=3D"https://www.ietf.org/mailman/listinfo/opsawg">https://www.ietf.or=
g/mailman/listinfo/opsawg</A><o:p></o:p></P></BLOCKQUOTE></DIV></BLOCKQUO=
TE></BODY></HTML>

------=_NextPart_000_0A68_01C986F0.92A6AE80--

From: WashamFan <[email-masked]>
To: [email-masked]
Date: Thu, 05 Feb 2009 11:13:32 +0800
Priority: normal
Subject: [Netconf] multiple targets of <partial-lock>

Hi,

>From sec 2.4.1.1, para 5:
"Note that if some of the requested nodes exist only in some of
       the targeted datastores, the lock is granted on different nodes
       in different datastores."
para 6:
"Each select expression MUST return a node set, and at least one
       of the node sets for one of the specified datastores MUST be non-
       empty."

Then, look at this:

a) If I attempt to lock /config/a and /config/b on both <running> and <candidate>, and /config/b only exists in <candidate>.

So lock would be granted and returned <rpc-reply> seems to be:(namespaces are omitted for simplicity)
<rpc-reply>
  <lock-id>127</lock-id>
  <running>
    <locked-node>/config/a</locked-node>
  </running>
  <candidate>
    <locked-node>/config/a</locked-node>
    <locked-node>/config/b</locked-node>
  </candidate>
</rpc-reply>

b) But if I attempt to lock only /config/b instead. lock request should be failed, as all returned node sets for <running> are empty. 

Why should we allow a> whilst prohibit b>? a> is no more secure than b>.

washam

Date: Wed, 04 Feb 2009 19:59:41 -0800
From: Andy Bierman <[email-masked]>
To: WashamFan <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] multiple targets of <partial-lock>

WashamFan wrote:
> Hi,
> 
>>From sec 2.4.1.1, para 5:
> "Note that if some of the requested nodes exist only in some of
>        the targeted datastores, the lock is granted on different nodes
>        in different datastores."
> para 6:
> "Each select expression MUST return a node set, and at least one
>        of the node sets for one of the specified datastores MUST be non-
>        empty."
> 
> Then, look at this:
> 
> a) If I attempt to lock /config/a and /config/b on both <running> and <candidate>, and /config/b only exists in <candidate>.
> 
> So lock would be granted and returned <rpc-reply> seems to be:(namespaces are omitted for simplicity)
> <rpc-reply>
>   <lock-id>127</lock-id>
>   <running>
>     <locked-node>/config/a</locked-node>
>   </running>
>   <candidate>
>     <locked-node>/config/a</locked-node>
>     <locked-node>/config/b</locked-node>
>   </candidate>
> </rpc-reply>
> 
> b) But if I attempt to lock only /config/b instead. lock request should be failed, as all returned node sets for <running> are empty. 
> 
> Why should we allow a> whilst prohibit b>? a> is no more secure than b>.
> 

good question.

Is it an error response for (b), or is it:

  <rpc-reply>
    <lock-id>127</lock-id>
    <candidate>
      <locked-node>/config/b</locked-node>
    </candidate>
  </rpc-reply>

(I don't know -- asking Martin and Balazs)

Either way, I agree that this 'database skew' problem
I brought in earlier should be avoided.  If the same
nodes cannot be locked 1:1, then the entire lock should fail.
Otherwise, do not use multiple targets at once.

[note: if the only target is <candidate/>,
then locks on <running/> are not needed.
IMO, it is a really bad idea to allow concurrent
writes on <candidate/> and <running/>. YMMV.]

> washam

Andy

From: WashamFan <[email-masked]>
To: Andy Bierman <[email-masked]>
Date: Thu, 05 Feb 2009 14:40:39 +0800
Priority: normal
Cc: [email-masked]
Subject: Re: [Netconf] multiple targets of <partial-lock>

Hi,
>  > 
>  >>From sec 2.4.1.1, para 5:
>  > "Note that if some of the requested nodes exist only in some of
>  >        the targeted datastores, the lock is granted on different nodes
>  >        in different datastores."
>  > para 6:
>  > "Each select expression MUST return a node set, and at least one
>  >        of the node sets for one of the specified datastores MUST be 
> non-
>  >        empty."
>  > 
>  > Then, look at this:
>  > 
>  > a) If I attempt to lock /config/a and /config/b on both <running> 
> and <candidate>, and /config/b only exists in <candidate>.
>  > 
>  > So lock would be granted and returned <rpc-reply> seems to 
> be:(namespaces are omitted for simplicity)
>  > <rpc-reply>
>  >   <lock-id>127</lock-id>
>  >   <running>
>  >     <locked-node>/config/a</locked-node>
>  >   </running>
>  >   <candidate>
>  >     <locked-node>/config/a</locked-node>
>  >     <locked-node>/config/b</locked-node>
>  >   </candidate>
>  > </rpc-reply>
>  > 
>  > b) But if I attempt to lock only /config/b instead. lock request 
> should be failed, as all returned node sets for <running> are empty. 
>  > 
>  > Why should we allow a> whilst prohibit b>? a> is no more secure 
> than b>.
>  > 
>  
>  good question.
>  
>  Is it an error response for (b), or is it:
>  
>    <rpc-reply>
>      <lock-id>127</lock-id>
>      <candidate>
>        <locked-node>/config/b</locked-node>
>      </candidate>
>    </rpc-reply>

Well, when I re-reading the relevant text, you are right, b> would succeed and <rpc-reply> as above.

>  (I don't know -- asking Martin and Balazs)
>  
>  Either way, I agree that this 'database skew' problem
>  I brought in earlier should be avoided.  If the same
>  nodes cannot be locked 1:1, then the entire lock should fail.
>  Otherwise, do not use multiple targets at once.

I agree. But the draft seems allow 'database skew'.

washam
  
>  [note: if the only target is <candidate/>,
>  then locks on <running/> are not needed.
>  IMO, it is a really bad idea to allow concurrent
>  writes on <candidate/> and <running/>. YMMV.]
>  
>  
>  
>  > washam
>  
>  Andy
>  
>  

Content-class: urn:content-classes:message
Date: Thu, 5 Feb 2009 14:13:57 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Subject: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

This is the AD review for  draft-ietf-netconf-tls-06.txt. I believe that
this document is in good shape and I am sending it to IETF Last Call.
The comments below can be dealt with together with the other comments
that may arrive during the IETF Last Call period.=20

1. I believe that there is a need for more clarity in defining the usage
of the delimiter sequence ]]>]]> after each XML document. The text in
RFC 4742 seems to me more clear and I suggest to take inspiration from
it:=20

   [The] special character sequence,
   ]]>]]>, MUST be sent by both the client and the server after each XML
   document in the NETCONF exchange.  This character sequence cannot
   legally appear in an XML document, so it can be unambiguously used to
   identify the end of the current document, allowing resynchronization
   of the NETCONF exchange in the event of an XML syntax or parsing
   error.

2. In section 3.2: 'Typically, the server has no external knowledge of
what the client's identity ought to be'. I question if this is really
true in the 'typical' case. I would actually imagine that the case where
network devices would be preconfigured with information about the
identity of their managers would be quite common.=20

3.   Id-nits complains about the obsolete normative reference: RFC 4366
(Obsoleted by RFC 5246). I assume this does not change anything wrt. the
content of the document, but please check.=20

Dan

=20

Content-class: urn:content-classes:message
Date: Thu, 5 Feb 2009 14:25:57 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>, <[email-masked]>
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

One more nit - the header of the I-D should say Intended Status:
Proposed Standard rather than Standards Track.=20

Dan
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
> Sent: Thursday, February 05, 2009 3:14 PM
> To: [email-masked]
> Subject: [Netconf] AD review for draft-ietf-netconf-tls-06.txt
>=20
> This is the AD review for  draft-ietf-netconf-tls-06.txt. I=20
> believe that this document is in good shape and I am sending=20
> it to IETF Last Call.
> The comments below can be dealt with together with the other=20
> comments that may arrive during the IETF Last Call period.=20
>=20
> 1. I believe that there is a need for more clarity in=20
> defining the usage of the delimiter sequence ]]>]]> after=20
> each XML document. The text in RFC 4742 seems to me more=20
> clear and I suggest to take inspiration from
> it:=20
>=20
>    [The] special character sequence,
>    ]]>]]>, MUST be sent by both the client and the server=20
> after each XML
>    document in the NETCONF exchange.  This character sequence cannot
>    legally appear in an XML document, so it can be=20
> unambiguously used to
>    identify the end of the current document, allowing=20
> resynchronization
>    of the NETCONF exchange in the event of an XML syntax or parsing
>    error.
>=20
> 2. In section 3.2: 'Typically, the server has no external=20
> knowledge of what the client's identity ought to be'. I=20
> question if this is really true in the 'typical' case. I=20
> would actually imagine that the case where network devices=20
> would be preconfigured with information about the identity of=20
> their managers would be quite common.=20
>=20
> 3.   Id-nits complains about the obsolete normative=20
> reference: RFC 4366
> (Obsoleted by RFC 5246). I assume this does not change=20
> anything wrt. the content of the document, but please check.=20
>=20
> Dan
>=20
>=20
>=20
>=20
> =20
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>=20

To: IETF-Announce <[email-masked]> 
From: The IESG <[email-masked]>
Date: Thu,  5 Feb 2009 06:25:48 -0800 (PST)
Cc: [email-masked]
Subject: [Netconf] Last Call: draft-ietf-netconf-tls (NETCONF over Transport Layer Security (TLS)) to Proposed Standard
Reply-To: [email-masked]

The IESG has received a request from the Network Configuration WG 
(netconf) to consider the following document:

- 'NETCONF over Transport Layer Security (TLS) '
   <draft-ietf-netconf-tls-06.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2009-02-19. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-06.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16831&rfc_flag=0

Date: Fri, 06 Feb 2009 12:01:24 +0100
From: Balazs Lengyel <[email-masked]>
To: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05

Hello Mehmet,
Thanks for the comments. See also below!
Balazs

Ersue, Mehmet (NSN - DE/Munich) wrote:
>  
> But I have some questions concerning XML schema, though:
>  
> - Why is the count of PartialLock targets is limited to '3' ?
> AFAIK a Netconf client may also define new datastores other
> than <running>, <candidate> and <startup>.

BALAZS: Yes agents can define additional data stores.
However just as RFC4741 defines 3 datastores and we also use these. If you add more datastores 
you violate the XSD both in 4741 and here. In this case you will violate both XSDs in multiple 
places not just this one maxOccurs=3 clause. So as we don't want to prepare 4741 for the 
possible addition of more datastores I don't see the value of preparing this draft either. Do 
you want to raise this issue in the 4741bis effort?

>  
> - The "target" element in the "partial-lock" elements allows to
> repeat 1 to 3 times any of the "startup"/"candidate"/"running",
> so i.e. also 3 times the same. Is this a schema design issue?

Yes, but I don't know how to say this in a nicer way in XSD. The intent is to allow one or more 
of the 3 datastores, but each datastore is allowed only once.

>  
> - I am not sure whether datastore names should be each
> individually in a target node. The following XML snippet ...
>  
> 
> <partial-lock xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
> 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> 
> xsi:schemaLocation="urn:ietf:params:xml:ns:netconf:partial-lock:1.0
> 
> C:\Partial_Lock_05.xsd">
> 
>             <target/>
> 
>                         <target>
> 
>                             <candidate/>
> 
>                         </target>
> 
>                         <target>
> 
>                             <candidate/>
> 
>                         </target>
> 
>             <select/>
> 
> </partial-lock>
> 
> is accepted by XMLSpy as valid with regard to the partial lock
> schema. 
> OTOH the description says: "Each target element MUST contain
> a different datastore name."

BALAZS: You are right, thats why we put in the annotation text:
"Each target element MUST contain a different datastore name."
I did not know about a formal way to say this in XSD?. Could you propose an alternative?

> 
> - The schema requires that in "startup"/"candidate"/"running"
> elements belonging to "contentPartInPartialLockReplyType"
> must containt at least one "locked-node" element.
> But in the YANG module, the "locked-node" leaf lists inside
> "startup"/"candidate"/"running" containers do not contain a
> "min-elements 1;" statement, so the containers may be empty,
> which differs from XSD.
> 

BALAZS: You are right, the restriction is added to YANG as well. There is no sense in sending 
an empty <startup/> element if it does not contain any locked nodes.

Balazs

Date: Fri, 06 Feb 2009 14:34:22 +0100
From: Balazs Lengyel <[email-masked]>
To: WashamFan <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] multiple targets of <partial-lock>

Hello,
Case b will succeed as Washam has written, because NOT all returned node-sets are empty. One of 
the selects when applied to the candidate does return "b".

Locking multiple databases was explicitly asked for earlier and was accepted by the group. Yes 
you can mess it up if you don't check the results, but there are so many ways to shoot yourself 
  in the foot.

regards Balazs

WashamFan wrote:
> Hi,
>>  > 
>>  >>From sec 2.4.1.1, para 5:
>>  > "Note that if some of the requested nodes exist only in some of
>>  >        the targeted datastores, the lock is granted on different nodes
>>  >        in different datastores."
>>  > para 6:
>>  > "Each select expression MUST return a node set, and at least one
>>  >        of the node sets for one of the specified datastores MUST be 
>> non-
>>  >        empty."
>>  > 
>>  > Then, look at this:
>>  > 
>>  > a) If I attempt to lock /config/a and /config/b on both <running> 
>> and <candidate>, and /config/b only exists in <candidate>.
>>  > 
>>  > So lock would be granted and returned <rpc-reply> seems to 
>> be:(namespaces are omitted for simplicity)
>>  > <rpc-reply>
>>  >   <lock-id>127</lock-id>
>>  >   <running>
>>  >     <locked-node>/config/a</locked-node>
>>  >   </running>
>>  >   <candidate>
>>  >     <locked-node>/config/a</locked-node>
>>  >     <locked-node>/config/b</locked-node>
>>  >   </candidate>
>>  > </rpc-reply>
>>  > 
>>  > b) But if I attempt to lock only /config/b instead. lock request 
>> should be failed, as all returned node sets for <running> are empty. 
>>  > 
>>  > Why should we allow a> whilst prohibit b>? a> is no more secure 
>> than b>.
>>  > 
>>  
>>  good question.
>>  
>>  Is it an error response for (b), or is it:
>>  
>>    <rpc-reply>
>>      <lock-id>127</lock-id>
>>      <candidate>
>>        <locked-node>/config/b</locked-node>
>>      </candidate>
>>    </rpc-reply>
> 
> Well, when I re-reading the relevant text, you are right, b> would succeed and <rpc-reply> as above.
> 
>>  (I don't know -- asking Martin and Balazs)
>>  
>>  Either way, I agree that this 'database skew' problem
>>  I brought in earlier should be avoided.  If the same
>>  nodes cannot be locked 1:1, then the entire lock should fail.
>>  Otherwise, do not use multiple targets at once.
> 
> I agree. But the draft seems allow 'database skew'.
> 
> washam
>   
>>  [note: if the only target is <candidate/>,
>>  then locks on <running/> are not needed.
>>  IMO, it is a really bad idea to allow concurrent
>>  writes on <candidate/> and <running/>. YMMV.]
>>  
>>  
>>  
>>  > washam
>>  
>>  Andy
>>  
>>  
> _______________________________________________
> Netconf mailing list
> [email-masked]
> 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: [email-masked]

From: [email-masked]
To: [email-masked]
Date: Fri,  6 Feb 2009 07:00:01 -0800 (PST)
Cc: [email-masked]
Subject: [Netconf] I-D Action:draft-ietf-netconf-partial-lock-06.txt

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration Working Group of the IETF.

	Title           : Partial Lock RPC for NETCONF
	Author(s)       : B. Lengyel, M. Bjorklund
	Filename        : draft-ietf-netconf-partial-lock-06.txt
	Pages           : 30
	Date            : 2009-02-06

The NETCONF protocol defines the lock and unlock RPCs, used to lock
entire configuration datastores.  In some situations, a way to lock
only parts of a configuration datastore is required.  This document
defines a capability-based extension to the NETCONF protocol for
locking portions of a configuration datastore.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-partial-lock-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-netconf-partial-lock-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

From: "Bert Wijnen \(IETF\)" <[email-masked]>
To: <[email-masked]>
Date: Fri, 6 Feb 2009 17:22:13 +0100
Organization: Consultant
Subject: [Netconf] PLEASE CHECK new I-D BEFORE Feb 14th - draft-ietf-netconf-partial-lock-06.txt

This is a multi-part message in MIME format.

------=_NextPart_000_117D_01C9887F.733DBDA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The WGLC for revision 05 ended on Feb 1st.=20
We did get a good deal of comments and reviews.
Thanks to Balazs and Martin for the new revision.

ALL: pls check out this new version.
THOSE WHO Commented earlier: PLEASE MAKE SURE your comments
have ben appropriately addressed. please do so before 14 Feb 2009.

If we do not see serious or many remaining issues/concerns
we (wg chairs)  would like to proceed passing this on to our AD=20
to consider revision 6 for publication as a Proposed Standard.

If anyone dis-agrees and thinks we need another WG LC, PLEAS SPEAK UP=20
no later than Feb 14.

Bert and Mehmet

  ----- Original Message -----=20
  From: [email-masked]=20
  To: [email-masked]=20
  Cc: [email-masked]=20
  Sent: Friday, February 06, 2009 4:00 PM
  Subject: [Netconf] I-D Action:draft-ietf-netconf-partial-lock-06.txt

  A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
  This draft is a work item of the Network Configuration Working Group =
of the IETF.

  Title           : Partial Lock RPC for NETCONF
  Author(s)       : B. Lengyel, M. Bjorklund
  Filename        : draft-ietf-netconf-partial-lock-06.txt
  Pages           : 30
  Date            : 2009-02-06

  The NETCONF protocol defines the lock and unlock RPCs, used to lock
  entire configuration datastores.  In some situations, a way to lock
  only parts of a configuration datastore is required.  This document
  defines a capability-based extension to the NETCONF protocol for
  locking portions of a configuration datastore.

  A URL for this Internet-Draft is:
  =
http://www.ietf.org/internet-drafts/draft-ietf-netconf-partial-lock-06.tx=
t

  Internet-Drafts are also available by anonymous FTP at:
  ftp://ftp.ietf.org/internet-drafts/

  Below is the data which will enable a MIME compliant mail reader
  implementation to automatically retrieve the ASCII version of the
  Internet-Draft.

-------------------------------------------------------------------------=
-----

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

------=_NextPart_000_117D_01C9887F.733DBDA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6001.18183" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>The WGLC for revision 05 ended on Feb 1st. =
</FONT></DIV>
<DIV><FONT size=3D2>We did get a good deal of comments and =
reviews.</FONT></DIV>
<DIV><FONT size=3D2>Thanks to Balazs and Martin for the new =
revision.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>ALL: pls check out this new version.</FONT></DIV>
<DIV><FONT size=3D2>THOSE WHO Commented earlier: PLEASE MAKE SURE your=20
comments</FONT></DIV>
<DIV><FONT size=3D2>have ben appropriately addressed. please do so =
</FONT><FONT=20
size=3D3>before 14 Feb 2009.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>If we do not see serious or&nbsp;many remaining=20
issues/concerns</FONT></DIV>
<DIV><FONT size=3D2>we (wg chairs) &nbsp;would like to proceed passing =
this on to=20
our AD </FONT></DIV>
<DIV><FONT size=3D2>to consider revision 6 </FONT><FONT size=3D2>for =
publication as=20
a Proposed Standard.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>If anyone dis-agrees and thinks we need another WG =
LC, PLEAS=20
SPEAK UP </FONT></DIV>
<DIV><FONT size=3D2>no later than Feb 14.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Bert and Mehmet</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A title=[email-masked] =

  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, February 06, 2009 =
4:00=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [Netconf] I-D=20
  Action:draft-ietf-netconf-partial-lock-06.txt</DIV>
  <DIV><BR></DIV>A New Internet-Draft is available from the on-line=20
  Internet-Drafts directories.<BR>This draft is a work item of the =
Network=20
  Configuration Working Group of the=20
  =
IETF.<BR><BR><BR>Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;=20
  : Partial Lock RPC for=20
  NETCONF<BR>Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : B. Lengyel, =
M.=20
  Bjorklund<BR>Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; :=20
  =
draft-ietf-netconf-partial-lock-06.txt<BR>Pages&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  : =
30<BR>Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
  : 2009-02-06<BR><BR>The NETCONF protocol defines the lock and unlock =
RPCs,=20
  used to lock<BR>entire configuration datastores.&nbsp; In some =
situations, a=20
  way to lock<BR>only parts of a configuration datastore is =
required.&nbsp; This=20
  document<BR>defines a capability-based extension to the NETCONF =
protocol=20
  for<BR>locking portions of a configuration datastore.<BR><BR>A URL for =
this=20
  Internet-Draft is:<BR><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-netconf-partial-lo=
ck-06.txt">http://www.ietf.org/internet-drafts/draft-ietf-netconf-partial=
-lock-06.txt</A><BR><BR>Internet-Drafts=20
  are also available by anonymous FTP at:<BR><A=20
  =
href=3D"ftp://ftp.ietf.org/internet-drafts/">ftp://ftp.ietf.org/internet-=
drafts/</A><BR><BR>Below=20
  is the data which will enable a MIME compliant mail =
reader<BR>implementation=20
  to automatically retrieve the ASCII version of =
the<BR>Internet-Draft.<BR>
  <P>
  <HR>

  <P></P>_______________________________________________<BR>Netconf =
mailing=20
  list<BR><A href=3D"mailto:[email-masked]">[email-masked]</A><BR><A =

  =
href=3D"https://www.ietf.org/mailman/listinfo/netconf">https://www.ietf.o=
rg/mailman/listinfo/netconf</A><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_117D_01C9887F.733DBDA0--

Date: Sat, 7 Feb 2009 09:46:30 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: "Bert Wijnen (IETF)" <[email-masked]>
Mail-Followup-To: "Bert Wijnen (IETF)" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] PLEASE CHECK new I-D BEFORE Feb 14th -	draft-ietf-netconf-partial-lock-06.txt
Reply-To: [email-masked]

On Fri, Feb 06, 2009 at 05:22:13PM +0100, Bert Wijnen (IETF) wrote:

> THOSE WHO Commented earlier: PLEASE MAKE SURE your comments
> have ben appropriately addressed. please do so before 14 Feb 2009.

I am fine with the changes.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

Content-class: urn:content-classes:message
Date: Mon, 9 Feb 2009 14:25:25 +0100
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: "ext Balazs Lengyel" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05

Hi Balazs, Martin,

I think the issues are related to each other. I can go with=20
a change like:

           <xs:element name=3D"target" maxOccurs=3D"unbounded">
             <xs:annotation>
               <xs:documentation>
                 A list of one or more datastore names for NETCONF.
                 Each target element MUST contain a different
                 datastore name.
               </xs:documentation>
             </xs:annotation>
             <xs:complexType>
               <xs:choice>
                 <xs:element name=3D"startup" minOccurs=3D"0">
                   <xs:complexType/>
                 </xs:element>
                 <xs:element name=3D"candidate" minOccurs=3D"0">
                   <xs:complexType/>
                 </xs:element>
                 <xs:element name=3D"running" minOccurs=3D"0">
                   <xs:complexType/>
                 </xs:element>
                 <xs:any namespace=3D"##other" minOccurs=3D"0"/>
               </xs:choice>
             </xs:complexType>
           </xs:element>

Cheers,=20
Mehmet

> -----Original Message-----
> From: ext Balazs Lengyel [mailto:[email-masked]]=20
> Sent: Friday, February 06, 2009 12:01 PM
> To: Ersue, Mehmet (NSN - DE/Munich)
> Cc: Martin Bjorklund; [email-masked]
> Subject: Re: WGLC: draft-ietf-netconf-partial-lock-05
>=20
> Hello Mehmet,
> Thanks for the comments. See also below!
> Balazs
>=20
> Ersue, Mehmet (NSN - DE/Munich) wrote:
> > =20
> > But I have some questions concerning XML schema, though:
> > =20
> > - Why is the count of PartialLock targets is limited to '3' ?
> > AFAIK a Netconf client may also define new datastores other
> > than <running>, <candidate> and <startup>.
>=20
> BALAZS: Yes agents can define additional data stores.
> However just as RFC4741 defines 3 datastores and we also use=20
> these. If you add more datastores=20
> you violate the XSD both in 4741 and here. In this case you=20
> will violate both XSDs in multiple=20
> places not just this one maxOccurs=3D3 clause. So as we don't=20
> want to prepare 4741 for the=20
> possible addition of more datastores I don't see the value of=20
> preparing this draft either. Do=20
> you want to raise this issue in the 4741bis effort?
>=20
> > =20
> > - The "target" element in the "partial-lock" elements allows to
> > repeat 1 to 3 times any of the "startup"/"candidate"/"running",
> > so i.e. also 3 times the same. Is this a schema design issue?
>=20
> Yes, but I don't know how to say this in a nicer way in XSD.=20
> The intent is to allow one or more=20
> of the 3 datastores, but each datastore is allowed only once.
>=20
> > =20
> > - I am not sure whether datastore names should be each
> > individually in a target node. The following XML snippet ...
> > =20
> >=20
> > <partial-lock=20
> xmlns=3D"urn:ietf:params:xml:ns:netconf:partial-lock:1.0"
> >=20
> > xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
> >=20
> > =
xsi:schemaLocation=3D"urn:ietf:params:xml:ns:netconf:partial-lock:1.0
> >=20
> > C:\Partial_Lock_05.xsd">
> >=20
> >             <target/>
> >=20
> >                         <target>
> >=20
> >                             <candidate/>
> >=20
> >                         </target>
> >=20
> >                         <target>
> >=20
> >                             <candidate/>
> >=20
> >                         </target>
> >=20
> >             <select/>
> >=20
> > </partial-lock>
> >=20
> > is accepted by XMLSpy as valid with regard to the partial lock
> > schema.=20
> > OTOH the description says: "Each target element MUST contain
> > a different datastore name."
>=20
> BALAZS: You are right, thats why we put in the annotation text:
> "Each target element MUST contain a different datastore name."
> I did not know about a formal way to say this in XSD?. Could=20
> you propose an alternative?
>=20
> >=20
> > - The schema requires that in "startup"/"candidate"/"running"
> > elements belonging to "contentPartInPartialLockReplyType"
> > must containt at least one "locked-node" element.
> > But in the YANG module, the "locked-node" leaf lists inside
> > "startup"/"candidate"/"running" containers do not contain a
> > "min-elements 1;" statement, so the containers may be empty,
> > which differs from XSD.
> >=20
>=20
> BALAZS: You are right, the restriction is added to YANG as=20
> well. There is no sense in sending=20
> an empty <startup/> element if it does not contain any locked nodes.
>=20
> Balazs
>=20

Date: Mon, 09 Feb 2009 14:54:41 +0100
From: Balazs Lengyel <[email-masked]>
To: netconf mailing list <[email-masked]>
Subject: [Netconf] Allow other datastores for Netconf

Hello,
A recent comment mentioned

"I think the Netconf base protocol specification does not limit the
count of datastores to 3 and it is not disallowed to define new
datastores for new purposes. In fact Candidate and Startup
datastores are examples of new datastores realized as capabilities."

It is true, that the 4741 XSD does limit the number of data stores, but that was probably not 
the original intention. For this reason the partial-locking draft XSD and YANG will be modified 
to allow locking of other datastores outside the usual 3 (running, startup,candidate).

Proposed changes to XSD:

<xs:element name="target" maxOccurs="unbounded">  <-------------------
   <xs:annotation>
     <xs:documentation>
       A list of one or more datastore names for NETCONF.
       Each target element MUST contain a different
       datastore name.
     </xs:documentation>
   </xs:annotation>
   <xs:complexType>
     <xs:choice>
       <xs:element name="startup" minOccurs="0">
         <xs:complexType/>
       </xs:element>
       <xs:element name="candidate" minOccurs="0">
         <xs:complexType/>
       </xs:element>
       <xs:element name="running" minOccurs="0">
         <xs:complexType/>
       </xs:element>
       <xs:any namespace="##other" minOccurs="0">   <-------------------
         <xs:annotation>
           <xs:documentation>
             The content of this xs:any MUST be a single empty
             element referring to an implementation specific
             NETCONF datastore that is not one of
             startup, running or candidate.
           </xs:documentation>
         </xs:annotation>
       </xs:any>
     </xs:choice>
   </xs:complexType>
</xs:element>

Proposed changes to YANG:

list target {
   min-elements 1;    <------------------- max-elements removed
   description
     "A list of one or more datastore names.
      Each list entry must contain a different datastore name.

      Implementations might lock other datastores, if they   <-------------------
      augment the list of datastore names with other (type empty)
      leafs referring to an implementation specific
      NETCONF datastore, that is not one of
      startup, running or candidate.";
   choice datastore {
     leaf running   { type empty; }
     leaf candidate { type empty; }
     leaf startup   { type empty;
   }
}

Balazs

From: WashamFan <[email-masked]>
To: Balazs Lengyel <[email-masked]>
Date: Tue, 10 Feb 2009 10:51:58 +0800
Priority: normal
Cc: netconf mailing list <[email-masked]>
Subject: Re: [Netconf] Allow other datastores for Netconf

Hi,

> Hello,
>  A recent comment mentioned
>  
>  "I think the Netconf base protocol specification does not limit the
>  count of datastores to 3 and it is not disallowed to define new
>  datastores for new purposes. In fact Candidate and Startup
>  datastores are examples of new datastores realized as capabilities."
>  
>  It is true, that the 4741 XSD does limit the number of data stores, 
> but that was probably not 
>  the original intention. For this reason the partial-locking draft XSD 
> and YANG will be modified 
>  to allow locking of other datastores outside the usual 3 (running, startup,candidate).
>  
>  Proposed changes to XSD:
>  
>  <xs:element name="target" maxOccurs="unbounded">  <-------------------
>     <xs:annotation>
>       <xs:documentation>
>         A list of one or more datastore names for NETCONF.
>         Each target element MUST contain a different
>         datastore name.
>       </xs:documentation>
>     </xs:annotation>
>     <xs:complexType>
>       <xs:choice>
>         <xs:element name="startup" minOccurs="0">
>           <xs:complexType/>
>         </xs:element>
>         <xs:element name="candidate" minOccurs="0">
>           <xs:complexType/>
>         </xs:element>
>         <xs:element name="running" minOccurs="0">
>           <xs:complexType/>
>         </xs:element>
>         <xs:any namespace="##other" minOccurs="0">   <-------------------
>           <xs:annotation>
>             <xs:documentation>
>               The content of this xs:any MUST be a single empty
>               element referring to an implementation specific
>               NETCONF datastore that is not one of
>               startup, running or candidate.
>             </xs:documentation>
>           </xs:annotation>
>         </xs:any>
>       </xs:choice>
>     </xs:complexType>
>  </xs:element>

Why allow for minOccurs="0" :
<target></taget>     <------------corret?

washam

>  Proposed changes to YANG:
>  
>  list target {
>     min-elements 1;    <------------------- max-elements removed
>     description
>       "A list of one or more datastore names.
>        Each list entry must contain a different datastore name.
>  
>        Implementations might lock other datastores, if they   <-------------------
>        augment the list of datastore names with other (type empty)
>        leafs referring to an implementation specific
>        NETCONF datastore, that is not one of
>        startup, running or candidate.";
>     choice datastore {
>       leaf running   { type empty; }
>       leaf candidate { type empty; }
>       leaf startup   { type empty;
>     }
>  }
>  
>  
>  Balazs
>  _______________________________________________
>  Netconf mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/netconf
>  

Date: Tue, 10 Feb 2009 09:23:33 +0100
From: Balazs Lengyel <[email-masked]>
To: WashamFan <[email-masked]>
Cc: netconf mailing list <[email-masked]>
Subject: Re: [Netconf] Allow other datastores for Netconf

WashamFan wrote:
> Hi,
> 
>> Hello,
>>  A recent comment mentioned
>>  
>>  "I think the Netconf base protocol specification does not limit the
>>  count of datastores to 3 and it is not disallowed to define new
>>  datastores for new purposes. In fact Candidate and Startup
>>  datastores are examples of new datastores realized as capabilities."
>>  
>>  It is true, that the 4741 XSD does limit the number of data stores, 
>> but that was probably not 
>>  the original intention. For this reason the partial-locking draft XSD 
>> and YANG will be modified 
>>  to allow locking of other datastores outside the usual 3 (running, startup,candidate).
>>  
>>  Proposed changes to XSD:
>>  
>>  <xs:element name="target" maxOccurs="unbounded">  <-------------------
>>     <xs:annotation>
>>       <xs:documentation>
>>         A list of one or more datastore names for NETCONF.
>>         Each target element MUST contain a different
>>         datastore name.
>>       </xs:documentation>
>>     </xs:annotation>
>>     <xs:complexType>
>>       <xs:choice>
>>         <xs:element name="startup" minOccurs="0">
>>           <xs:complexType/>
>>         </xs:element>
>>         <xs:element name="candidate" minOccurs="0">
>>           <xs:complexType/>
>>         </xs:element>
>>         <xs:element name="running" minOccurs="0">
>>           <xs:complexType/>
>>         </xs:element>
>>         <xs:any namespace="##other" minOccurs="0">   <-------------------
>>           <xs:annotation>
>>             <xs:documentation>
>>               The content of this xs:any MUST be a single empty
>>               element referring to an implementation specific
>>               NETCONF datastore that is not one of
>>               startup, running or candidate.
>>             </xs:documentation>
>>           </xs:annotation>
>>         </xs:any>
>>       </xs:choice>
>>     </xs:complexType>
>>  </xs:element>
> 
> Why allow for minOccurs="0" :
> <target></taget>     <------------corret?
> 
> washam
> 
BALAZS: Any of the datastores might be absent from the request. The requirement is that at 
least one valid datastore name is inserted. So target must occur at least once, which is the 
XSD default.

Sorry if I misunderstood your comment.

Balazs

From: WashamFan <[email-masked]>
To: Balazs Lengyel <[email-masked]>
Date: Tue, 10 Feb 2009 16:37:19 +0800
Priority: normal
Cc: netconf mailing list <[email-masked]>
Subject: Re: [Netconf] Allow other datastores for Netconf

>  WashamFan wrote:
>  > Hi,
>  > 
>  >> Hello,
>  >>  A recent comment mentioned
>  >>  
>  >>  "I think the Netconf base protocol specification does not limit the
>  >>  count of datastores to 3 and it is not disallowed to define new
>  >>  datastores for new purposes. In fact Candidate and Startup
>  >>  datastores are examples of new datastores realized as capabilities."
>  >>  
>  >>  It is true, that the 4741 XSD does limit the number of data 
> stores, 
>  >> but that was probably not 
>  >>  the original intention. For this reason the partial-locking draft 
> XSD 
>  >> and YANG will be modified 
>  >>  to allow locking of other datastores outside the usual 3 
> (running, startup,candidate).
>  >>  
>  >>  Proposed changes to XSD:
>  >>  
>  >>  <xs:element name="target" maxOccurs="unbounded">  <-------------------
>  >>     <xs:annotation>
>  >>       <xs:documentation>
>  >>         A list of one or more datastore names for NETCONF.
>  >>         Each target element MUST contain a different
>  >>         datastore name.
>  >>       </xs:documentation>
>  >>     </xs:annotation>
>  >>     <xs:complexType>
>  >>       <xs:choice>
>  >>         <xs:element name="startup" minOccurs="0">
>  >>           <xs:complexType/>
>  >>         </xs:element>
>  >>         <xs:element name="candidate" minOccurs="0">
>  >>           <xs:complexType/>
>  >>         </xs:element>
>  >>         <xs:element name="running" minOccurs="0">
>  >>           <xs:complexType/>
>  >>         </xs:element>
>  >>         <xs:any namespace="##other" minOccurs="0">   <-------------------
>  >>           <xs:annotation>
>  >>             <xs:documentation>
>  >>               The content of this xs:any MUST be a single empty
>  >>               element referring to an implementation specific
>  >>               NETCONF datastore that is not one of
>  >>               startup, running or candidate.
>  >>             </xs:documentation>
>  >>           </xs:annotation>
>  >>         </xs:any>
>  >>       </xs:choice>
>  >>     </xs:complexType>
>  >>  </xs:element>
>  > 
>  > Why allow for minOccurs="0" :
>  > <target></taget>     <------------corret?
>  > 
>  > washam
>  > 
>  BALAZS: Any of the datastores might be absent from the request. The 
> requirement is that at 
>  least one valid datastore name is inserted. So target must occur at 
> least once, which is the 
>  XSD default.

I meant '<target></target>' would be correct syntacticly according to this XSD.
<xs:choice> means only one of four child <element>s should be selected. When a <element>
is selected. it is allowed for 0 occurrence.
I suggest omitting 'minOccurs="0"'.

washam

>  Sorry if I misunderstood your comment.
>  
>  Balazs
>  

Date: Tue, 10 Feb 2009 07:49:38 -0800
From: Andy Bierman <[email-masked]>
To: WashamFan <[email-masked]>
Cc: netconf mailing list <[email-masked]>
Subject: Re: [Netconf] Allow other datastores for Netconf

WashamFan wrote:
>  
>>  WashamFan wrote:
>>  > Hi,
>>  > 
>>  >> Hello,
>>  >>  A recent comment mentioned
>>  >>  
>>  >>  "I think the Netconf base protocol specification does not limit the
>>  >>  count of datastores to 3 and it is not disallowed to define new
>>  >>  datastores for new purposes. In fact Candidate and Startup
>>  >>  datastores are examples of new datastores realized as capabilities."
>>  >>  
>>  >>  It is true, that the 4741 XSD does limit the number of data 
>> stores, 
>>  >> but that was probably not 
>>  >>  the original intention. For this reason the partial-locking draft 
>> XSD 
>>  >> and YANG will be modified 
>>  >>  to allow locking of other datastores outside the usual 3 
>> (running, startup,candidate).
>>  >>  
>>  >>  Proposed changes to XSD:
>>  >>  
>>  >>  <xs:element name="target" maxOccurs="unbounded">  <-------------------
>>  >>     <xs:annotation>
>>  >>       <xs:documentation>
>>  >>         A list of one or more datastore names for NETCONF.
>>  >>         Each target element MUST contain a different
>>  >>         datastore name.
>>  >>       </xs:documentation>
>>  >>     </xs:annotation>
>>  >>     <xs:complexType>
>>  >>       <xs:choice>
>>  >>         <xs:element name="startup" minOccurs="0">
>>  >>           <xs:complexType/>
>>  >>         </xs:element>
>>  >>         <xs:element name="candidate" minOccurs="0">
>>  >>           <xs:complexType/>
>>  >>         </xs:element>
>>  >>         <xs:element name="running" minOccurs="0">
>>  >>           <xs:complexType/>
>>  >>         </xs:element>
>>  >>         <xs:any namespace="##other" minOccurs="0">   <-------------------
>>  >>           <xs:annotation>
>>  >>             <xs:documentation>
>>  >>               The content of this xs:any MUST be a single empty
>>  >>               element referring to an implementation specific
>>  >>               NETCONF datastore that is not one of
>>  >>               startup, running or candidate.
>>  >>             </xs:documentation>
>>  >>           </xs:annotation>
>>  >>         </xs:any>
>>  >>       </xs:choice>
>>  >>     </xs:complexType>
>>  >>  </xs:element>
>>  > 
>>  > Why allow for minOccurs="0" :
>>  > <target></taget>     <------------corret?
>>  > 
>>  > washam
>>  > 
>>  BALAZS: Any of the datastores might be absent from the request. The 
>> requirement is that at 
>>  least one valid datastore name is inserted. So target must occur at 
>> least once, which is the 
>>  XSD default.
> 
> I meant '<target></target>' would be correct syntacticly according to this XSD.
> <xs:choice> means only one of four child <element>s should be selected. When a <element>
> is selected. it is allowed for 0 occurrence.
> I suggest omitting 'minOccurs="0"'.
> 

1) I think you want minOccurs=1, maxOccurs=unbounded for
    the entire choice, maxOccurs=1 on candidate, running,
    and startup, and maxOccurs=unbounded on 'any'.
    You don't need minOccurs=0 on choice members.

2) The schema implies that all agents will accept this 'any'
    placeholder parameter, even though :url is required for
    this feature to have any meaning on the agent.

3) This seems to be changing the design of NETCONF operations
    to introduce arbitrary empty elements instead of the <url> element,
    used everywhere else in NETCONF.  There is no such thing
    as a config named <foo/> in NETCONF.  Instead, there is
    a <url>file:://foo</url> allowed.  IMO, partial-lock should
    be consistent with existing protocol operations.

> washam
> 
>>  Sorry if I misunderstood your comment.
>>  
>>  Balazs
>>  

Andy

From: Vladlen Kot <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 10 Feb 2009 09:22:03 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: [Netconf] 4 bytes header when connecting via NETCONF and using SSH subsystem.

--_000_48C276B536524E478C659685995F6AA5A30A9FD0DCRBSJXadredbac_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi folks,

I have a question on the SSH subsystem with NETCONF; and I'm looking if any=
one knows of any Standard for this (4 bytes leading header).  Here the dile=
mma I'm facing:

"One of our guys having problem running his commands with SSH subsystem. It=
 appears as if he is connecting via the NETCONF subsystem, but the packets =
that you are sending are not SSH subsystem packets.

SSH subsystem packets consist of a header portion followed by the data segm=
ent. The header portion consists of 4 bytes that contain the length of the =
data segment in network byte order. The data segment contains the data.

If user doesn't use the NETCONF subsystem, then he will not have to form th=
ese subsystem packets.

I've searched the RFC for some guidance on this, and I was unable to find a=
ny mention of it. The only reference to something similar was that the scp =
and stfp subsystem use this packet protocol. Other SSH libraries (perl's Ne=
t:SSH in particular) seem to adhere to the same encoding of data when using=
 subsystems."

Any help or pointing into right direction to look for the source of the Sta=
ndard will be much appreciated.

Thanks,
Vlad

--_000_48C276B536524E478C659685995F6AA5A30A9FD0DCRBSJXadredbac_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc=
hemas-microsoft-com:office:word" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>Hi folks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'>I have a question on the SSH
subsystem with NETCONF; and I&#8217;m looking if anyone knows of any Standa=
rd
for this (4 bytes leading header). &nbsp;Here the dilemma I&#8217;m facing:=
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font=
></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><i><font size=3D2 face=
=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;font-style:italic'>&#8220;</spa=
n></font></i><i><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt;font-family:"=
Courier New";
font-style:italic'>One of our guys having problem running his commands with=
 SSH
subsystem. It appears as if he is connecting via the NETCONF subsystem, but=
 the
packets that you are sending are not SSH subsystem packets.<o:p></o:p></spa=
n></font></i></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><i><font size=3D2
face=3D"Courier New"><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew";
font-style:italic'><o:p>&nbsp;</o:p></span></font></i></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><i><font size=3D2
face=3D"Courier New"><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew";
font-style:italic'>SSH subsystem packets consist of a header portion follow=
ed
by the data segment. The header portion consists of 4 bytes that contain th=
e length
of the data segment in network byte order. The data segment contains the da=
ta.<o:p></o:p></span></font></i></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><i><font size=3D2
face=3D"Courier New"><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew";
font-style:italic'><o:p>&nbsp;</o:p></span></font></i></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><i><font size=3D2
face=3D"Courier New"><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew";
font-style:italic'>If user doesn't use the NETCONF subsystem, then he will =
not
have to form these subsystem packets.<o:p></o:p></span></font></i></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><i><font size=3D2
face=3D"Courier New"><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew";
font-style:italic'><o:p>&nbsp;</o:p></span></font></i></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><i><font size=3D2
face=3D"Courier New"><span style=3D'font-size:10.0pt;font-family:"Courier N=
ew";
font-style:italic'>I&#8217;ve searched the RFC for some guidance on this, a=
nd I
was unable to find any mention of it. The only reference to something simil=
ar
was that the scp and stfp subsystem use this packet protocol. Other SSH
libraries (perl's Net:SSH in particular) seem to adhere to the same encodin=
g of
data when using subsystems</span></font></i><i><font size=3D2 face=3DArial>=
<span
style=3D'font-size:10.0pt;font-family:Arial;font-style:italic'>.&#8221;<o:p=
></o:p></span></font></i></p>

<p class=3DMsoNormal><i><font size=3D2 face=3DArial><span style=3D'font-siz=
e:10.0pt;
font-family:Arial;font-style:italic'><o:p>&nbsp;</o:p></span></font></i></p=

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>Any help or pointing into right direction to look for th=
e
source of the Standard will be much appreciated.<o:p></o:p></span></font></=
p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>Thanks,</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span style=3D'font-size:1=
0.0pt;
font-family:Arial'>Vlad</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

--_000_48C276B536524E478C659685995F6AA5A30A9FD0DCRBSJXadredbac_--

From: WashamFan <[email-masked]>
To: Andy Bierman <[email-masked]>
Date: Wed, 11 Feb 2009 09:47:31 +0800
Priority: normal
Cc: netconf mailing list <[email-masked]>
Subject: Re: [Netconf] Allow other datastores for Netconf

Hi,

> WashamFan wrote:
>  >  
>  >>  WashamFan wrote:
>  >>  > Hi,
>  >>  > 
>  >>  >> Hello,
>  >>  >>  A recent comment mentioned
>  >>  >>  
>  >>  >>  "I think the Netconf base protocol specification does not 
> limit the
>  >>  >>  count of datastores to 3 and it is not disallowed to define new
>  >>  >>  datastores for new purposes. In fact Candidate and Startup
>  >>  >>  datastores are examples of new datastores realized as capabilities."
>  >>  >>  
>  >>  >>  It is true, that the 4741 XSD does limit the number of data 
>  >> stores, 
>  >>  >> but that was probably not 
>  >>  >>  the original intention. For this reason the partial-locking 
> draft 
>  >> XSD 
>  >>  >> and YANG will be modified 
>  >>  >>  to allow locking of other datastores outside the usual 3 
>  >> (running, startup,candidate).
>  >>  >>  
>  >>  >>  Proposed changes to XSD:
>  >>  >>  
>  >>  >>  <xs:element name="target" maxOccurs="unbounded">  <-------------------
>  >>  >>     <xs:annotation>
>  >>  >>       <xs:documentation>
>  >>  >>         A list of one or more datastore names for NETCONF.
>  >>  >>         Each target element MUST contain a different
>  >>  >>         datastore name.
>  >>  >>       </xs:documentation>
>  >>  >>     </xs:annotation>
>  >>  >>     <xs:complexType>
>  >>  >>       <xs:choice>
>  >>  >>         <xs:element name="startup" minOccurs="0">
>  >>  >>           <xs:complexType/>
>  >>  >>         </xs:element>
>  >>  >>         <xs:element name="candidate" minOccurs="0">
>  >>  >>           <xs:complexType/>
>  >>  >>         </xs:element>
>  >>  >>         <xs:element name="running" minOccurs="0">
>  >>  >>           <xs:complexType/>
>  >>  >>         </xs:element>
>  >>  >>         <xs:any namespace="##other" minOccurs="0">   <-------------------
>  >>  >>           <xs:annotation>
>  >>  >>             <xs:documentation>
>  >>  >>               The content of this xs:any MUST be a single empty
>  >>  >>               element referring to an implementation specific
>  >>  >>               NETCONF datastore that is not one of
>  >>  >>               startup, running or candidate.
>  >>  >>             </xs:documentation>
>  >>  >>           </xs:annotation>
>  >>  >>         </xs:any>
>  >>  >>       </xs:choice>
>  >>  >>     </xs:complexType>
>  >>  >>  </xs:element>
>  >>  > 
>  >>  > Why allow for minOccurs="0" :
>  >>  > <target></taget>     <------------corret?
>  >>  > 
>  >>  > washam
>  >>  > 
>  >>  BALAZS: Any of the datastores might be absent from the request. 
> The 
>  >> requirement is that at 
>  >>  least one valid datastore name is inserted. So target must occur 
> at 
>  >> least once, which is the 
>  >>  XSD default.
>  > 
>  > I meant '<target></target>' would be correct syntacticly according 
> to this XSD.
>  > <xs:choice> means only one of four child <element>s should be 
> selected. When a <element>
>  > is selected. it is allowed for 0 occurrence.
>  > I suggest omitting 'minOccurs="0"'.
>  > 
>  
>  1) I think you want minOccurs=1, maxOccurs=unbounded for
>      the entire choice, maxOccurs=1 on candidate, running,
>      and startup, and maxOccurs=unbounded on 'any'.
>      You don't need minOccurs=0 on choice members.

Not exactly. I actually want minOccurs=1, maxOccurs=1.
Since <target> allows for one and only one children syntacticly
if I understand correctly.

washam

>  2) The schema implies that all agents will accept this 'any'
>      placeholder parameter, even though :url is required for
>      this feature to have any meaning on the agent.
>  
>  3) This seems to be changing the design of NETCONF operations
>      to introduce arbitrary empty elements instead of the <url> element,
>      used everywhere else in NETCONF.  There is no such thing
>      as a config named <foo/> in NETCONF.  Instead, there is
>      a <url>file:://foo</url> allowed.  IMO, partial-lock should
>      be consistent with existing protocol operations.
>  
>  
>  > washam
>  > 
>  >>  Sorry if I misunderstood your comment.
>  >>  
>  >>  Balazs
>  >>  
>  
>  
>  Andy
>  
>  

Date: Wed, 11 Feb 2009 09:26:19 +0100
From: Balazs Lengyel <[email-masked]>
To: WashamFan <[email-masked]>
Cc: netconf mailing list <[email-masked]>
Subject: Re: [Netconf] Allow other datastores for Netconf

WashamFan wrote:
>>  >>  >>  Proposed changes to XSD:
>>  >>  >>  
>>  >>  >>  <xs:element name="target" maxOccurs="unbounded">  <-------------------
>>  >>  >>     <xs:annotation>
>>  >>  >>       <xs:documentation>
>>  >>  >>         A list of one or more datastore names for NETCONF.
>>  >>  >>         Each target element MUST contain a different
>>  >>  >>         datastore name.
>>  >>  >>       </xs:documentation>
>>  >>  >>     </xs:annotation>
>>  >>  >>     <xs:complexType>
>>  >>  >>       <xs:choice>
>>  >>  >>         <xs:element name="startup" minOccurs="0">
>>  >>  >>           <xs:complexType/>
>>  >>  >>         </xs:element>
>>  >>  >>         <xs:element name="candidate" minOccurs="0">
>>  >>  >>           <xs:complexType/>
>>  >>  >>         </xs:element>
>>  >>  >>         <xs:element name="running" minOccurs="0">
>>  >>  >>           <xs:complexType/>
>>  >>  >>         </xs:element>
>>  >>  >>         <xs:any namespace="##other" minOccurs="0">   <-------------------
>>  >>  >>           <xs:annotation>
>>  >>  >>             <xs:documentation>
>>  >>  >>               The content of this xs:any MUST be a single empty
>>  >>  >>               element referring to an implementation specific
>>  >>  >>               NETCONF datastore that is not one of
>>  >>  >>               startup, running or candidate.
>>  >>  >>             </xs:documentation>
>>  >>  >>           </xs:annotation>
>>  >>  >>         </xs:any>
>>  >>  >>       </xs:choice>
>>  >>  >>     </xs:complexType>
>>  >>  >>  </xs:element>
>>  >>  > 
>>  >>  > Why allow for minOccurs="0" :
>>  >>  > <target></taget>     <------------corret?
>>  >>  > 
>>  >>  > washam
>>  >>  > 
>>  >>  BALAZS: Any of the datastores might be absent from the request. 
>> The 
>>  >> requirement is that at 
>>  >>  least one valid datastore name is inserted. So target must occur 
>> at 
>>  >> least once, which is the 
>>  >>  XSD default.
>>  > 
>>  > I meant '<target></target>' would be correct syntacticly according 
>> to this XSD.
>>  > <xs:choice> means only one of four child <element>s should be 
>> selected. When a <element>
>>  > is selected. it is allowed for 0 occurrence.
>>  > I suggest omitting 'minOccurs="0"'.
>>  > 
>>  
>>  1) I think you want minOccurs=1, maxOccurs=unbounded for
>>      the entire choice, maxOccurs=1 on candidate, running,
>>      and startup, and maxOccurs=unbounded on 'any'.
>>      You don't need minOccurs=0 on choice members.
> 
> Not exactly. I actually want minOccurs=1, maxOccurs=1.
> Since <target> allows for one and only one children syntacticly
> if I understand correctly.
> 

BALAZS: Isn't minOccurs=1, maxOccurs=1 the default in XSD? In that case we don't need anything 
there.
Balazs

Date: Wed, 11 Feb 2009 10:21:38 +0100
From: Balazs Lengyel <[email-masked]>
To: Andy Bierman <[email-masked]>
Cc: netconf mailing list <[email-masked]>
Subject: Re: [Netconf] Allow other datastores for Netconf

Hello,

Andy Bierman wrote:
> 
> 1) I think you want minOccurs=1, maxOccurs=unbounded for
>    the entire choice, maxOccurs=1 on candidate, running,
>    and startup, and maxOccurs=unbounded on 'any'.
>    You don't need minOccurs=0 on choice members.
> 
> 2) The schema implies that all agents will accept this 'any'
>    placeholder parameter, even though :url is required for
>    this feature to have any meaning on the agent.

> 
> 3) This seems to be changing the design of NETCONF operations
>    to introduce arbitrary empty elements instead of the <url> element,
>    used everywhere else in NETCONF.  There is no such thing
>    as a config named <foo/> in NETCONF.  Instead, there is
>    a <url>file:://foo</url> allowed.  IMO, partial-lock should
>    be consistent with existing protocol operations.
> 

BALAZS:

I will ask the basic question.
1) Do we want to prepare partial-lock for addition of other (non-standard) datastores?
2) If the answer 1) is yes how do we want to designate the additional datastores
    2a) like the datastores today with an empty element: <datastoreName/>
    2b) with an URL: <url>file:://foo</url> even though the datastore will often not be a file
    2c) something else

Handling additional datastores is not part of the partial-locking task. So unless we can get 
consensus fast, I think we need to drop the issue from partial-locking. Very fast for me means 
by Monday midnight. I would like the chairmans to explicitly approve this approach.

So please voice your opinion on the two questions!

Votes as I understand today (please correct me if I am wrong):

1)
Yes: Mehmet
No: Andy
Don't care: Balazs, Martin

2a) Balazs
2b) Andy
2c)
Balazs

From: "tom.petch" <[email-masked]>
To: "Romascanu, Dan \(Dan\)" <[email-masked]>, <[email-masked]>
Date: Wed, 11 Feb 2009 11:52:12 +0100
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt
Reply-To: "tom.petch" <[email-masked]>

inline
Tom Petch

----- Original Message -----
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, February 05, 2009 2:13 PM
Subject: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

> This is the AD review for  draft-ietf-netconf-tls-06.txt. I believe that
> this document is in good shape and I am sending it to IETF Last Call.
> The comments below can be dealt with together with the other comments
> that may arrive during the IETF Last Call period.
>
> 1. I believe that there is a need for more clarity in defining the usage
> of the delimiter sequence ]]>]]> after each XML document. The text in
> RFC 4742 seems to me more clear and I suggest to take inspiration from
> it:
>
>    [The] special character sequence,
>    ]]>]]>, MUST be sent by both the client and the server after each XML
>    document in the NETCONF exchange.  This character sequence cannot
>    legally appear in an XML document, so it can be unambiguously used to
>    identify the end of the current document, allowing resynchronization
>    of the NETCONF exchange in the event of an XML syntax or parsing
>    error.
>

There was a discussion on this list at the end of November which said that this
was not true, that the character sequence can validly appear in comments and in
attributes and that this was a problem for Netconf rpc.

Tom Petch

> 2. In section 3.2: 'Typically, the server has no external knowledge of
> what the client's identity ought to be'. I question if this is really
> true in the 'typical' case. I would actually imagine that the case where
> network devices would be preconfigured with information about the
> identity of their managers would be quite common.
>
> 3.   Id-nits complains about the obsolete normative reference: RFC 4366
> (Obsoleted by RFC 5246). I assume this does not change anything wrt. the
> content of the document, but please check.
>
> Dan

From: Ladislav Lhotka <[email-masked]>
To: "tom.petch" <[email-masked]>
Organization: CESNET
Date: Wed, 11 Feb 2009 14:00:07 +0100
Cc: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

tom.petch píše v St 11. 02. 2009 v 11:52 +0100:

> >
> >    [The] special character sequence,
> >    ]]>]]>, MUST be sent by both the client and the server after each XML
> >    document in the NETCONF exchange.  This character sequence cannot
> >    legally appear in an XML document, so it can be unambiguously used to
> >    identify the end of the current document, allowing resynchronization
> >    of the NETCONF exchange in the event of an XML syntax or parsing
> >    error.
> >
> 
> There was a discussion on this list at the end of November which said that this
> was not true, that the character sequence can validly appear in comments and in
> attributes and that this was a problem for Netconf rpc.

Yes, that assumption in RFC 4742 is wrong. The ']]>' and ']]>]]>' can
also legally appear in processing instructions.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

Date: Wed, 11 Feb 2009 15:58:32 +0100
From: Mohamad Badra <[email-masked]>
To: Ladislav Lhotka <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

Ladislav Lhotka

> tom.petch 
>>>   [The] special character sequence,
>>>    ]]>]]>, MUST be sent by both the client and the server after each XML
>>>    document in the NETCONF exchange.  This character sequence cannot
>>>    legally appear in an XML document, so it can be unambiguously used to
>>>    identify the end of the current document, allowing resynchronization
>>>    of the NETCONF exchange in the event of an XML syntax or parsing
>>>    error.
>>>
>>>       
>> There was a discussion on this list at the end of November which said that this
>> was not true, that the character sequence can validly appear in comments and in
>> attributes and that this was a problem for Netconf rpc.
>>     
>
> Yes, that assumption in RFC 4742 is wrong. The ']]>' and ']]>]]>' can
> also legally appear in processing instructions.
>
> Lada
>   
So we need to use another character sequence to identify the end of the XML documents? If then, please don't hesitate to propose it.

Best regards,

Badra

Content-class: urn:content-classes:message
Date: Wed, 11 Feb 2009 16:06:23 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "tom.petch" <[email-masked]>, <[email-masked]>
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

=20

> -----Original Message-----
> From: tom.petch [mailto:[email-masked]]=20
> Sent: Wednesday, February 11, 2009 12:52 PM
> To: Romascanu, Dan (Dan); [email-masked]
> Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt
>=20
> inline
> Tom Petch
>=20
> ----- Original Message -----
> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, February 05, 2009 2:13 PM
> Subject: [Netconf] AD review for draft-ietf-netconf-tls-06.txt
>=20
>=20
> > This is the AD review for  draft-ietf-netconf-tls-06.txt. I believe=20
> > that this document is in good shape and I am sending it to=20
> IETF Last Call.
> > The comments below can be dealt with together with the=20
> other comments=20
> > that may arrive during the IETF Last Call period.
> >
> > 1. I believe that there is a need for more clarity in defining the=20
> > usage of the delimiter sequence ]]>]]> after each XML document. The=20
> > text in RFC 4742 seems to me more clear and I suggest to take=20
> > inspiration from
> > it:
> >
> >    [The] special character sequence,
> >    ]]>]]>, MUST be sent by both the client and the server=20
> after each XML
> >    document in the NETCONF exchange.  This character sequence cannot
> >    legally appear in an XML document, so it can be=20
> unambiguously used to
> >    identify the end of the current document, allowing=20
> resynchronization
> >    of the NETCONF exchange in the event of an XML syntax or parsing
> >    error.
> >
>=20
> There was a discussion on this list at the end of November=20
> which said that this was not true, that the character=20
> sequence can validly appear in comments and in attributes and=20
> that this was a problem for Netconf rpc.
>=20
> Tom Petch
>=20

So are you saying that the character sequence is not an appropriate
delimiter and that this document as well as RFC 4742 when revised should
not make use of it?=20

Dan

Date: Wed, 11 Feb 2009 07:25:40 -0800
From: Andy Bierman <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

Romascanu, Dan (Dan) wrote:
>  
> 
>> -----Original Message-----
>> From: tom.petch [mailto:[email-masked]] 
>> Sent: Wednesday, February 11, 2009 12:52 PM
>> To: Romascanu, Dan (Dan); [email-masked]
>> Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt
>>
>> inline
>> Tom Petch
>>
>> ----- Original Message -----
>> From: "Romascanu, Dan (Dan)" <[email-masked]>
>> To: <[email-masked]>
>> Sent: Thursday, February 05, 2009 2:13 PM
>> Subject: [Netconf] AD review for draft-ietf-netconf-tls-06.txt
>>
>>
>>> This is the AD review for  draft-ietf-netconf-tls-06.txt. I believe 
>>> that this document is in good shape and I am sending it to 
>> IETF Last Call.
>>> The comments below can be dealt with together with the 
>> other comments 
>>> that may arrive during the IETF Last Call period.
>>>
>>> 1. I believe that there is a need for more clarity in defining the 
>>> usage of the delimiter sequence ]]>]]> after each XML document. The 
>>> text in RFC 4742 seems to me more clear and I suggest to take 
>>> inspiration from
>>> it:
>>>
>>>    [The] special character sequence,
>>>    ]]>]]>, MUST be sent by both the client and the server 
>> after each XML
>>>    document in the NETCONF exchange.  This character sequence cannot
>>>    legally appear in an XML document, so it can be 
>> unambiguously used to
>>>    identify the end of the current document, allowing 
>> resynchronization
>>>    of the NETCONF exchange in the event of an XML syntax or parsing
>>>    error.
>>>
>> There was a discussion on this list at the end of November 
>> which said that this was not true, that the character 
>> sequence can validly appear in comments and in attributes and 
>> that this was a problem for Netconf rpc.
>>
>> Tom Petch
>>
> 
> So are you saying that the character sequence is not an appropriate
> delimiter and that this document as well as RFC 4742 when revised should
> not make use of it? 
> 

Has the current end-of-message sequence caused any inter-operability
problems, or just theoretical problems that only occur in test suites?

I prefer to leave the EOM framing alone.
It seems to be working fine in the real world.
It allows the code at the SSH channel level to
ignore XML and look at a byte stream instead.

Changing the way sessions and message framing works are
fairly large changes, which would require a new protocol
version, and making the current version obsolete.

> Dan

Andy

From: "tom.petch" <[email-masked]>
To: "Andy Bierman" <[email-masked]>, "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 11 Feb 2009 18:55:17 +0100
Cc: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt
Reply-To: "tom.petch" <[email-masked]>

----- Original Message ----- 
From: "Andy Bierman" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: "tom.petch" <[email-masked]>; <[email-masked]>
Sent: Wednesday, February 11, 2009 4:25 PM
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

> Romascanu, Dan (Dan) wrote:
> >  
> >> -----Original Message-----
> >> From: tom.petch [mailto:[email-masked]] 
> >> Sent: Wednesday, February 11, 2009 12:52 PM
> >> To: Romascanu, Dan (Dan); [email-masked]
> >> Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt
> >>
> >> inline
> >> Tom Petch
> >>
> >> ----- Original Message -----
> >> From: "Romascanu, Dan (Dan)" <[email-masked]>
> >> To: <[email-masked]>
> >> Sent: Thursday, February 05, 2009 2:13 PM
> >> Subject: [Netconf] AD review for draft-ietf-netconf-tls-06.txt
> >>
> >>
> >>> This is the AD review for  draft-ietf-netconf-tls-06.txt. I believe 
> >>> that this document is in good shape and I am sending it to 
> >> IETF Last Call.
> >>> The comments below can be dealt with together with the 
> >> other comments 
> >>> that may arrive during the IETF Last Call period.
> >>>
> >>> 1. I believe that there is a need for more clarity in defining the 
> >>> usage of the delimiter sequence ]]>]]> after each XML document. The 
> >>> text in RFC 4742 seems to me more clear and I suggest to take 
> >>> inspiration from
> >>> it:
> >>>
> >>>    [The] special character sequence,
> >>>    ]]>]]>, MUST be sent by both the client and the server 
> >> after each XML
> >>>    document in the NETCONF exchange.  This character sequence cannot
> >>>    legally appear in an XML document, so it can be 
> >> unambiguously used to
> >>>    identify the end of the current document, allowing 
> >> resynchronization
> >>>    of the NETCONF exchange in the event of an XML syntax or parsing
> >>>    error.
> >>>
> >> There was a discussion on this list at the end of November 
> >> which said that this was not true, that the character 
> >> sequence can validly appear in comments and in attributes and 
> >> that this was a problem for Netconf rpc.
> >>
> >> Tom Petch
> > 
> > So are you saying that the character sequence is not an appropriate
> > delimiter and that this document as well as RFC 4742 when revised should
> > not make use of it? 
> > 
> 
> Has the current end-of-message sequence caused any inter-operability
> problems, or just theoretical problems that only occur in test suites?
> 
> I prefer to leave the EOM framing alone.
> It seems to be working fine in the real world.
> It allows the code at the SSH channel level to
> ignore XML and look at a byte stream instead.
> 
> Changing the way sessions and message framing works are
> fairly large changes, which would require a new protocol
> version, and making the current version obsolete.
> 

I haven't done my homework and so don't know how significant an
exposure this is.  For the moment, I do not think that we should change
the protocol but we should reword the paragraph in this I-D to flag
the fact that we no longer think this as safe as we once thought.

And then, perhaps, raise a clarifying erratum to RFC4742.

Tom Petch

> > Dan

From: Ladislav Lhotka <[email-masked]>
To: [email-masked]
Organization: CESNET
Date: Wed, 11 Feb 2009 20:16:01 +0100
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

Andy Bierman píše v St 11. 02. 2009 v 07:25 -0800:
> Has the current end-of-message sequence caused any inter-operability
> problems, or just theoretical problems that only occur in test suites?

I don't know, but in any case this hack doesn't work as well as the
authors expected.

> 
> I prefer to leave the EOM framing alone.
> It seems to be working fine in the real world.
> It allows the code at the SSH channel level to
> ignore XML and look at a byte stream instead.

A processing instruction, e.g., <?NETCONF:EOM?>, would be a cleaner way
to achieve the same and the low-level code wouldn't have to parse XML
either.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

Date: Wed, 11 Feb 2009 21:03:52 +0100 (CET)
From: "Mohamad Badra" <[email-masked]>
To: "Ladislav Lhotka" <[email-masked]>
Importance: Normal
Cc: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt
Reply-To: [email-masked]

>> I prefer to leave the EOM framing alone.
>> It seems to be working fine in the real world.
>> It allows the code at the SSH channel level to
>> ignore XML and look at a byte stream instead.
>
> A processing instruction, e.g., <?NETCONF:EOM?>, would be a cleaner way
> to achieve the same and the low-level code wouldn't have to parse XML
> either.

Do we really need a processing instruction, or a character sequence will
be sufficient?

Best regards,
-- 
Mohamad Badra
CNRS - LIMOS Laboratory

From: Ladislav Lhotka <[email-masked]>
To: [email-masked]
Organization: CESNET
Date: Wed, 11 Feb 2009 21:20:45 +0100
Cc: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

Mohamad Badra píše v St 11. 02. 2009 v 21:03 +0100:
> >> I prefer to leave the EOM framing alone.
> >> It seems to be working fine in the real world.
> >> It allows the code at the SSH channel level to
> >> ignore XML and look at a byte stream instead.
> >
> > A processing instruction, e.g., <?NETCONF:EOM?>, would be a cleaner way
> > to achieve the same and the low-level code wouldn't have to parse XML
> > either.
> 
> 
> Do we really need a processing instruction, or a character sequence will
> be sufficient?

I am afraid there is no character sequence that would work without
exceptions (i.e., that can appear nowhere in an XML document), ']]>]]>'
is about the best you can get.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

To: Ladislav Lhotka <[email-masked]>
Date: Wed, 11 Feb 2009 15:56:49 -0500
From: Phil Shafer <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

Ladislav Lhotka writes:
>A processing instruction, e.g., <?NETCONF:EOM?>, would be a cleaner way
>to achieve the same and the low-level code wouldn't have to parse XML
>either.

A PI has the same issues (ie. put it in a CDATA).  Without a real
framing protocol, there's no way to avoid parsing XML as XML.

Thanks,
 Phil

Date: Wed, 11 Feb 2009 22:28:46 +0100 (CET)
From: "Mohamad Badra" <[email-masked]>
To: "Phil Shafer" <[email-masked]>
Importance: Normal
Cc: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt
Reply-To: [email-masked]

> Ladislav Lhotka writes:
>>A processing instruction, e.g., <?NETCONF:EOM?>, would be a cleaner way
>>to achieve the same and the low-level code wouldn't have to parse XML
>>either.
>
> A PI has the same issues (ie. put it in a CDATA).  Without a real
> framing protocol, there's no way to avoid parsing XML as XML.
>
> Thanks,
>  Phil

I don't know if this requires updating RFC4741, a separated document, or a
sub-section to be added to the related transport protocols (SSH, TLS).

Best regards,
-- 
Mohamad Badra
CNRS - LIMOS Laboratory

Date: Wed, 11 Feb 2009 22:43:41 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked], Phil Shafer <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt
Reply-To: [email-masked]

On Wed, Feb 11, 2009 at 10:28:46PM +0100, Mohamad Badra wrote:
> 
> > Ladislav Lhotka writes:
> >>A processing instruction, e.g., <?NETCONF:EOM?>, would be a cleaner way
> >>to achieve the same and the low-level code wouldn't have to parse XML
> >>either.
> >
> > A PI has the same issues (ie. put it in a CDATA).  Without a real
> > framing protocol, there's no way to avoid parsing XML as XML.
> >
> > Thanks,
> >  Phil
> 
> I don't know if this requires updating RFC4741, a separated document, or a
> sub-section to be added to the related transport protocols (SSH, TLS).

As Phil says, the solution is to slowly require that implementations
parse the XML. The RFC4741 erratum should therefore explain that the
delimiter does not always work as expected and that implementators are
advised to parse the XML instead of blindly relying on the delimiter.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

Date: Wed, 11 Feb 2009 23:12:47 +0100 (CET)
From: "Mohamad Badra" <[email-masked]>
To: [email-masked]
Importance: Normal
Cc: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt
Reply-To: [email-masked]

> On Wed, Feb 11, 2009 at 10:28:46PM +0100, Mohamad Badra wrote:
>>
>> > Ladislav Lhotka writes:
>> >>A processing instruction, e.g., <?NETCONF:EOM?>, would be a cleaner
>> way
>> >>to achieve the same and the low-level code wouldn't have to parse XML
>> >>either.
>> >
>> > A PI has the same issues (ie. put it in a CDATA).  Without a real
>> > framing protocol, there's no way to avoid parsing XML as XML.
>> >
>> > Thanks,
>> >  Phil
>>
>> I don't know if this requires updating RFC4741, a separated document, or
>> a
>> sub-section to be added to the related transport protocols (SSH, TLS).
>
> As Phil says, the solution is to slowly require that implementations
> parse the XML. The RFC4741 erratum should therefore explain that the
> delimiter does not always work as expected and that implementators are
> advised to parse the XML instead of blindly relying on the delimiter.

OK. So what about replacing:

   Current NETCONF messages don't include a message's length.  This
   document uses consequently the same delimiter sequence defined in
   [RFC4742] and therefore the special character sequence, ]]>]]>, to
   delimit XML documents.

With:

   Current NETCONF messages don't include a message's length.  [RFC4742]
   uses a special delimiter sequence to delimit XML documents.  However,
   the delimiter does not always work as expected.  It is RECOMMENDED that
   implementations of this document parse the XML instead of blindly
   relying on the delimiter.

Comments?

Best regards,
Badra

To: [email-masked]
Date: Wed, 11 Feb 2009 17:10:05 -0500
From: Phil Shafer <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

Juergen Schoenwaelder writes:
>As Phil says, the solution is to slowly require that implementations
>parse the XML. The RFC4741 erratum should therefore explain that the
>delimiter does not always work as expected and that implementators are
>advised to parse the XML instead of blindly relying on the delimiter.

Parsing XML is painful, since many XML parsers are "pull" based.
I've tried pre-parsing (with a low quality parser) to be able to
insert an EOF at the appropriate place, with mixed results (and
lots of hand washing after).  There seems to be no interest in
adding a real framing protocol, and no easy way to do it, so we're
mostly stuck.

Hmm... try this one on:

Given that "]]>]]>" can only appear in attributes, we'll see real
EOFs as:

   </{rpc,rpc-reply,notification,hello}>[ \t\n]*]]>]]>

one could say that EOF is really:

   '<' [^"']+ ']]>]]>'

So find "]]>]]>", look backwards for "<" or quotes and if you find
the former before that latter, it's quitting time.

Does that make sense?

Thanks,
 Phil

Date: Thu, 12 Feb 2009 02:13:49 +0100 (CET)
From: "Mohamad Badra" <[email-masked]>
To: [email-masked]
Importance: Normal
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt
Reply-To: [email-masked]

> Parsing XML is painful, since many XML parsers are "pull" based.
> I've tried pre-parsing (with a low quality parser) to be able to
> insert an EOF at the appropriate place, with mixed results (and
> lots of hand washing after).  There seems to be no interest in
> adding a real framing protocol, and no easy way to do it, so we're
> mostly stuck.
>
> Hmm... try this one on:
>
> Given that "]]>]]>" can only appear in attributes, we'll see real
> EOFs as:
>
>    </{rpc,rpc-reply,notification,hello}>[ \t\n]*]]>]]>
>
> one could say that EOF is really:
>
>    '<' [^"']+ ']]>]]>'
>
> So find "]]>]]>", look backwards for "<" or quotes and if you find
> the former before that latter, it's quitting time.
>
> Does that make sense?
>
> Thanks,
>  Phil

Here is a proposition with regards to Phil's proposal. Any other text is
wellcome.

   Current NETCONF messages don't include a message's length.  This
   document uses consequently the same delimiter sequence defined in
   [RFC4742] and therefore the special character sequence, ]]>]]>, to
   delimit XML documents. This character sequence MUST be sent by both the
   client and the server after each XML document in the NETCONF exchange.
   That special character sequence may appear in a valid NETCONF message.
   For that, and after finding the special character sequence, the entity
   (the client or the server) MUST look for the next character. If the
   next character is <, then the special character sequence identify the
   end of the current document. Else, the entity MUST consider the special
   character sequence as part of the current document and then repeat the
   same above operations to identify the end of the current document.

Comments?

Best regards,
-- 
Mohamad Badra
CNRS - LIMOS Laboratory

Date: Thu, 12 Feb 2009 06:41:24 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt
Reply-To: [email-masked]

On Thu, Feb 12, 2009 at 02:13:49AM +0100, Mohamad Badra wrote:

> Here is a proposition with regards to Phil's proposal. Any other text is
> wellcome.
> 
>    Current NETCONF messages don't include a message's length.  This
>    document uses consequently the same delimiter sequence defined in
>    [RFC4742] and therefore the special character sequence, ]]>]]>, to
>    delimit XML documents. This character sequence MUST be sent by both the
>    client and the server after each XML document in the NETCONF exchange.
>    That special character sequence may appear in a valid NETCONF message.
>    For that, and after finding the special character sequence, the entity
>    (the client or the server) MUST look for the next character. If the
>    next character is <, then the special character sequence identify the
>    end of the current document. Else, the entity MUST consider the special
>    character sequence as part of the current document and then repeat the
>    same above operations to identify the end of the current document.

Are we sure ]]>]]>< is significantly bettern than ]]>]]>??

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

From: WashamFan <[email-masked]>
To: [email-masked]
Date: Thu, 12 Feb 2009 14:19:17 +0800
Priority: normal
Cc: [email-masked], [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

Hi,
> On Thu, Feb 12, 2009 at 02:13:49AM +0100, Mohamad Badra wrote:
>  
>  > Here is a proposition with regards to Phil's proposal. Any other 
> text is
>  > wellcome.
>  > 
>  >    Current NETCONF messages don't include a message's length.  This
>  >    document uses consequently the same delimiter sequence defined in
>  >    [RFC4742] and therefore the special character sequence, ]]>]]>, 
> to
>  >    delimit XML documents. This character sequence MUST be sent by 
> both the
>  >    client and the server after each XML document in the NETCONF exchange.
>  >    That special character sequence may appear in a valid NETCONF message.
>  >    For that, and after finding the special character sequence, the 
> entity
>  >    (the client or the server) MUST look for the next character. If 
> the
>  >    next character is <, then the special character sequence 
> identify the
>  >    end of the current document. Else, the entity MUST consider the 
> special
>  >    character sequence as part of the current document and then 
> repeat the
>  >    same above operations to identify the end of the current document.
>  
>  Are we sure ]]>]]>< is significantly bettern than ]]>]]>??

How about the last XML document? There is no < following ]]>]]>.

>  /js

Date: Thu, 12 Feb 2009 00:06:12 -0800
From: Andy Bierman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

Juergen Schoenwaelder wrote:
> On Thu, Feb 12, 2009 at 02:13:49AM +0100, Mohamad Badra wrote:
> 
>> Here is a proposition with regards to Phil's proposal. Any other text is
>> wellcome.
>>
>>    Current NETCONF messages don't include a message's length.  This
>>    document uses consequently the same delimiter sequence defined in
>>    [RFC4742] and therefore the special character sequence, ]]>]]>, to
>>    delimit XML documents. This character sequence MUST be sent by both the
>>    client and the server after each XML document in the NETCONF exchange.
>>    That special character sequence may appear in a valid NETCONF message.
>>    For that, and after finding the special character sequence, the entity
>>    (the client or the server) MUST look for the next character. If the
>>    next character is <, then the special character sequence identify the
>>    end of the current document. Else, the entity MUST consider the special
>>    character sequence as part of the current document and then repeat the
>>    same above operations to identify the end of the current document.
> 
> Are we sure ]]>]]>< is significantly bettern than ]]>]]>??
> 

Hmmm...
This is the question that should have been answered correctly
the first time around.

It has been suggested that a change like this could be
made with the errata publication process.  I strongly disagree
with that position, since the EOM marker is specified in RFC 4741
EXACTLY as the NETCONF WG intended at the time of RFC publication.
The current EOM is not incorrect due to a typo or unspecified
and in need of clarification.  Changing this EOM mechanism
requires a new SSH transport and protocol version, which will be
incompatible with the current 4741/4742 version.

> /js

Andy

From: Ladislav Lhotka <[email-masked]>
To: Phil Shafer <[email-masked]>
Organization: CESNET
Date: Thu, 12 Feb 2009 09:31:15 +0100
Cc: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

Phil Shafer píše v St 11. 02. 2009 v 15:56 -0500:
> Ladislav Lhotka writes:
> >A processing instruction, e.g., <?NETCONF:EOM?>, would be a cleaner way
> >to achieve the same and the low-level code wouldn't have to parse XML
> >either.
> 
> A PI has the same issues (ie. put it in a CDATA).  Without a real
> framing protocol, there's no way to avoid parsing XML as XML.

Agreed. I found an interesting thread back from 2004 starting with
Andy's message

http://www.ops.ietf.org/lists/netconf/netconf.2004/msg00158.html

where the various EOM approaches were nicely discussed. I wasn't able to
find though why the ']]>]]>' marker was eventually selected.

Lada

> Thanks,
>  Phil
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

Date: Thu, 12 Feb 2009 09:56:55 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Andy Bierman <[email-masked]>
Mail-Followup-To: Andy Bierman <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt
Reply-To: [email-masked]

On Thu, Feb 12, 2009 at 12:06:12AM -0800, Andy Bierman wrote:
> Juergen Schoenwaelder wrote:
>> On Thu, Feb 12, 2009 at 02:13:49AM +0100, Mohamad Badra wrote:
>>
>>> Here is a proposition with regards to Phil's proposal. Any other text is
>>> wellcome.
>>>
>>>    Current NETCONF messages don't include a message's length.  This
>>>    document uses consequently the same delimiter sequence defined in
>>>    [RFC4742] and therefore the special character sequence, ]]>]]>, to
>>>    delimit XML documents. This character sequence MUST be sent by both the
>>>    client and the server after each XML document in the NETCONF exchange.
>>>    That special character sequence may appear in a valid NETCONF message.
>>>    For that, and after finding the special character sequence, the entity
>>>    (the client or the server) MUST look for the next character. If the
>>>    next character is <, then the special character sequence identify the
>>>    end of the current document. Else, the entity MUST consider the special
>>>    character sequence as part of the current document and then repeat the
>>>    same above operations to identify the end of the current document.
>>
>> Are we sure ]]>]]>< is significantly bettern than ]]>]]>??
>>
>
> Hmmm...
> This is the question that should have been answered correctly
> the first time around.
>
> It has been suggested that a change like this could be
> made with the errata publication process.  

This is simply not true. You are mixing up statements, please read the
thread again.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

Date: Thu, 12 Feb 2009 11:10:15 +0100
From: Mohamad Badra <[email-masked]>
To: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

>>    Current NETCONF messages don't include a message's length.  This
>>    document uses consequently the same delimiter sequence defined in
>>    [RFC4742] and therefore the special character sequence, ]]>]]>, to
>>    delimit XML documents. This character sequence MUST be sent by both the
>>    client and the server after each XML document in the NETCONF exchange.
>>    That special character sequence may appear in a valid NETCONF message.
>>    For that, and after finding the special character sequence, the entity
>>    (the client or the server) MUST look for the next character. If the
>>    next character is <, then the special character sequence identify the
>>    end of the current document. Else, the entity MUST consider the special
>>    character sequence as part of the current document and then repeat the
>>    same above operations to identify the end of the current document.
>>     
>
> Are we sure ]]>]]>< is significantly bettern than ]]>]]>??
>
>   

No idea, but the text proposes using ]]>]]> and not ]]>]]><

Best regards,

Badra

Date: Thu, 12 Feb 2009 11:09:18 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Mohamad Badra <[email-masked]>
Mail-Followup-To: Mohamad Badra <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt
Reply-To: [email-masked]

On Thu, Feb 12, 2009 at 11:10:15AM +0100, Mohamad Badra wrote:
>
>>>    Current NETCONF messages don't include a message's length.  This
>>>    document uses consequently the same delimiter sequence defined in
>>>    [RFC4742] and therefore the special character sequence, ]]>]]>, to
>>>    delimit XML documents. This character sequence MUST be sent by both the
>>>    client and the server after each XML document in the NETCONF exchange.
>>>    That special character sequence may appear in a valid NETCONF message.
>>>    For that, and after finding the special character sequence, the entity
>>>    (the client or the server) MUST look for the next character. If the
>>>    next character is <, then the special character sequence identify the
>>>    end of the current document. Else, the entity MUST consider the special
>>>    character sequence as part of the current document and then repeat the
>>>    same above operations to identify the end of the current document.
>>>     
>>
>> Are we sure ]]>]]>< is significantly bettern than ]]>]]>??
>
> No idea, but the text proposes using ]]>]]> and not ]]>]]><

I read:

  For that, and after finding the special character sequence, the entity
  (the client or the server) MUST look for the next character. If the
  next character is <, then the special character sequence identify the
  end of the current document. Else, the entity MUST consider the special
  character sequence as part of the current document and then repeat the
  same above operations to identify the end of the current document.

How can I have misunderstood this text??? And waiting for the
beginning of the next message to determine the end of a message is
obviously a broken idea.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

Date: Thu, 12 Feb 2009 11:25:07 +0100
From: Mohamad Badra <[email-masked]>
To: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

>>>>    Current NETCONF messages don't include a message's length.  This
>>>>    document uses consequently the same delimiter sequence defined in
>>>>    [RFC4742] and therefore the special character sequence, ]]>]]>, to
>>>>    delimit XML documents. This character sequence MUST be sent by both the
>>>>    client and the server after each XML document in the NETCONF exchange.
>>>>    That special character sequence may appear in a valid NETCONF message.
>>>>    For that, and after finding the special character sequence, the entity
>>>>    (the client or the server) MUST look for the next character. If the
>>>>    next character is <, then the special character sequence identify the
>>>>    end of the current document. Else, the entity MUST consider the special
>>>>    character sequence as part of the current document and then repeat the
>>>>    same above operations to identify the end of the current document.
>>>>     
>>>>         
>>> Are we sure ]]>]]>< is significantly bettern than ]]>]]>??
>>>       
>> No idea, but the text proposes using ]]>]]> and not ]]>]]><
>>     
>
> I read:
>
>   For that, and after finding the special character sequence, the entity
>   (the client or the server) MUST look for the next character. If the
>   next character is <, then the special character sequence identify the
>   end of the current document. Else, the entity MUST consider the special
>   character sequence as part of the current document and then repeat the
>   same above operations to identify the end of the current document.
>
> How can I have misunderstood this text??? And waiting for the
> beginning of the next message to determine the end of a message is
> obviously a broken idea.
>   

I don't know if there is a better way to delimit XML documents using a special character sequence, which may appear in a legal NETCONF message.

Best regards,
Badra

To: [email-masked]
Date: Thu, 12 Feb 2009 08:12:23 -0500
From: Phil Shafer <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

Juergen Schoenwaelder writes:
>Are we sure ]]>]]>< is significantly bettern than ]]>]]>??

It's much worse, since one doesn't know when or if the next
character will arrive.

Thanks,
 Phil

From: "Bert Wijnen \(IETF\)" <[email-masked]>
To: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 12 Feb 2009 14:30:48 +0100
Organization: Consultant
Cc: Netconf <[email-masked]>
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

Dear WG participants,

I would like to ask for implementers and people who deploy implementations
what the answer is to this question:

   Has the current end-of-message sequence caused any inter-operability
   problems, or just theoretical problems that only occur in test suites?

IF there are no real pragmatic/practical/operational problems, then do we
really need (want) to cover all possible/theoretical corner cases?

The question is even more relevant, since it seems that we would have to
do have a new protocol version if we want to change it consistently, that
is also for SSH.

I can agree with Dan, that we should make the text clear. And adding
a sentence that in theory the sequence could legally occur in an XML
sequence is fine. I guess if that is the case, then using it as an EOM,
that means that such a message would be dropped/grabled/mis-interpreted.
So what? The message is: PLEASE DO NOT put that sequence in
the XML content. In fact, by specifying it as an EOM sequence I think
we implicitly made that statement in RFC47x.

Bert

----- Original Message ----- 
From: Andy Bierman 
To: Romascanu, Dan (Dan) 
Cc: [email-masked] 
Sent: Wednesday, February 11, 2009 4:25 PM
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

Romascanu, Dan (Dan) wrote:
>  
> 
>> -----Original Message-----
>> From: tom.petch [mailto:[email-masked]] 
>> Sent: Wednesday, February 11, 2009 12:52 PM
>> To: Romascanu, Dan (Dan); [email-masked]
>> Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt
>>
>> inline
>> Tom Petch
>>
>> ----- Original Message -----
>> From: "Romascanu, Dan (Dan)" <[email-masked]>
>> To: <[email-masked]>
>> Sent: Thursday, February 05, 2009 2:13 PM
>> Subject: [Netconf] AD review for draft-ietf-netconf-tls-06.txt
>>
>>
>>> This is the AD review for  draft-ietf-netconf-tls-06.txt. I believe 
>>> that this document is in good shape and I am sending it to 
>> IETF Last Call.
>>> The comments below can be dealt with together with the 
>> other comments 
>>> that may arrive during the IETF Last Call period.
>>>
>>> 1. I believe that there is a need for more clarity in defining the 
>>> usage of the delimiter sequence ]]>]]> after each XML document. The 
>>> text in RFC 4742 seems to me more clear and I suggest to take 
>>> inspiration from
>>> it:
>>>
>>>    [The] special character sequence,
>>>    ]]>]]>, MUST be sent by both the client and the server 
>> after each XML
>>>    document in the NETCONF exchange.  This character sequence cannot
>>>    legally appear in an XML document, so it can be 
>> unambiguously used to
>>>    identify the end of the current document, allowing 
>> resynchronization
>>>    of the NETCONF exchange in the event of an XML syntax or parsing
>>>    error.
>>>
>> There was a discussion on this list at the end of November 
>> which said that this was not true, that the character 
>> sequence can validly appear in comments and in attributes and 
>> that this was a problem for Netconf rpc.
>>
>> Tom Petch
>>
> 
> So are you saying that the character sequence is not an appropriate
> delimiter and that this document as well as RFC 4742 when revised should
> not make use of it? 
> 

Has the current end-of-message sequence caused any inter-operability
problems, or just theoretical problems that only occur in test suites?

I prefer to leave the EOM framing alone.
It seems to be working fine in the real world.
It allows the code at the SSH channel level to
ignore XML and look at a byte stream instead.

Changing the way sessions and message framing works are
fairly large changes, which would require a new protocol
version, and making the current version obsolete.

> Dan

Andy

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

To: Mohamad Badra <[email-masked]>
Date: Thu, 12 Feb 2009 08:15:07 -0500
From: Phil Shafer <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

Mohamad Badra writes:
>I don't know if there is a better way to delimit XML documents using a special character
> sequence, which may appear in a legal NETCONF message.

Does the algorithm I suggested work?

Thanks,
 Phil

To: Andy Bierman <[email-masked]>
Date: Thu, 12 Feb 2009 08:17:51 -0500
From: Phil Shafer <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

Andy Bierman writes:
>The current EOM is not incorrect due to a typo or unspecified
>and in need of clarification.

It contains a typo in that it needs to be noted that the sequence
can appear inside valid data and additional checks are needed to
avoid confusion with attributes containing the value "]]>]]>".

I don't think anyone is suggesting that we can undo use of this
delimiter in any manner that breaks backwards compatibility.

Thanks,
 Phil

From: Ladislav Lhotka <[email-masked]>
To: [email-masked]
Organization: CESNET
Date: Thu, 12 Feb 2009 14:37:05 +0100
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

Phil Shafer píše v St 11. 02. 2009 v 17:10 -0500:
> 
> Given that "]]>]]>" can only appear in attributes, we'll see real
> EOFs as:

No, it can also appear in comments and PIs.

Lada

> 
>    </{rpc,rpc-reply,notification,hello}>[ \t\n]*]]>]]>
> 
> one could say that EOF is really:
> 
>    '<' [^"']+ ']]>]]>'
> 
> So find "]]>]]>", look backwards for "<" or quotes and if you find
> the former before that latter, it's quitting time.
> 
> Does that make sense?
> 
> Thanks,
>  Phil
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

Date: Thu, 12 Feb 2009 14:48:56 +0100
From: Mohamad Badra <[email-masked]>
CC: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

>> I don't know if there is a better way to delimit XML documents using a special character
>> sequence, which may appear in a legal NETCONF message.
>>     
>
> Does the algorithm I suggested work?
>
>   

In fact, I was talking about the algorithm you suggested when I said that I don't know a better way.

Best regards,
Badra

Date: Thu, 12 Feb 2009 14:53:10 +0100 (CET)
To: [email-masked]
From: Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

"Bert Wijnen \(IETF\)" <[email-masked]> wrote:
> Dear WG participants,
> 
> I would like to ask for implementers and people who deploy implementations
> what the answer is to this question:
> 
>    Has the current end-of-message sequence caused any inter-operability
>    problems, or just theoretical problems that only occur in test suites?
> 
> IF there are no real pragmatic/practical/operational problems, then do we
> really need (want) to cover all possible/theoretical corner cases?

No, I agree with you.  Changing this now is guaranteed to lead to
interoperability problems.   We can make it clear in the update to
4741 that this sequence MUST NOT occur in the paylod.

/martin

To: Ladislav Lhotka <[email-masked]>
Date: Thu, 12 Feb 2009 08:39:45 -0500
From: Phil Shafer <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

Ladislav Lhotka writes:
>Phil Shafer píše v St 11. 02. 2009 v 17:10 -0500:
>No, it can also appear in comments and PIs.

Worse: PIs can have any text except "?>", which means that
parsing backwards is simply impossible.

<?bad mumble]]>]]>mumble?>
<?worse <?mumble?>
<?worstest <!--yup?>

So the EOM is worthless as anything more than a sanity check.

Thanks,
 Phil

From: Ladislav Lhotka <[email-masked]>
To: [email-masked]
Organization: CESNET
Date: Thu, 12 Feb 2009 15:21:20 +0100
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

Martin Bjorklund píše v Čt 12. 02. 2009 v 14:53 +0100:
> "Bert Wijnen \(IETF\)" <[email-masked]> wrote:
> > Dear WG participants,
> > 
> > I would like to ask for implementers and people who deploy implementations
> > what the answer is to this question:
> > 
> >    Has the current end-of-message sequence caused any inter-operability
> >    problems, or just theoretical problems that only occur in test suites?
> > 
> > IF there are no real pragmatic/practical/operational problems, then do we
> > really need (want) to cover all possible/theoretical corner cases?
> 
> No, I agree with you.  Changing this now is guaranteed to lead to
> interoperability problems.   We can make it clear in the update to
> 4741 that this sequence MUST NOT occur in the paylod.

Then it will be probably better to define this sequence as the only
possible character-level EOM marker to prevent other transports from
complicating things further by inventing new ones. My opinion is that a
PI would have been a better choice, but if it's too late, ']]>]]>'
should work reasonably well, too.

Lada

> 
> 
> /martin
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

To: Ladislav Lhotka <[email-masked]>
Date: Thu, 12 Feb 2009 13:18:50 -0500
From: Phil Shafer <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

>Martin Bjorklund píše v Čt 12. 02. 2009 v 14:53 +0100:
>> No, I agree with you.  Changing this now is guaranteed to lead to
>> interoperability problems.   We can make it clear in the update to
>> 4741 that this sequence MUST NOT occur in the paylod.

Are you suggesting that we force non-EOM use of the EOM to be
escaped?

Ladislav Lhotka writes:
>Then it will be probably better to define this sequence as the only
>possible character-level EOM marker to prevent other transports from
>complicating things further by inventing new ones.

Other transports may opt for real framing mechanisms and not need
this EOM marker.  SOAP and BEEP do not need it.

>My opinion is that a
>PI would have been a better choice, but if it's too late, ']]>]]>'
>should work reasonably well, too.

Given that the PI string can appear in comments, wouldn't it
have the same issues?

Thanks,
 Phil

Date: Thu, 12 Feb 2009 20:42:08 +0100 (CET)
To: [email-masked]
From: Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

UGhpbCBTaGFmZXIgPHBoaWxAanVuaXBlci5uZXQ+IHdyb3RlOg0KPiA+TWFydGluIEJqb3JrbHVu
ZCBww4PCrcOFwqFlIHYgw4TFknQgMTIuIDAyLiAyMDA5IHYgMTQ6NTMgKzAxMDA6DQo+ID4+IE5v
LCBJIGFncmVlIHdpdGggeW91LiAgQ2hhbmdpbmcgdGhpcyBub3cgaXMgZ3VhcmFudGVlZCB0byBs
ZWFkIHRvDQo+ID4+IGludGVyb3BlcmFiaWxpdHkgcHJvYmxlbXMuICAgV2UgY2FuIG1ha2UgaXQg
Y2xlYXIgaW4gdGhlIHVwZGF0ZSB0bw0KPiA+PiA0NzQxIHRoYXQgdGhpcyBzZXF1ZW5jZSBNVVNU
IE5PVCBvY2N1ciBpbiB0aGUgcGF5bG9kLg0KPiANCj4gQXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQg
d2UgZm9yY2Ugbm9uLUVPTSB1c2Ugb2YgdGhlIEVPTSB0byBiZQ0KPiBlc2NhcGVkPw0KDQpZZXMu
DQoNCg0KL21hcnRpbg0K

Date: Thu, 12 Feb 2009 22:00:51 +0100
From: Balazs Lengyel <[email-masked]>
To: [email-masked]
Subject: Re: [Netconf] review of draft-ietf-netconf-monitoring-03a

Some late comments:

Juergen Schoenwaelder wrote:
> 
> z) I fail to see why sourceHost is included at all. The IP address or
>    a DNS name is not sufficient to identify a client in all cases and
>    the value of this diminishes greatly if you have NATs and so on.
>    But the most important problem I have is that an IP address is not
>    a transport endpoint.

BALAZS: This is still often useful. I know about no other easy solution for identifying the 
source of the session, so even if sourceHost is unreliable it is worth the effort. I propose
to keep it.

> 
> G) I tried to draw a case diagram for the counters and I failed. I
>    believe the counters are not well thought out. Perhaps it helps
>    to draw case diagrams and to organize suitable counters along
>    the netconf protocol layers.

BALAZS: E.g. Does inBadHellos count Hellos with parsing errors? (Same question for inBadRpcs)

Balazs

Date: Thu, 12 Feb 2009 22:26:08 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: Balazs Lengyel <[email-masked]>
Mail-Followup-To: Balazs Lengyel <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] review of draft-ietf-netconf-monitoring-03a
Reply-To: [email-masked]

On Thu, Feb 12, 2009 at 10:00:51PM +0100, Balazs Lengyel wrote:
> Some late comments:
>
> Juergen Schoenwaelder wrote:
>>
>> z) I fail to see why sourceHost is included at all. The IP address or
>>    a DNS name is not sufficient to identify a client in all cases and
>>    the value of this diminishes greatly if you have NATs and so on.
>>    But the most important problem I have is that an IP address is not
>>    a transport endpoint.
>
> BALAZS: This is still often useful. I know about no other easy
> solution for identifying the source of the session, so even if
> sourceHost is unreliable it is worth the effort. I propose to keep
> it.

Either do it right or drop it. This is what the IETF used to be strong
at. Since I believe doing this right is really much harder than it
appears, I suggest to drop it.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

Date: Thu, 12 Feb 2009 22:58:12 +0100
From: Balazs Lengyel <[email-masked]>
To: [email-masked]
Subject: Re: [Netconf] review of draft-ietf-netconf-monitoring-03b

Hello,
Some late comments.

Balazs

----------------

General) This document defines 2 capabilities, but does not follow the capability template. 
Some points which I would like to see from that template:
- the capability URNs should be specified in the main part of the document not just in the IANA 
considerations. It should be very clearly stated what the two capabilities mean: e.g. that the 
value NETCONF can be used for schema location can only be used if the schema-retrieval 
capability is used, ...
- that these apabilities have no impact on existing capabilities or operations

I agree with Jurgen that 4741bis MUST clearly state whether new capabilities can be added or 
removed during the session. Earlier Andy sad that removing a capability would break the 
contract specified in the hello message.

2.1.2)
OLD:

      ...  The lockedNodes is the list of
      actual nodes which were locked at the the selection was evaluated.
      This is provided for completeness noting that the list of nodes
      returned by the selection may differ over time.

      Additionally partial lock items will contain both the selection
      and the list of lockedNodes.  The selection is the xpath expression
      which was used to evaluate the list of nodes to lock.

The lockedNodes list is available only for partial-locks.  The list is the primary way of 
maintaining a lock it is not just for completeness.

NEW:

... For partial locks the list of locked nodes is also returned. This list may change over 
time. For partial locks the select expressions originally used to request the lock are also 
returned. Note that the scope of the partial lock is defined by the list of locked nodes. The 
select expression, can indicated the original intended scope of the lock.

2.1.3)
OLD:
At least one schema entry SHOULD be available to support retrieval.
NEW:
At least one location entry SHOULD be available to support retrieval.

We spoke about differentiating between YANG modules, from which only the datatypes, groupings 
are used (via import) and YAMs that really define data nodes. This is missing !!! The same 
problem is valid for other XSD and RNG as well.  !!!!!!!!!!!!!!!!!!!!!!

2.1.5)
I think sessionId should be a key.

2.1.6)
The definitions of the counters are not clear enough. More formulas like the one in the 
definition of inSessions in the XSD would be good.

Do inBadHellos/inBadRpcs include parse errors? I assume No

3.2)
in the sentence in the reply containing the <identifier> ,<version> and
    <location> elements.
include format as well. Its a critical bit of data.

    The response data can be used to determine the available schema and
    their versions.  The schema itself (ie. schema content) is not
    returned in the response.  The details returned in the list SHOULD
    facilitate retrieval from a network location via a URL using a
    supported mechanism on the device such as ftp or http.i

What does "supported mechanism on the device" mean? Reword!

    Additionally the ability to retrieve a schema via NETCONF SHOULD be
    supported.  When a schema is available on the device and the schema-
    retrieval capability is supported by the NETCONF server a location
    value of 'NETCONF' MUST be used to indicate that it can be retrieved
    via NETCONF using the <get-schema> RPC described in section 3.1.

This is the first place were it is mentioned that this draft is defeining a NETCONF capability. 
It is a bit to informal isn't it :-)

5.1)
The default minOccurs="1" maxOccurs="1" should be removed. They just clutter the text.

---
         <xs:element name="schemas" minOccurs="0" maxOccurs="1">

I think the element name should be in singular. minOccurs="0" is not needed, as at least this 
present schema is supported.

---
         <xs:element name="statistics" type="ManagementStatistics"
                     minOccurs="0" maxOccurs="1">

minOccurs="0" seems unneeded. Is it really the intent that statistics might sometimes be 
completely absent? Shouldn't it then rather be a separate capability?

Generally take care whether the plural or singular form of elements names is used. E.g.
<xs:element name="partialLocks"

partialLocks needs minOccurs="0"

-----

<xs:element name="transport"
description should include SOAP, BEEP, TLS

<xs:element name="username"
s/username/userName/

session owner is a bad term. Management user authenticated for the session.

For both subscriptions and partial locks the XSD and YANG should refer to the RFC. Especially 
as the contents of NetconfSubscription don't have any description.

       <xs:element name="filter" type="netconf:filterInlineType"/>
missing minOccurs="0"

----

       <xs:element name="startup" type="xs:string"/>
should be restricted to length=0"  Mismatch with YANG

It is mentioned in a comment that stopTine is optional, but not for startTime. Be consequent.

           <xs:documentation>
             The session Id which holds the lock.
           </xs:documentation>

It should be mentioned that for non-netconf lock the session id contains ... Do it for both 
global and partial locks and for YANG too

TransportType must no be restricted to a fixed set of values. It must include SOAP, BEEP and 
TLS. Same comment for YANG.

ProtocolType must no be restricted to a fixed set of values. Same comment for YANG.

---

The description clause of objects using the
            domainName type MUST describe how (and when)
            these names are resolved to IP addresses.

We do not describe whats required here !

8)
The registration request for the XML namespace is missing. See Notification RFC.

9) Add non-normative reference to YANG

Partial lock is already at revision-06

Appendix A

       leaf-list capability {
         min-elements 1;

there are at least 3 capabilities if this model can be read.

The XML encoding for config datastore namesis different for XSD and YANG

----
         anyxml filter {
           description
             "The filters associated with this subscription.";
         }
  Only one filter can be used. For the content of anyXML include a reference to 4741.

The descriptions of the subscription content is not the same in YANG and XSD. Synchronize!

----

netconfStartTime

Mention that at netconfStartTime=0 all counters are reset to zero.

Date: Thu, 12 Feb 2009 23:10:04 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: "Bert Wijnen (IETF)" <[email-masked]>
Mail-Followup-To: "Bert Wijnen (IETF)" <[email-masked]>, "Romascanu, Dan (Dan)" <[email-masked]>, Netconf <[email-masked]>
Cc: Netconf <[email-masked]>
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt
Reply-To: [email-masked]

On Thu, Feb 12, 2009 at 02:30:48PM +0100, Bert Wijnen (IETF) wrote:

> I would like to ask for implementers and people who deploy implementations
> what the answer is to this question:
>
>   Has the current end-of-message sequence caused any inter-operability
>   problems, or just theoretical problems that only occur in test suites?
>
> IF there are no real pragmatic/practical/operational problems, then do we
> really need (want) to cover all possible/theoretical corner cases?

Operationally, I am not so much concerned. I am more concerned about
someone finding a way to make malicious use of this framing sequence,
e.g. tricking implementations to somehow generate framing sequences
where they should not be and using that to do creative things.

Some people on this list argue that such concerns are not justified
because NETCONF implementations should never generate the framing
sequence and if they do, the (not really defined) NETCONF access
control prevents damage to happen and by tampering with messages, you
will not really be able to do damage but just cause parse errors and
other failures.  My concern is that people might underestimate
creativity of hackers and overestimate the skills of NETCONF
implementors.

But perhaps we are really best of for the moment stating explicitly
that NETCONF implementations MUST ensure that the framing sequence is
never part of a NETCONF message they generate. By stating this
explicitly this, a potential CERT advisory is immediately turned away
from the IETF and hits the implementors.

So the errata becomes to replace the following text

   This character sequence cannot
   legally appear in an XML document, so it can be unambiguously used to
   identify the end of the current document, allowing resynchronization
   of the NETCONF exchange in the event of an XML syntax or parsing
   error.

with for example

   Implementations MUST ensure that this character sequence is never
   part of a NETCONF message.

And someone might formulate some additional text explaining why this
is not a restriction for any data carried in XML elements etc.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

To: [email-masked]
Date: Thu, 12 Feb 2009 18:11:56 -0500
From: Phil Shafer <[email-masked]>
Cc: Netconf <[email-masked]>
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

Juergen Schoenwaelder writes:
>My concern is that people might underestimate
>creativity of hackers and overestimate the skills of NETCONF
>implementors.

I share this concern.  I imagine someone using a provider's
customer-side webapp to make a list member named
"]]>]]><rpc><reboot/></rpc>]]>]]>" and trying to insert an object
in front of this instance.  The backend of the webapp ships it
over without escaping it and poof.  Bad news.

>But perhaps we are really best of for the moment stating explicitly
>that NETCONF implementations MUST ensure that the framing sequence is
>never part of a NETCONF message they generate.

In many cases, the serialization from internal data to stream
content generates data in a way that isn't controllable by the
programmer (like java or perl).  Saying "don't do that" may mean
one cannot use the stock libraries.

IMHO the EOM is not useful in its current form and needs to be
treated as an advisory or "sanity check" mechanism.

Thanks,
 Phil

Date: Thu, 12 Feb 2009 16:19:31 -0800
From: Andy Bierman <[email-masked]>
To: "Bert Wijnen (IETF)" <[email-masked]>,  "Romascanu, Dan (Dan)" <[email-masked]>, Netconf <[email-masked]>
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

Juergen Schoenwaelder wrote:
> On Thu, Feb 12, 2009 at 02:30:48PM +0100, Bert Wijnen (IETF) wrote:
> 
>> I would like to ask for implementers and people who deploy implementations
>> what the answer is to this question:
>>
>>   Has the current end-of-message sequence caused any inter-operability
>>   problems, or just theoretical problems that only occur in test suites?
>>
>> IF there are no real pragmatic/practical/operational problems, then do we
>> really need (want) to cover all possible/theoretical corner cases?
> 
> Operationally, I am not so much concerned. I am more concerned about
> someone finding a way to make malicious use of this framing sequence,
> e.g. tricking implementations to somehow generate framing sequences
> where they should not be and using that to do creative things.
> 
> Some people on this list argue that such concerns are not justified
> because NETCONF implementations should never generate the framing
> sequence and if they do, the (not really defined) NETCONF access
> control prevents damage to happen and by tampering with messages, you
> will not really be able to do damage but just cause parse errors and
> other failures.  My concern is that people might underestimate
> creativity of hackers and overestimate the skills of NETCONF
> implementors.
> 
> But perhaps we are really best of for the moment stating explicitly
> that NETCONF implementations MUST ensure that the framing sequence is
> never part of a NETCONF message they generate. By stating this
> explicitly this, a potential CERT advisory is immediately turned away
> from the IETF and hits the implementors.
> 
> So the errata becomes to replace the following text
> 
>    This character sequence cannot
>    legally appear in an XML document, so it can be unambiguously used to
>    identify the end of the current document, allowing resynchronization
>    of the NETCONF exchange in the event of an XML syntax or parsing
>    error.
> 
> with for example
> 
>    Implementations MUST ensure that this character sequence is never
>    part of a NETCONF message.
> 

This is fine with me.
I prefer to leave the EOM sequence alone.
IMO it is useful because the slightest malformed XML
in a parameter will force a session to terminate,
whereas the <rpc-error> information could be quite
useful to an operator or application developer
trying to use the agent.

Proper access control enforcement is the only way
to protect the agent, and that is not fool-proof either.
Just because it is a little easier for an attacker
to inject a NETCONF PDU with EOM via blind WEB form applications,
it is by no means difficult or impossible.

Assuming that the hacker will not be able to determine
the format of the NETCONF message sent via the WEB form is
very weak security.

Why worry about injecting a <reboot> RPC and not
worry about injecting additional config data into the
original request?  IMO, the EOM marker has nothing to do
with the very real issue of XML data injection (and
session hijacking) via sloppy applications.
Changing the message framing will not help at all.

> And someone might formulate some additional text explaining why this
> is not a restriction for any data carried in XML elements etc.
> 
> /js
> 

Andy

Date: Fri, 13 Feb 2009 02:24:24 +0100 (CET)
From: "Mohamad Badra" <[email-masked]>
To: [email-masked]
Importance: Normal
Cc: Netconf <[email-masked]>
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt
Reply-To: [email-masked]

> On Thu, Feb 12, 2009 at 02:30:48PM +0100, Bert Wijnen (IETF) wrote:
>
>> I would like to ask for implementers and people who deploy
>> implementations
>> what the answer is to this question:
>>
>>   Has the current end-of-message sequence caused any inter-operability
>>   problems, or just theoretical problems that only occur in test suites?
>>
>> IF there are no real pragmatic/practical/operational problems, then do
>> we
>> really need (want) to cover all possible/theoretical corner cases?
>
> Operationally, I am not so much concerned. I am more concerned about
> someone finding a way to make malicious use of this framing sequence,
> e.g. tricking implementations to somehow generate framing sequences
> where they should not be and using that to do creative things.
>
> Some people on this list argue that such concerns are not justified
> because NETCONF implementations should never generate the framing
> sequence and if they do, the (not really defined) NETCONF access
> control prevents damage to happen and by tampering with messages, you
> will not really be able to do damage but just cause parse errors and
> other failures.  My concern is that people might underestimate
> creativity of hackers and overestimate the skills of NETCONF
> implementors.
>
> But perhaps we are really best of for the moment stating explicitly
> that NETCONF implementations MUST ensure that the framing sequence is
> never part of a NETCONF message they generate. By stating this
> explicitly this, a potential CERT advisory is immediately turned away
> from the IETF and hits the implementors.
>
> So the errata becomes to replace the following text
>
>    This character sequence cannot
>    legally appear in an XML document, so it can be unambiguously used to
>    identify the end of the current document, allowing resynchronization
>    of the NETCONF exchange in the event of an XML syntax or parsing
>    error.
>
> with for example
>
>    Implementations MUST ensure that this character sequence is never
>    part of a NETCONF message.

I am fine with that.
Best regards,
Badra

From: Ladislav Lhotka <[email-masked]>
To: Phil Shafer <[email-masked]>
Organization: CESNET
Date: Fri, 13 Feb 2009 10:56:12 +0100
Cc: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

Phil Shafer píše v Čt 12. 02. 2009 v 13:18 -0500:
> 
> >My opinion is that a
> >PI would have been a better choice, but if it's too late, ']]>]]>'
> >should work reasonably well, too.
> 
> Given that the PI string can appear in comments, wouldn't it
> have the same issues?

Yes, but given that RFC 4741bis will have to forbid a string in the PDU
data content, which ']]>]]>' unsuccessfully tried to avoid, a PI is a
more systematic choice that moreover is less likely to appear in the
data by coincidence. This also seemed to be the majority opinion in the
2004 ML thread.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

Date: Fri, 13 Feb 2009 11:04:37 +0100 (CET)
To: [email-masked]
From: Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt

Andy Bierman <[email-masked]> wrote:
> I prefer to leave the EOM sequence alone.

[...]

> IMO, the EOM marker has nothing to do
> with the very real issue of XML data injection (and
> session hijacking) via sloppy applications.
> Changing the message framing will not help at all.

I fully agree with all this.

/martin

Content-class: urn:content-classes:message
Date: Fri, 13 Feb 2009 21:10:44 +0100
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: "Netconf" <[email-masked]>
Cc: [email-masked]
Subject: [Netconf] Consensus verification WAS:RE: AD review for draft-ietf-netconf-tls-06.txt

Dear NETCONF WG,

we had already a long thread on this issue with 47 mails.

As Bert stated in a parallel mail there seems to be no=20
real practical or operational problems with the current=20
end-of-message sequence. In fact changing the current
mechanism would potentially cause problems.

> >    Implementations MUST ensure that this character sequence is never
> >    part of a NETCONF message.

After some of you and the draft author agreed I assume=20
we can see now the small text block above as the WG=20
consensus.

If anybody has any _strong_ objections please provide new
text by Feb 16 by considering the discussion we had already.

Mehmet
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of ext Mohamad Badra
> Sent: Friday, February 13, 2009 2:24 AM
> To: [email-masked]
> Cc: Netconf
> Subject: Re: [Netconf] AD review for draft-ietf-netconf-tls-06.txt
>=20
>=20
> > On Thu, Feb 12, 2009 at 02:30:48PM +0100, Bert Wijnen (IETF) wrote:
> >
> >> I would like to ask for implementers and people who deploy
> >> implementations
> >> what the answer is to this question:
> >>
> >>   Has the current end-of-message sequence caused any=20
> inter-operability
> >>   problems, or just theoretical problems that only occur=20
> in test suites?
> >>
> >> IF there are no real pragmatic/practical/operational=20
> problems, then do
> >> we
> >> really need (want) to cover all possible/theoretical corner cases?
> >
> > Operationally, I am not so much concerned. I am more concerned about
> > someone finding a way to make malicious use of this framing=20
> sequence,
> > e.g. tricking implementations to somehow generate framing sequences
> > where they should not be and using that to do creative things.
> >
> > Some people on this list argue that such concerns are not justified
> > because NETCONF implementations should never generate the framing
> > sequence and if they do, the (not really defined) NETCONF access
> > control prevents damage to happen and by tampering with=20
> messages, you
> > will not really be able to do damage but just cause parse errors and
> > other failures.  My concern is that people might underestimate
> > creativity of hackers and overestimate the skills of NETCONF
> > implementors.
> >
> > But perhaps we are really best of for the moment stating explicitly
> > that NETCONF implementations MUST ensure that the framing=20
> sequence is
> > never part of a NETCONF message they generate. By stating this
> > explicitly this, a potential CERT advisory is immediately=20
> turned away
> > from the IETF and hits the implementors.
> >
> > So the errata becomes to replace the following text
> >
> >    This character sequence cannot
> >    legally appear in an XML document, so it can be=20
> unambiguously used to
> >    identify the end of the current document, allowing=20
> resynchronization
> >    of the NETCONF exchange in the event of an XML syntax or parsing
> >    error.
> >
> > with for example
> >
> >    Implementations MUST ensure that this character sequence is never
> >    part of a NETCONF message.
>=20
>=20
> I am fine with that.
> Best regards,
> Badra
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>=20