Last Call Review of draft-ietf-netconf-rfc5539bis-09
review-ietf-netconf-rfc5539bis-09-opsdir-lc-winter-2015-04-09-00

Hello,
	
	I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.
 These comments were written with the intent of improving the
operational aspects of the IETF drafts. Comments that are not addressed
in last call may be included in AD reviews during the IESG review.
Document editors and WG chairs should treat these comments just like any
other last call comments.

I believe the document is ready for publication with nits (see below).

The document is part of the OPS area and thus deals with operations and
management to a great deal. It is well thought-out with version
information and negotiation (new framing vs. old framing is negotiated
with netconf's capability exchange). Backward compatibility with the old
framing is assured.

There is one statement in the draft which seems incorrect or badly
formulated. In section 3, it is stated that:

"The previous version [RFC5539] of this document used the framing
   sequence defined in [RFC4742], under the assumption that it could not
   be found in well-formed XML documents."

That is not true; RFC5539 acknowledged this fact in its own section 2.1:

"Since this character
   sequence can legally appear in plain XML in attribute values,
   comments, and processing instructions, implementations of this
   document MUST ensure that this character sequence is never part of a
   NETCONF message."

Maybe I'm just confused about this. To me it seems like 5539 wasn't
"clean" in the sense that payload could be interpreted as a control
character leading to a premature close of connection (and found this an
acceptable risk). And that its successor does not consider this as
acceptable and ameliorates the situation by establishing a clean frame
for the payload by wrapping the message inside a
<hello>...<close-session> container?

In that case, it would be nice to state it that way.

In another minor note, I see in the RFC5539 and this draft's IANA
Considerations that the Registration Contact for TCP/6513 is
"transferred" from the individual Mohamad Badra to the IESG. Then again,
I see in the port number registration database that no asignee is
currently listed for that port at all?

According to RFC6335 a "transfer" would actually be quite problematic.
As the author, Mohamad, are you suggesting to de-allocate from yourself,
and then re-allocate to the IESG? It would be nice to spell that out
explicitly.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me



http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66




Attachment:


0x8A39DC66.asc




Description:

 application/pgp-keys




Attachment:


signature.asc




Description:

 OpenPGP digital signature