Subject: Re: [Netconf] [OPS-DIR] Review of draft-ietf-netconf-rfc5539bis-09

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Apr 2015 12:06:39 +0200

On Tue, Apr 07, 2015 at 11:00:57AM +0200, Stefan Winter wrote:
> 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.

The story is more complicated than that. The original transport for
NETCONF over SSH picked the framing marker under the assumption that
it could not be found in well-formed XML documents. This turned out to
be wrong. Hence, when RFC 5539 was done, the text found in section 2.1
of RFC 5539 was created (but it is essentially only saying the framing
sequence is illegal not how to deal with the situation when it
appears). Later on, the NETCONF over SSH transport mapping got revised
and in order to address framing isssue, a new framing mechanism was
defined. The work on RFC 5539bis was started primarily to align the
two framing mechanisms (and as a consequence text that was valid for
the SSH mapping was copied over the TLS mapping).

Perhaps a better text would be this (replacing the second paragraph in
section 3):

  The previous version [RFC5539] of this document used the framing
  sequence defined in [RFC4742]. This version of the document aligns
  with [RFC6242] and adopts the framing protocol defined in [RFC6242]
  as follows:

> 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.

I do not recall what the rules where when RFC 5539 was approved. But
clearly, this has been a standards-track document and thus the
allocation by an individual can be seen as an error that slipped
through?

/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: Stefan Winter <[email-masked]>
Date: Tue, 07 Apr 2015 11:00:57 +0200

Hello,

"Since this character

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

---

From: Stefan Winter <[email-masked]>
Date: Fri, 10 Apr 2015 07:52:21 +0200

Hello,

> the SSH mapping was copied over the TLS mapping).

Thanks for this extra background - quite complicated indeed.

>   with [RFC6242] and adopts the framing protocol defined in [RFC6242]

Sounds good to me.

> allocation by an individual can be seen as an error that slipped

Probably; TBH, I don't care much about this, just spotted it. I guess
IANA would be the one to raise real concerns if there are any. I would
hope that whatever the process is, the outcome would be that the
assignee in the end is "The IESG".

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473