A Policy Control Mechanism in IS-IS Using Administrative Tags
RFC 5130

Note: This ballot was opened for revision 04 and is now closed.

(David Kessens) Discuss

Discuss (2007-02-08 for -)
In section '2. Sub-TLV Additions ':

 The methods for which their use is employed is beyond the scope of 
 this document and left to the implementer and/or operator. 

We are not required to have a complete operational description, but
I do believe that there should be a few example use cases that the
authors envision what this option can be/should be used for.

 An implementation MAY consider only one of the encoded tags, in which 
 case the first encoded tag MUST be considered. 

What is the motivation for this ? I don't see why the first tag is more 

important than the next one. I also wonder why the 'MAY' is useful in the
first place.

Note that section '3. Ordering of Tags' says:
          
 The semantics of the tag order are implementation-dependent.  That 
 is, there is no implied meaning to the ordering of the tags that 
 indicates a certain operation or set of operations need be performed 
 based on the order of the tags.

Why is the following not a 'MUST':

 However, an implementation MAY 
 wish to preserve tag ordering such that an ordered set of tags has 
 meaning to the local policy. 

This seems a recipe for problems for operators with multi-vendor networks 

and I don't see a reason why the spec allows for this flexibility without 

a real benefit.

I don't why a 'SHOULD' is used instead of a 'MUST':

 If an 
 implementation needs to change tag values, for example, at an area 
 boundary, then the TLV(s) SHOULD be copied to the newly generated 
 Level-1 or Level-2 LSP at which point, the contents of the SubTLV(s) 
 MAY change as dictated by the policy action.  In the event that no 
 change is required, the SubTLV(s) SHOULD be copied in order into the 
 new LSP, such that ordering is preserved. 

In section '5. Operations':

 There is no discussion on how compliant and non-compliant routers are  

supposed to interact.

Otherwise, this draft is well written and easy to understand.

(Ross Callon) (was No Objection) Yes

(Bill Fenner) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Brian Carpenter) No Objection

Comment (2007-02-02 for -)
No email
send info
I very nearly made this a DISCUSS...

1. The example in Fig 1 is not from the range of example addresses.

2.
 7. IANA Considerations 
         
 
    The authors have chosen "1" as the type code of the 32-bits 
    Administrative Tag Sub-TLV and "2" as the type code of the 64-bits 
    Administrative Tag Sub-TLV. These values must be allocated by IANA.

We normally talk about suggested values, not "must", and does this need
a new registry?

(Lars Eggert) (was Discuss) No Objection

Comment (2007-02-05)
No email
send info
  - Obsolete Reference: RFC 3667
  - Obsolete Reference: RFC 3668

Has a _ton_ of other idnits, please check with latest version of the tool.

(Ted Hardie) No Objection

(Sam Hartman) No Objection

Comment (2007-02-07 for -)
No email
send info
I think the semantics specified by this draft are incredibly thin
about how tags can be set from BGP extended communities, how tags can
be used, etc.  I think that there are not really sufficient semantics
for a reasonable assurance that two implementation make sufficiently
similar uses of tags that you can use them on the same network.  I
consider that a problem, but there's just enough there that I'm filing
a no-obj.

(Russ Housley) No Objection

(Chris Newman) No Objection

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) (was Discuss) No Objection

(David Ward) No Objection

Magnus Westerlund (was Discuss) No Objection

Comment (2007-02-02 for -)
No email
send info
The security consideration sections seems incredible thin. Aren't there risks with someone tapping this information from within the network. What effect would that have? I think that should be described.