Note: This ballot was opened for revision 05 and is now closed.
Summary: Needs a YES.
Discuss (2005-09-29) 
I worry about the extnedibility and how easy this can be done:
3. IANA Considerations
LLS TLV types are maintained by the IANA. Extensions to OSPF which
require a new LLS TLV type must be reviewed by an designated expert
from the routing area.
Have you assigned one or two of such experts?
Following the policies outlined in [IANA], LLS type values in the
range of 0-32767 are allocated through an IETF Consensus action and
We have seen in the past that "IETF Consensus Action" is vague and
not so easy (straight-forward) as for example stds action
LLS type values in the range of 32768-65536 are reserved for private
and experimental use.
Are thoese assigned at all by IANA?
And if so, is it FCFS?
And is any spec required?
This document assigns LLS types 1 and 2, as follows:
LLS Type Name Reference
0 Reserved
1 Extended Options [RFCNNNN]*
2 Cryptographic Authentication [RFCNNNN]*
3-32767 Reserved for assignment by the IANA
32768-65535 Private Use
earlier on you state that 32768-65536 are for Private use AND experimental use>
here in the table ujust "Private Use" ??
65535 Reserved
So 65535 is both "Private Use" and "Reserved" ??
*[RFCNNNN] refers to the RFC number-to-be for this document.
This document also assigns the following bits for the Extended
Options bits field in the EO-TLV outlined in Section 2.4.1:
Extended Options Bit Name Reference
0x00000001 LSDB Resynchronization (LR) [OOB]
0x00000002 Restart Signal (RS-bit) [RESTART]
Other Extended Options bits will be allocated through an IETF
consensus action.
Strange that youwrite that here while the actual assignment is in the
other documents. Oh well
Comment (2005-09-29)
doc: draft-nguyen-ospf-lls-05.txt
document states
sect 2.4.1 says:
The value of the type field in EO-TLV is TBD (temporarily used value
is 1).
sect. 2.4.2 says:
The value of the Type field for CA-TLV is TBD. Temporary used value
is 2.
While IANA considerations section already assigns value 2:
This document assigns LLS types 1 and 2, as follows:
LLS Type Name Reference
0 Reserved
1 Extended Options [RFCNNNN]*
2 Cryptographic Authentication [RFCNNNN]*
Reference/Citation issues:
!! Missing Reference for citation: [IANA]
P007 L029: Following the policies outlined in [IANA], LLS type values in
the
!! Missing citation for Normative reference:
P008 L034: [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
!! Missing Reference for citation: [RFC2328]
P002 L015: [RFC2328] packets are not very flexible to provide an acceptable
P002 L037: [RFC2328] packets are not very flexible to provide an acceptable
--------
draft-nguyen-ospf-oob-resync-05.txt
!! Missing Reference for citation: [RFC2328]
P002 L008: According to the OSPF standard [RFC2328], after two OSPF
routers have
$ idnits draft-nguyen-ospf-oob-resync-05.txt
idnits 1.77 (21 Aug 2005)
draft-nguyen-ospf-oob-resync-05.txt:
Checking nits according to http://www.ietf.org/ID-Checklist.html:
* The document seems to lack an Abstract section.
* The document seems to lack an IANA Considerations section.
-------
draft-nguyen-ospf-restart-05.txt
$ idnits draft-nguyen-ospf-restart-05.txt
idnits 1.77 (21 Aug 2005)
draft-nguyen-ospf-restart-05.txt:
Checking nits according to http://www.ietf.org/ID-Checklist.html:
* The document seems to lack an Abstract section.
* The document seems to lack an Introduction section.
* The document seems to lack an IANA Considerations section.
Comment (2005-09-29)
In draft-nguyen-ospf-restart-05:
s/2.3. Insuring topology stability/2.3. Ensuring topology stability/
datatracker.ietf.org