Subject: [Netconf] status WGLC RFC4741bis

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Wed, 20 Oct 2010 15:52:05 +0200

It seems that the WGLC discussion has now died out on the mailing list.
>From re-reading all those comments, I also get the impression that 
there is consensus/agreement on the changes that need to be addressed.

The editors (specifically Martin) is preparing a new revision based
on the result of the discussions. Will probably show up later today.

Our plan as WG-chairs is to allow the WG a few days to quickly check
if the changes are OK. Then ask our Ad to bring it forward to IETF
Last Call and IESG review.

Thanks,
Bert and Mehmet

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Mon, 25 Oct 2010 22:54:26 +0200

I am preparing the write-up and will send it to our AD in a day
or so. The new revision 6 that came out today has some additional text 
in the secuirty considerations section as follows:
>          This section provides security considerations for the base
>          NETCONF message layer and the base operations of the NETCONF
>          protocol. Security considerations for the NETCONF transports
>          are provided in the transport documents and security
>          considerations for the content manipulated by NETCONF can be
>          found in the document defining data models.
>

The Wg did have agreement on that in our reading.

Bert and Mehmet.
----- Original Message ----- 
From: "Bert Wijnen (IETF)" <[email-masked]>
To: "Netconf" <[email-masked]>
Sent: Wednesday, October 20, 2010 3:52 PM
Subject: [Netconf] status WGLC RFC4741bis

Thanks,
Bert and Mehmet

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Tue, 26 Oct 2010 16:09:47 +0200

OK, before sending my document-shepherd write-up to our AD with a request
to consider this document for standards track RFC publication, I of course did another
quite detailed review (I have to, in order to answer all the questions that the
shepherd write-up asks). The document looks really good, except a few editorial
nits/remarks. So I propose that they can be considered initial IETF Last Call comments
(ID cutoff was yday, so Martin cannot quickly submit a new revision).

Here are the things I found. Speak up asap if you disagree with any of this.

The IDNITs page
    http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-netconf-4741bis-06.txt
shows a few warnings and comments as follows:

   Checking nits according to http://www.ietf.org/id-info/checklist :
   -----------------------------------------------------------------------
   == The 'Obsoletes: ' line in the draft header should list only the
      _numbers_ of the RFCs which will be obsoleted by this document (if
      approved); it should not include the word 'RFC' in the list.

   Miscellaneous warnings:
   -------------------------------------------------------------------------
   == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
      or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
      use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
      mean).

      Found 'MUST not' in this paragraph:

      A lock MUST not be granted if either of the following conditions is
      true:

XX-- The document has a disclaimer for pre-RFC5378 work, but was first
      submitted on or after 10 November 2008.  Does it really need the
      disclaimer?

   Checking references for intended status: Proposed Standard
   ----------------------------------------------------------------------------
      (See RFCs 3967 and 4897 for information about using normative references
      to lower-maturity documents in RFCs)

XX-- Possible downref: Non-RFC (?) normative reference: ref. '1'

XX-- Possible downref: Non-RFC (?) normative reference: ref. '2'

   == Outdated reference: A later version (-04) exists of
      draft-ietf-netconf-rfc4742bis-03

   -- Obsolete informational reference (is this intentional?): RFC 4346 (ref.
      '15') (Obsoleted by RFC 5246)

I discussed them with the main editor (Martin) and he agrees to fix then all
except the ones I marked XX, because we know that this is correct.
Futher, I notoced that our figire 1 (which is an update to the one in RFC4741)
also differes from figire 1 in rfc5277. The reason for this is that we have
renamed the layers (to more appropriate names), and so the figure in this
4741bis document is the most accurate and best representation of our
protocol layers. Martin and I have agreed that it is best to add a bullet
to appendix F, to explicitly state that we have changed the names of our
layers (fort clarification) and that as a result figure 1 changed.

I found one place where "data store" is written while "datastore" is
intended (page 18). For consistency and clarity, I think it is best to fix that.

Document Shepherd
Bert