Subject: [ANCP] I-D Action: draft-ietf-ancp-mc-extensions-11.txt

From: [email-masked]
Date: Wed, 13 Nov 2013 19:34:33 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Access Node Control Protocol Working Group of the IETF.

	Title           : Multicast Control Extensions for ANCP
	Author(s)       : Francois Le Faucheur
                          Roberta Maglione
                          Tom Taylor
	Filename        : draft-ietf-ancp-mc-extensions-11.txt
	Pages           : 85
	Date            : 2013-11-13

Abstract:
   This document specifies the extensions to the Access Node Control
   Protocol required for support of the multicast use cases defined in
   the Access Node Control Protocol framework document and one
   additional use case described in this document.  These use cases are
   organized into the following ANCP capabilities:

   o  NAS-initiated multicast replication;

   o  conditional access with white and black lists;

   o  conditional access with grey lists;

   o  bandwidth delegation;

   o  committed bandwidth reporting.

   These capabilities may be combined according to the rules given in
   this specification.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ancp-mc-extensions

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ancp-mc-extensions-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ancp-mc-extensions-11

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

---

From: Tom Taylor <[email-masked]>
Date: Wed, 13 Nov 2013 22:50:27 -0500

This update was to fix a few nits. In the process, I noted that IEEE 
*tutorials* on 48-bit and 64-bit MAC addresses had been classified as 
Normative and moved them to the Informative section. This could be 
argued, since the formats themselves are mandatory to implement. I'll 
move them back or find appropriate normative references if people think 
I should.

I also deleted a speculative note on error return codes as proposed in 
what is now an old and abandoned MBONED draft (draft-morin-mboned-...), 
along with the reference.

The final significant change was to upgrade the copyright statement to 
the latest version.

Purely editorial changes were to fix long lines in Figure 21 and change 
the multicast group addresses in the examples in the appendix to use 
example subnet 233.252.0.0/24.

FYI there was one totally spurious nit complaining about possible 
non-documentation IPv4 address 3.4.2.3. The previous text read:
  "... Sections 3.4.1 and 3.4.2.3 ...". It appears IDnits recognizes the 
Section keyword, because when I changed the text to: "... Section 3.4.1 
and Section 3.4.2.3 ..." the warning went away.

Tom Taylor

> 	Author(s)       : Francois Le Faucheur
...

---

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Mon, 18 Nov 2013 17:26:46 +0000

WG,

There are a couple of issues that we have picked up with this draft, and
the registries that were created on request of RFC6320, is as follows.

The draft assigns a code point 3 in the ANCP Capability Type Registry for
NAS-Initiated Replication. However, that value is currently reserved,
rather than unassigned.

The definition of “reserved" in RFC5226 is as follows:

"Reserved:  Not to be assigned.  Reserved values are held for
            special uses, such as to extend the namespace when it become
            exhausted.  Reserved values are not available for general
            assignment.²

This was set as reserved by RFC6320. I assume it was reserved for the
multicast draft, but this seems to clash with the definition of reserved
above.

Secondly, the draft requests some allocations from the ANCP result codes
registry. The IANA web page states that future allocation from the the
IETF consensus range should start from 0x100. However, the draft requests
allocations starting form 0x64. I believe that this is a result of a
decimal/hex typo. This should be corrected, and also the FCFS range
starting at 0x1000 (which I suspect should mean 1000).

It is probably easier to resolve this by making the multicast draft update
RFC6320 in terms of the rules associated with the relevant IANA registries.

Here is how I suggest we do it:
- Add a sentence to the IANA section requesting that they change the
allocation policy for the IETF Review section of the results codes
registry so that it is sequential starting at 0x64.
- Add a note to the abstract and the introduction explaining this.
- Add an Updates: 6320 statement to the draft header.
- While we area about it, please  also check that the ‘Specification
required’ range really starts at 0x1000 rather than 1000.

Regards

Matthew