Response to IESG last call comments on NETCONF Notifications

["Sharon Chisholm" <schishol@nortel.com>]

Hi

I sent a separate response to the gen-art review, but for completeness
here I will include the issue for which I have proposed a change to the
document. Please let me know if I've missed any issues. 

I'm not sure whether we should make these changes to the document or
create a series of editing instructions to RFC editor. I await guidance
from the chairs.

1. > 
> * Modification: How can a client modify a subscription? Section 6.5 
> talks about how it cannot be done, but there is no mention of whether 
> this is even possible to do. If not this must be clearly specified.

<sharon>
Subscriptions cannot be modified. I propose adding a sentence to section
1.3 as follows:

  "Note that a subscription cannot be modified once created."
</sharon>

2. sect 2.2.1
  I assume that <eventTime> is of type dateTime!!??
  Would be good to state so.

<sharon>
In section 2.2.1, in the description of eventTime, add the following
text: "This parameter is of type dateTime."
</sharon>

3. on page 14 I see:

   <rpc message-id="101"
      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <get>
      <filter type="subtree">
        <netconf xmlns="urn:ietf:params:xml:ns:netmod:notification">
           <streams/>
         <netconf>
      </filter>
     </get>
   </rpc>


  Should "netmod" be changed into "netconf" !!??
  Actually, I wonder if the line
        <netconf xmlns="urn:ietf:params:xml:ns:netmod:notification">
  should be
        <netconf
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  instead?

  Same question on page 15.

  Mmm... I see it in the Schema on page 17/18 as well. So maybe it is
OK.
  Or is this an accidental inheritance from NETMOD efforts? Is there a
good
  reason to make it netmod and not netconf?

<sharon>
This is intentional. We are defining the protocol and the content in
different parts of the namespace.
</sharon>

4. 

- Page 29/30

   The above fictional notification definition could result in the
   following is a sample notification list, which is used in the
   examples in this section.

  On 2nd line s/is a// >>

<sharon>
Ok.
</sharon>

5. 

- IN IANA Considerations, I guess that instead of
    Following the format in RFC 3688, IANA has made the following
    registration.
  We should have stated:
    Following the format in RFC 3688, IANA is requested to make the
    following registration.
  Oh well... that is what we intended to write ;-)

<sharon>
Add the following text

   -- Editor note to IANA/RFC-Editor: we request that you make these
   --     assignments, in which case it is top be documented as below
</sharon>

6. 
- I wonder how/why
   [XML Schema]
              Fallside, D. and P. Walmsley, "XML Schema Part 0: Primer
              Second Edition", W3C XML Schema, October 2004.
  would/could be a normative reference. It is a "primer", so some
  sort of education/tutorial on XML Schema, no?
  I doubt that that should be normative.
  But I think the issue is that the reference is not so well described.
  I think they mean to point to:

      http://www.w3.org/TR/xmlschema-0/

  Which states:
             XML Schema Part 0: Primer Second Edition
             W3C Recommendation 28 October 2004
  So then it is a W3C recommendation, and then it may make sense as
normative ref.
  I think I would make the reference as follows:

   [XML Schema]
              Fallside, D. and P. Walmsley, "XML Schema Part 0: Primer
              Second Edition", W3C Recommendation, 28 October 2004
              <http://www.w3.org/TR/xmlschema-0/>

<sharon>
That seems to be the same reference. How about

[XML Schema]  Thompson, H., Beech, D., Maloney, M., Mendelsohn, N., "XML
Schema Part 1: Structures Second Edition", W3C Recommendation, 28
October 2004
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html>
</sharon>

7. 
- I guess we should instruct the RFC-Editor to remove Appendix A
  (Change log) right before publication as RFC.

<sharon>
Ok.
</sharon>

8. 
A minor quirk - I see a missing solidus in 3.2.5.1 "<netconf
xmlns="urn:ietf:params:xml:ns:netmod:notification">
           <streams/>
         <netconf>
"

<sharon>
Right. That should be </netconf>
</sharon>

9.

and an uncertainty - the I-D does not register the XML Schema defined in
sections 4 and 3.4, just their targetNamespace; is this intentional?

<sharon>
Section 4 defines: 
   "urn:ietf:params:xml:ns:netconf:notification:1.0"

Section 3,4 defines:
	"urn:ietf:params:xml:ns:netmod:notification"
Section 3.4 references:
	
http://www.iana.org/assignments/xml-registry/schema/notification.xsd


And I guess we technically don't register this last one and it should be
added to the list. Reformatting this section was suggested but I'm not
sure whether we should make that change at this time.
</sharon>

10.

Also in IANA considerations, it might be clearer if the registration of
the capability urn refers to the named registry created by RFC4741
s.10.3; obvious to those up to their ears in netconf, perhaps less so to
those with an IANA-wide remit.

<sharon>
We can divide the list into two and indicate that those which are for
capabilities (notification, interleave) also align to the registry from
RFC4741 s.10.3.
</sharon>

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>