Skip to main content

IS-IS Application-Specific Link Attributes
draft-ietf-isis-te-app-19

Revision differences

Document history

Date Rev. By Action
2022-05-14
19 (System) Received changes through RFC Editor sync (removed Errata tag (all errata rejected))
2021-07-06
19 (System) Received changes through RFC Editor sync (added Errata tag)
2020-10-23
19 (System) IANA registries were updated to include RFC8919
2020-10-22
19 (System)
Received changes through RFC Editor sync (created alias RFC 8919, changed abstract to 'Existing traffic-engineering-related link attribute advertisements have been defined and are used …
Received changes through RFC Editor sync (created alias RFC 8919, changed abstract to 'Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments.  Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined.  In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application-specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link.  This document introduces new link attribute advertisements that address both of these shortcomings.', changed pages to 20, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2020-10-22, changed IESG state to RFC Published)
2020-10-22
19 (System) RFC published
2020-10-15
19 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc8919">AUTH48-DONE</a> from AUTH48
2020-09-23
19 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc8919">AUTH48</a> from RFC-EDITOR
2020-09-02
19 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-07-08
19 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2020-07-08
19 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2020-07-08
19 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-07-07
19 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-07-02
19 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2020-07-02
19 Tero Kivinen Assignment of request for Last Call review by SECDIR to Alan DeKok was marked no-response
2020-07-01
19 (System) RFC Editor state changed to EDIT
2020-07-01
19 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-07-01
19 (System) Announcement was received by RFC Editor
2020-07-01
19 (System) IANA Action state changed to In Progress
2020-07-01
19 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-07-01
19 Cindy Morgan IESG has approved the document
2020-07-01
19 Cindy Morgan Closed "Approve" ballot
2020-07-01
19 Cindy Morgan Ballot approval text was generated
2020-07-01
19 Alvaro Retana IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2020-06-29
19 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-06-29
19 Les Ginsberg New version available: draft-ietf-isis-te-app-19.txt
2020-06-29
19 (System) New version approved
2020-06-29
19 (System)
Request for posting confirmation emailed to previous authors: Stefano Previdi <stefano@previdi.net>, John Drake <jdrake@juniper.net>, Les Ginsberg <ginsberg@cisco.com>, Peter Psenak …
Request for posting confirmation emailed to previous authors: Stefano Previdi <stefano@previdi.net>, John Drake <jdrake@juniper.net>, Les Ginsberg <ginsberg@cisco.com>, Peter Psenak <ppsenak@cisco.com>, Wim Henderickx <wim.henderickx@nokia.com>
2020-06-29
19 Les Ginsberg Uploaded new revision
2020-06-23
18 Alvaro Retana IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation::AD Followup
2020-06-22
18 Les Ginsberg New version available: draft-ietf-isis-te-app-18.txt
2020-06-22
18 (System) New version approved
2020-06-22
18 (System)
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak …
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak <ppsenak@cisco.com>, Les Ginsberg <ginsberg@cisco.com>
2020-06-22
18 Les Ginsberg Uploaded new revision
2020-06-18
17 Deborah Brungard
[Ballot comment]
Thanks for resolving my discuss on aligning SR terms with SPRING's work.

I remain unconvinced on backward compatibility with RSVP-TE, hence my abstain …
[Ballot comment]
Thanks for resolving my discuss on aligning SR terms with SPRING's work.

I remain unconvinced on backward compatibility with RSVP-TE, hence my abstain ballot. Similar to other operators, I have serious concerns with operational aspects and the unfair burden placed on operators. A simple on/off control would have provided a much more elegant solution.

From the discussion, this is obviously a multi-vendor agreement on their preferred way, so while I disagree, I will not stand in the way.
2020-06-18
17 Deborah Brungard [Ballot Position Update] Position for Deborah Brungard has been changed to Abstain from Discuss
2020-06-17
17 Les Ginsberg New version available: draft-ietf-isis-te-app-17.txt
2020-06-17
17 (System) New version approved
2020-06-17
17 (System)
Request for posting confirmation emailed to previous authors: Peter Psenak <ppsenak@cisco.com>, Les Ginsberg <ginsberg@cisco.com>, John Drake <jdrake@juniper.net>, Stefano Previdi …
Request for posting confirmation emailed to previous authors: Peter Psenak <ppsenak@cisco.com>, Les Ginsberg <ginsberg@cisco.com>, John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>
2020-06-17
17 Les Ginsberg Uploaded new revision
2020-06-15
16 Les Ginsberg New version available: draft-ietf-isis-te-app-16.txt
2020-06-15
16 (System) New version approved
2020-06-15
16 (System)
Request for posting confirmation emailed to previous authors: Les Ginsberg <ginsberg@cisco.com>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, John Drake …
Request for posting confirmation emailed to previous authors: Les Ginsberg <ginsberg@cisco.com>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, John Drake <jdrake@juniper.net>, Peter Psenak <ppsenak@cisco.com>
2020-06-15
16 Les Ginsberg Uploaded new revision
2020-06-11
15 Murray Kucherawy
[Ballot comment]
EDIT: Thanks for setting me straight on my DISCUSS point.

--

Since this document is in many parts a copy of draft-ietf-ospf-te-link-attr-reuse, …
[Ballot comment]
EDIT: Thanks for setting me straight on my DISCUSS point.

--

Since this document is in many parts a copy of draft-ietf-ospf-te-link-attr-reuse, I'm only reviewing this delta between them here:
https://www.ietf.org/rfcdiff?url1=draft-ietf-ospf-te-link-attr-reuse-14&url2=draft-ietf-isis-te-app-14

Section 2:
* "... expected to continue - so any discussion ..." -- change to "... expected to continue.  Therefore, any discussion ..."
* "... key points identified in the introduction - which are:" -- change hyphen to a comma

Section 3:
* "... advertisements include sub-TLVs for TLVs ..." -- Please define or expand "TLV" on first use.
* Please just name the registries, rather than giving multi-line URLs to them.

Section 3.1:
* As with the matching OSPF document, I don't see the benefit of citing current registry contents rather than just referencing the registry.

Section 4.3:
* Interestingly, the entries for IPv4 are not capitalized (e.g., "interface address"), but they are for IPv6 (e.g., "Interface Address").

Section 6.3.2:
* These two paragraphs read like they're in the wrong order.

Sections 7.1 and 7.2:
* These should refer back to Sections 4.2 and 4.3, respectively, where the new values are fully described.
2020-06-11
15 Murray Kucherawy [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from Discuss
2020-06-11
15 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2020-06-11
15 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-06-11
15 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-06-11
15 Les Ginsberg New version available: draft-ietf-isis-te-app-15.txt
2020-06-11
15 (System) New version approved
2020-06-11
15 (System)
Request for posting confirmation emailed to previous authors: Peter Psenak <ppsenak@cisco.com>, Les Ginsberg <ginsberg@cisco.com>, Wim Henderickx <wim.henderickx@nokia.com>, John Drake …
Request for posting confirmation emailed to previous authors: Peter Psenak <ppsenak@cisco.com>, Les Ginsberg <ginsberg@cisco.com>, Wim Henderickx <wim.henderickx@nokia.com>, John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>
2020-06-11
15 Les Ginsberg Uploaded new revision
2020-06-11
14 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2020-06-11
14 Magnus Westerlund [Ballot comment]
Have to side with Warren that this document is hard to follow.
2020-06-11
14 Magnus Westerlund [Ballot Position Update] New position, Abstain, has been recorded for Magnus Westerlund
2020-06-11
14 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-06-11
14 Benjamin Kaduk
[Ballot discuss]
My apologies if this is super-obvious and I'm just missing it ... but
Section 4.3 dictates that part of the value for the …
[Ballot discuss]
My apologies if this is super-obvious and I'm just missing it ... but
Section 4.3 dictates that part of the value for the application-specific
SRLG TLV is a "Neighbor System-ID + pseudo-node ID (7 octets)".  Where
are these defined?  (We don't exactly say that we're reusing the structure
from, e.g., TLV 138, which I note refers to the seventh octet as
"pseudonode number", not "pseudo-node ID".  Similarly for the
interpretation of the SRLG value(s).  Do we just need to reference that
we're reusing the encoding from RFC 5307 (or similar) or are some
changes needed?
2020-06-11
14 Benjamin Kaduk
[Ballot comment]
What is the scope over which the user-defined application bits are
defined/allocated?

And, a general question, just to check my understanding: if I …
[Ballot comment]
What is the scope over which the user-defined application bits are
defined/allocated?

And, a general question, just to check my understanding: if I do need to
specify different values of a given attribute for different
applications, I do that by putting multiple copies of the new sub-TLV in
TLV 22/23/etc., with the flags set according to which application the
contained attributes apply to?  (Mostly I ask because I forget what the
rules are for having multiple instances of a given TLV/sub-TLV as
siblings in the same container.)

Section 3.1

Maybe mention (again, I know) that this is only the subset of sub-TLVs
that are used for RSVP-TE?

Section 4.2

  When the L-flag is set in the Application Identifier Bit Mask, all of
  the applications specified in the bit mask MUST use the legacy
  advertisements for the corresponding link found in TLVs 22, 23, 25,
  141, 222, and 223 or TLV 138 or TLV 139 as appropriate.  Link

nit(?): is this "found in sub-TLVs of TLVs 22, [...]"?

  attribute sub-sub-TLVs for the corresponding link attributes MUST NOT
  be advertised for the set of applications specified in the Standard/
  User Application Identifier Bit Masks and all such advertisements
  MUST be ignored on receipt.

Does this apply to just the (sub-)TLV with the L-flag set, or to other
instances of that (sub-)TLV as well?

  For a given application, the setting of the L-flag MUST be the same
  in all sub-TLVs for a given link.  In cases where this constraint is
  violated, the L-flag MUST be considered set for this application.

editorial: I suggest "the L-flag MUST be considered set for this
application for all sub-TLVs on the link in question".

  If link attributes are advertised associated with zero length
  Application Identifier Bit Masks for both standard applications and
  user defined applications, then any Standard Application and/or any

Do we need to talk about conflicts if there are multiple such sub-TLVs
for the link in question (that contain different values in the
sub-sub-TLV(s))?

  User Defined Application is permitted to use that set of link
  attributes so long as there is not another set of attributes
  advertised on that same link which is associated with a non-zero
  length Application Identifier Bit Mask with a matching Application
  Identifier Bit set.

nit: this phrasing of "matching Application Identifier Bit set" does not
seem as clear as it could be that the bit for the application in
question is what's checked (though I have a hard time believing that
someone would accidentally misinterpret the meaning).

  the link attribute sub-sub-TLV code points.  This document defines a
  sub-sub-TLV for each of the existing sub-TLVs listed in Section 3.1
  except as noted below.  The format of the sub-sub-TLVs matches the

Just to check that I'm matching things up properly: this leaves the only
attributes that do not have some form of exception noted as
administrative group, extended administrative group, and TE default
metric?

Section 4.2.1

  Maximum link bandwidth is an application independent attribute of the
  link.  When advertised using the Application Specific Link Attributes
  sub-TLV, multiple values for the same link MUST NOT be advertised.
  This can be accomplished most efficiently by having a single
  advertisement for a given link where the Application Identifier Bit
  Mask identifies all the applications which are making use of the
  value for that link.

If I want the same maximum link bandwidth to apply to all applications,
couldn't I just put it in a sub-TLV with both SABM and UDABM length of
zero?  (Is this somehow less efficient than setting all the bits for the
applications making use of the value?)  Section 4.2.3 seems to discuss
using the zero-length bit mask option in the context of TE metrics...
(I do note the note at the end of Section 5 about the "any application"
encoding leaving ambiguous whether an application is enabled, but I
don't see how this consideration differs between maximum link bandwidth
and extended TE metrics.)

Section 4.2.2

  Maximum Reservable Link Bandwidth and Unreserved Bandwidth are
  attributes specific to RSVP-TE.  When advertised using the
  Application Specific Link Attributes sub-TLV, bits other than the
  RSVP-TE (R-bit) MUST NOT be set in the Application Identifier Bit

Just to confirm: we find the risk of some future application that also
wants to do reservation-like things sufficiently low that we're okay
with preventing it from using these attributes?

Section 4.3

What are the semantics when I specify more than one link identifier
sub-TLV?  They are all supposed to identify the same link, and in some
case might be needed to disambiguate if there are (e.g.) multiple links
to the same neighbor?

Section 5

  In the case of SRTE, advertisement of application specific link
  attributes does not indicate enablement of SRTE on that link.  The

Is the SRTE specification sufficiently final that we're comfortable
enshrining in a (different) RFC this property of it?  I note that we
only list draft-ietf-spring-segment-routing-policy as an informative
reference, so it's entirely possible that this document will be
published as an RFC before that document is done.

Section 6.1

  the writing of this document.  Therefore, such applications have been
  deployed using the legacy advertisements.  The Standard Applications
  defined in this document may continue to use legacy advertisements
  for a given link so long as at least one of the following conditions
  is true:

nit(?): do we want to say something like "may safely continue" or "may
continue to use without ill effect"?

Section 6.3.2

  advertisements as defined in this document.  Attributes for
  applications other than RSVP-TE MUST be advertised using application
  specific advertisements which have the L-flag clear.  In cases where
  some link attributes are shared with RSVP-TE, this requires duplicate
  advertisements for those attributes.

Maybe repeat that this duplication is required because the L flag
applies per-application per-link, for all attributes?

Section 6.3.4

  2)Advertise all legacy link attributes using application specific
  advertisements with L-flag clear and R-bit set.

nit: I suggest clarifying that this involves duplicate advertisements
(legacy plus application-specific).  Or at least, I assume it does,
since step (3) is "remove legacy advertisements".

Section 7.3

  Note to IANA: For future codepoints, in cases where the document
  which defines the encoding is different from the document which
  assigns the codepoint, the encoding reference MUST be to the document
  which defines the encoding.

Why not list both as the reference?

  Note to designated experts: If a link attribute can be advertised
  both as a sub-TLV of TLVs 22, 23, 25, 141, 222, and 223 and as a sub-
  sub-TLV of the Application Specific Link Attributes sub-TLV defined
  in this document, then the same numerical code should be assigned to
  the link attribute whenever possible.

Are these notes intended to end up in the final RFC, attached to the
registry, both places, or neither place?

Section 7.4

  policy for this registry is "Standards Action" [RFC8126].  Bit
  definitions SHOULD be assigned in ascending bit order beginning with
  Bit 0 so as to minimize the number of octets that will need to be
  transmitted.  The following assignments are made by this document:

I worry a little bit that this will encourage codepoint squatting,
though in theory the user-defined bitmask should avoid the need for
squatting.

Section 7.5

  Note to IANA: For future codepoints, in cases where the document
  which defines the encoding is different from the document which
  assigns the codepoint, the encoding reference MUST be to the document
  which defines the encoding.

(As above, why not list both?)
2020-06-11
14 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2020-06-10
14 Deborah Brungard
[Ballot discuss]
This should be simple to resolve - the use of the SR-TE term is out-of-alignment with other drafts, spring and idr. Suggest: Segment …
[Ballot discuss]
This should be simple to resolve - the use of the SR-TE term is out-of-alignment with other drafts, spring and idr. Suggest: Segment Routing Traffic Engineering/s/Segment Routing Policy and SRTE/s/SR Policy.
2020-06-10
14 Deborah Brungard
[Ballot comment]
I found this document a bit easier to read than the OSPF one. Though it also seems (implementation) confused on 1:1 association of …
[Ballot comment]
I found this document a bit easier to read than the OSPF one. Though it also seems (implementation) confused on 1:1 association of signaling over a link with data use of the link and so the confusion on what application to support on the link. As I noted on the OSPF one, it would be much clearer to simply discuss the main problem (to me) - the ability to support advertisement of application specific values?

I don't see any discussion on the dark bandwidth problem or the security problems identified in RFC8426? It would be helpful if the draft pointed to the RFC8426 solution.
2020-06-10
14 Deborah Brungard [Ballot Position Update] New position, Discuss, has been recorded for Deborah Brungard
2020-06-10
14 Roman Danyliw
[Ballot comment]
(revised)
** Section 4.1.  As I understand it, the SABM can be of 0 – 8 octets in length. The SABM Length field …
[Ballot comment]
(revised)
** Section 4.1.  As I understand it, the SABM can be of 0 – 8 octets in length. The SABM Length field represents that length and has 7 bits to do that.  However, the maximum number of bits needed to represent 8 is only 4 bits.  What’s the thinking on those three extra bits?  Should they be marked as reserved?  I would have the same question for the UDABM mask.

** Section 6.2.  I didn’t follow what it means to send the sub-TLV in Section 4.2 with a zero length SABM Length and UDABM Length – that is two empty bitmasks?  Is that permitted?  What would it convey?

** Section 8.  Per “Tampering with the information defined in this document may have an effect on applications using it, including impacting Traffic Engineering.”, I have no disagreement with this statement.  However, I would recommend adding a brief statement what is the security impact of “impacting Traffic Engineering”.

** Section 8.  Per “This is similar in nature to the impacts associated  with (for example) [RFC5305]”, what specific text in RFC5305 was envisioned?  The SecCon section (Section 6) of RFC5305 contains only one sentence that points to RFC5304?

** Section 8.  Consider using the editorial framing of the first paragraph of Section 13 in draft-ietf-ospf-te-link-attr-reuse to introduce how the RFC5304 applies here.

** Editorial
-- Section 3.  Editorial.  Consider providing a reference for the registries instead of an inline URL.

-- Section 4.1.  The rendering of the sub-TLV diagram was split between Page 6 and 7 when this draft is read in TXT format.  IMO, it would be more readable if it was on one page.

-- Per Section 4.1.  Editorial.  Per “See the following section for a description …”, please explicitly name the section.

-- Section 4.2.  Typo. s/Identifer/Identifier/
2020-06-10
14 Roman Danyliw Ballot comment text updated for Roman Danyliw
2020-06-10
14 Roman Danyliw
[Ballot comment]
** Section 4.1.  As I understand it, the SABM can be of 0 – 8 octets in length. The SABM Length field represents …
[Ballot comment]
** Section 4.1.  As I understand it, the SABM can be of 0 – 8 octets in length. The SABM Length field represents that length and has 7 bits to do that.  However, the maximum number of bits needed to represent 8 is only 4 bits.  What’s the thinking on those three extra bits?  Should they be marked as reserved?  I would have the same question for the UDABM mask.

** Section 6.2.  I didn’t follow what it means to send the sub-TLV in Section 4.2 with a zero length SABM Length and UDABM Length – that is two empty bitmasks?  Is that permitted?  What would it convey?

** Section 8.  Per “Tampering with the information defined in this document may have an effect on applications using it, including impacting Traffic Engineering.”, I have no disagreement with this statement.  However, I would recommend adding a brief statement what is the security impact of “impacting Traffic Engineering”.

** Section 8.  Per “This is similar in nature to the impacts associated  with (for example) [RFC5305]”, what specific text in RFC5305 was envisioned?  The SecCon section (Section 6) of RFC5305 contains only one sentence that points to RFC5304?

** Editorial
-- Section 3.  Editorial.  Consider providing a reference for the registries instead of an inline URL.

-- Section 4.1.  The rendering of the sub-TLV diagram was split between Page 6 and 7 when this draft is read in TXT format.  IMO, it would be more readable if it was on one page.

-- Per Section 4.1.  Editorial.  Per “See the following section for a description …”, please explicitly name the section.

-- Section 4.2.  Typo. s/Identifer/Identifier/
2020-06-10
14 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-06-10
14 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2020-06-10
14 Robert Wilton
[Ballot comment]
I'm not sure whether this should really be a discuss ... I raised a similar concern on the OSPF document as part of …
[Ballot comment]
I'm not sure whether this should really be a discuss ... I raised a similar concern on the OSPF document as part of a discuss, and presume consistency is helpful.

4.1.  Application Identifier Bit Mask

  UDABM Length: Indicates the length in octets (0-8) of the
      User Defined Application Identifier Bit Mask. The length SHOULD
      be the minimum required to send all bits which are set.

  User Defined Application Identifier Bits have no relationship to
  Standard Application Identifier Bits and are not managed by IANA or
  any other standards body.  It is recommended that bits are used
  starting with Bit 0 so as to minimize the number of octets required
  to advertise all UDAs.

In section 4.1, I think that the document should also add the sentence (taken from the previous paragraph) "Bits that are not transmitted MUST be treated as if they are set to 0 on receipt."  Note, that I also think that this behaviour is implicitly required from the description of UDABM Length.

Regards,
Rob
2020-06-10
14 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-06-09
14 Warren Kumari
[Ballot comment]
I am balloting NoObj in the "I read the protocol action, and I trust the sponsoring AD so have no problem." sense, but …
[Ballot comment]
I am balloting NoObj in the "I read the protocol action, and I trust the sponsoring AD so have no problem." sense, but I do have some concerns.

I found the document to be really hard to read, enough so that I largely gave up - this might just be that I'm overcommitted/grumpy this week, but the lack of punctuation in sentences like: "In cases where multiple applications wish to make use of these link  attributes the current advertisements do not support application specific values for a given attribute nor do they support indication  of which applications are using the advertised value for a given link." certainly don't help...

I was largely unable to follow Section 4.1.  Application Identifier Bit Mask, but as others / the responsible AD seem to get it, I'm just going to assume that my wife secretly swapped out my coffee for decaf this week, or that I'm just being dumb.
As an example, I am unable to sensibly parse: "Standard Application Identifier Bits are defined/sent starting with Bit 0.  ... Bits that are not transmitted MUST be treated as if they are set to 0 on receipt.", especially the "Bits that are not transmitted" part.
2020-06-09
14 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2020-06-08
14 Barry Leiba [Ballot comment]
My co-AD has this covered.
2020-06-08
14 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-06-08
14 Martin Duke
[Ballot comment]
I know very little about this, but just checking:
- I trust that a network that mixes routers that use application attributes, and …
[Ballot comment]
I know very little about this, but just checking:
- I trust that a network that mixes routers that use application attributes, and not, will not lead to long-term routing loops in spite of them not having a common picture of the network?

- It is odd that a link that advertises a zero-length flags field means support for RSVP-TE is “ambiguous” (sec 5). What are the implications of this? When is it OK to use a zero-length flags field given this ambiguity? In a standard, can we not decide on a meaning to eliminate the uncertainty? I would appreciate some language here to answer at least the first two questions.

- as the TSVart review points out, the length field wastes 3 bits of 7 because the maximum length is 8. You could reserve them or even use them to encode these three legacy applications.

Nits:

Abstract:
In “these link attributes for a given attribute” add a comma after both instances of attribute(s)

Sec 4 2)Application. Add a space

Sec 5. Missing a period at the end of “existence of link attribute advertisements”
2020-06-08
14 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2020-06-08
14 Murray Kucherawy
[Ballot discuss]
An easy one:

Sections 7.3 and 7.5 create new IANA registries with "Expert Review" rules, but Section 7.5 provides no particular guidance to …
[Ballot discuss]
An easy one:

Sections 7.3 and 7.5 create new IANA registries with "Expert Review" rules, but Section 7.5 provides no particular guidance to the Designated Expert about how to review applications, as required by Section 4.5 of BCP 26.
2020-06-08
14 Murray Kucherawy
[Ballot comment]
Since this document is in many parts a copy of draft-ietf-ospf-te-link-attr-reuse, I'm only reviewing this delta between them here:
https://www.ietf.org/rfcdiff?url1=draft-ietf-ospf-te-link-attr-reuse-14&url2=draft-ietf-isis-te-app-14

Section 2: …
[Ballot comment]
Since this document is in many parts a copy of draft-ietf-ospf-te-link-attr-reuse, I'm only reviewing this delta between them here:
https://www.ietf.org/rfcdiff?url1=draft-ietf-ospf-te-link-attr-reuse-14&url2=draft-ietf-isis-te-app-14

Section 2:
* "... expected to continue - so any discussion ..." -- change to "... expected to continue.  Therefore, any discussion ..."
* "... key points identified in the introduction - which are:" -- change hyphen to a comma

Section 3:
* "... advertisements include sub-TLVs for TLVs ..." -- Please define or expand "TLV" on first use.
* Please just name the registries, rather than giving multi-line URLs to them.

Section 3.1:
* As with the matching OSPF document, I don't see the benefit of citing current registry contents rather than just referencing the registry.

Section 4.3:
* Interestingly, the entries for IPv4 are not capitalized (e.g., "interface address"), but they are for IPv6 (e.g., "Interface Address").

Section 6.3.2:
* These two paragraphs read like they're in the wrong order.

Sections 7.1 and 7.2:
* These should refer back to Sections 4.2 and 4.3, respectively, where the new values are fully described.
2020-06-08
14 Murray Kucherawy [Ballot Position Update] New position, Discuss, has been recorded for Murray Kucherawy
2020-06-08
14 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. I have only one nits in section 4.3: while I appreciate IPv6, there is …
[Ballot comment]
Thank you for the work put into this document. I have only one nits in section 4.3: while I appreciate IPv6, there is no need to capitalize 'IPv6 Interface Address' as "IPv4 interface address" is not capitalized ;-)

Special thanks to Acee, as the document shepherd he managed to represent the conflicts within the WG.

I hope that this helps to improve the document,

Regards,

-éric
2020-06-08
14 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-06-05
14 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2020-06-04
14 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-06-04
14 Les Ginsberg New version available: draft-ietf-isis-te-app-14.txt
2020-06-04
14 (System) New version approved
2020-06-04
14 (System)
Request for posting confirmation emailed to previous authors: Stefano Previdi <stefano@previdi.net>, Peter Psenak <ppsenak@cisco.com>, John Drake <jdrake@juniper.net>, Wim Henderickx …
Request for posting confirmation emailed to previous authors: Stefano Previdi <stefano@previdi.net>, Peter Psenak <ppsenak@cisco.com>, John Drake <jdrake@juniper.net>, Wim Henderickx <wim.henderickx@nokia.com>, Les Ginsberg <ginsberg@cisco.com>
2020-06-04
14 Les Ginsberg Uploaded new revision
2020-06-04
13 Cindy Morgan Placed on agenda for telechat - 2020-06-11
2020-06-04
13 Alvaro Retana IESG state changed to IESG Evaluation from Waiting for Writeup
2020-06-04
13 Alvaro Retana Ballot has been issued
2020-06-04
13 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2020-06-04
13 Alvaro Retana Created "Approve" ballot
2020-06-04
13 Alvaro Retana Ballot writeup was changed
2020-05-29
13 Bruno Decraene Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Bruno Decraene. Sent review to list.
2020-05-29
13 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2020-05-29
13 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-isis-te-app-12. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-isis-te-app-12. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are five actions which we must complete.

First, in the Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS reachability, IS Neighbor Attribute, L2 Bundle Member Attributes, inter-AS reachability information, MT-ISN, and MT IS Neighbor Attribute TLVs) on the IS-IS TLV Codepoints registry page located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

the following temporary registration will have its reference changed to [ RFC-to-be ]:

Type: 16
Description: Application Specific Link Attributes
22: Y
23: Y
25: Y(s)
141: Y
222: Y
223: Y
Reference: [ RFC-to-be ]

Second, in the TLV Codepoints registry also on the IS-IS TLV Codepoints registry page located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

the following temporary registration will have its reference changed to [ RFC-to-be ]:

Value: 238
Name: Application Specific SRLG
IIH: N
LSP: Y
SNP: N
Purge: N
Reference: [ TBD-at-Registration ]

Third, a new registry is to be created called the sub-sub-TLV code points for application specific link attributes registry. The new registry will be located on the IS-IS TLV Codepoints registry page located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

Registration in the new registry will be managed via Expert Review as defined in RFC 8126. There are initial registrations in the new registry as follows:

Type Description Encoding
Reference
---------------------------------------------------------
0-2 Unassigned
3 Administrative group (color) RFC5305
4-8 Unassigned
9 Maximum link bandwidth RFC5305
10 Maximum reservable link bandwidth RFC5305
11 Unreserved bandwidth RFC5305
12-13 Unassigned
14 Extended Administrative Group RFC7308
15-17 Unassigned
18 TE Default Metric RFC5305
19-32 Unassigned
33 Unidirectional Link Delay RFC8570
34 Min/Max Unidirectional Link Delay RFC8570
35 Unidirectional Delay Variation RFC8570
36 Unidirectional Link Loss RFC8570
37 Unidirectional Residual Bandwidth RFC8570
38 Unidirectional Available Bandwidth RFC8570
39 Unidirectional Utilized Bandwidth RFC8570
40-255 Unassigned

A note will be added to the new registry as follows: In cases where the document which defines the encoding is different from the document which assigns the codepoint, the encoding reference MUST be to the document which defines the encoding.

Fourth, a new registry will be created called the Link Attribute Applications registry. The new registry will be created on the Interior Gateway Protocol (IGP) Parameters registry page located at:

https://www.iana.org/assignments/igp-parameters/

The new registry will be managed via Standards Action as defined in RFC 8126. There are initial registrations in the new registry as follows:

Bit # Name Reference
------------------------------------------------------------------
0 RSVP-TE (R-bit) [ RFC-to-be ]
1 Segment Routing Traffic Engineering (S-bit) [ RFC-to-be ]
2 Loop Free Alternate (F-bit) [ RFC-to-be ]
3-63 Unassigned

Fifth, a new registry is to be created called the Sub-TLVs for TLV 238 registry. This registry is to be a subregistry of the IS-IS TLV Codepoints Registry located at:

https://www.iana.org/assignments/isis-tlv-codepoints/

The new registry is to be managed via Expert Review as defined in RFC 8126. There are initial registrations in the new registry as follows:

Value Description Encoding
Reference
---------------------------------------------------------
0-3 Unassigned
4 Link Local/Remote Identifiers [RFC5307]
5 Unassigned
6 IPv4 interface address [RFC5305]
7 Unassigned
8 IPv4 neighbor address [RFC5305]
9-11 Unassigned
12 IPv6 Interface Address [RFC6119]
13 IPv6 Neighbor Address [RFC6119]
14-255 Unassigned

A note will be added to the new registry as follows: In cases where the document which defines the encoding is different from the document which assigns the codepoint, the encoding reference MUST be to the document which defines the encoding.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2020-05-29
13 Jouni Korhonen Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Jouni Korhonen. Sent review to list.
2020-05-29
13 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-05-26
13 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Niclas Comstedt
2020-05-26
13 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Niclas Comstedt
2020-05-26
13 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': review request received twice
2020-05-21
13 Tero Kivinen Request for Last Call review by SECDIR is assigned to Alan DeKok
2020-05-21
13 Tero Kivinen Request for Last Call review by SECDIR is assigned to Alan DeKok
2020-05-20
13 Kyle Rose Request for Last Call review by TSVART Completed: Ready with Nits. Reviewer: Kyle Rose. Sent review to list.
2020-05-20
13 Tim Chown Assignment of request for Last Call review by OPSDIR to Tim Chown was rejected
2020-05-19
13 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Chown
2020-05-19
13 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Chown
2020-05-18
13 Min Ye Request for Last Call review by RTGDIR is assigned to Bruno Decraene
2020-05-18
13 Min Ye Request for Last Call review by RTGDIR is assigned to Bruno Decraene
2020-05-18
13 Les Ginsberg New version available: draft-ietf-isis-te-app-13.txt
2020-05-18
13 (System) New version approved
2020-05-18
13 (System)
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Wim Henderickx <wim.henderickx@nokia.com>, Stefano Previdi <stefano@previdi.net>, Peter Psenak …
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Wim Henderickx <wim.henderickx@nokia.com>, Stefano Previdi <stefano@previdi.net>, Peter Psenak <ppsenak@cisco.com>, Les Ginsberg <ginsberg@cisco.com>
2020-05-18
13 Les Ginsberg Uploaded new revision
2020-05-18
12 Wesley Eddy Request for Last Call review by TSVART is assigned to Kyle Rose
2020-05-18
12 Wesley Eddy Request for Last Call review by TSVART is assigned to Kyle Rose
2020-05-14
12 Jean Mahoney Request for Last Call review by GENART is assigned to Jouni Korhonen
2020-05-14
12 Jean Mahoney Request for Last Call review by GENART is assigned to Jouni Korhonen
2020-05-14
12 Alvaro Retana Requested Last Call review by RTGDIR
2020-05-14
12 Cindy Morgan IANA Review state changed to IANA - Review Needed
2020-05-14
12 Cindy Morgan
The following Last Call announcement was sent out (ends 2020-05-29):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: aretana.ietf@gmail.com, Acee Lindem …
The following Last Call announcement was sent out (ends 2020-05-29):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: aretana.ietf@gmail.com, Acee Lindem <acee@cisco.com>, acee@cisco.com, draft-ietf-isis-te-app@ietf.org, lsr-chairs@ietf.org, lsr@ietf.org
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-isis-te-app-12.txt> (IS-IS TE Attributes per application) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'IS-IS TE Attributes per application'
  <draft-ietf-isis-te-app-12.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-05-29. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Existing traffic engineering related link attribute advertisements
  have been defined and are used in RSVP-TE deployments.  Since the
  original RSVP-TE use case was defined, additional applications (e.g.,
  Segment Routing Traffic Engineering, Loop Free Alternate) have been
  defined which also make use of the link attribute advertisements.  In
  cases where multiple applications wish to make use of these link
  attributes the current advertisements do not support application
  specific values for a given attribute nor do they support indication
  of which applications are using the advertised value for a given
  link.  This document introduces new link attribute advertisements
  which address both of these shortcomings.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/



No IPR declarations have been submitted directly on this I-D.




2020-05-14
12 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2020-05-14
12 Alvaro Retana Last call was requested
2020-05-14
12 Alvaro Retana Ballot approval text was generated
2020-05-14
12 Alvaro Retana Ballot writeup was generated
2020-05-14
12 Alvaro Retana IESG state changed to Last Call Requested from AD Evaluation::External Party
2020-05-14
12 Alvaro Retana Last call announcement was changed
2020-05-14
12 Alvaro Retana Last call announcement was generated
2020-04-25
12 Alvaro Retana Moving the sub-state to "External Party" which is closer to: waiting for the authors to update the OSPF document.
2020-04-25
12 Alvaro Retana IESG state changed to AD Evaluation::External Party from AD Evaluation::AD Followup
2020-04-24
12 Cindy Morgan IESG state changed to AD Evaluation::AD Followup from AD Evaluation::Point Raised - writeup needed
2020-04-02
12 Alvaro Retana
The authors have addressed all my comments for this document.  I am now waiting for draft-ietf-ospf-te-link-attr-reuse to catch up so we can progress both of …
The authors have addressed all my comments for this document.  I am now waiting for draft-ietf-ospf-te-link-attr-reuse to catch up so we can progress both of them together through IETF LC and beyond.
2020-04-02
12 Alvaro Retana IESG state changed to AD Evaluation::Point Raised - writeup needed from AD Evaluation::AD Followup
2020-03-21
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-03-21
12 Les Ginsberg New version available: draft-ietf-isis-te-app-12.txt
2020-03-21
12 (System) New version approved
2020-03-21
12 (System)
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak …
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak <ppsenak@cisco.com>, Les Ginsberg <ginsberg@cisco.com>
2020-03-21
12 Les Ginsberg Uploaded new revision
2020-03-06
11 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2020-02-27
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-02-27
11 Les Ginsberg New version available: draft-ietf-isis-te-app-11.txt
2020-02-27
11 (System) New version approved
2020-02-27
11 (System)
Request for posting confirmation emailed to previous authors: Peter Psenak <ppsenak@cisco.com>, John Drake <jdrake@juniper.net>, Les Ginsberg <ginsberg@cisco.com>, Wim Henderickx …
Request for posting confirmation emailed to previous authors: Peter Psenak <ppsenak@cisco.com>, John Drake <jdrake@juniper.net>, Les Ginsberg <ginsberg@cisco.com>, Wim Henderickx <wim.henderickx@nokia.com>, Stefano Previdi <stefano@previdi.net>
2020-02-27
11 Les Ginsberg Uploaded new revision
2020-02-25
10 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2020-02-06
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-02-06
10 Les Ginsberg New version available: draft-ietf-isis-te-app-10.txt
2020-02-06
10 (System) New version approved
2020-02-06
10 (System)
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak …
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak <ppsenak@cisco.com>, Les Ginsberg <ginsberg@cisco.com>
2020-02-06
10 Les Ginsberg Uploaded new revision
2020-01-10
09 Acee Lindem

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    …

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    proper type of RFC? Is this type of RFC indicated in the title page
    header?

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:

      This document specifies extensions to ISIS to specify encoding for
      application specific link attributes. This will support both
      different attributes for applications and limiting the usage of
      attributes to specific applications. Backward compatibility
      considerations are also discussed.

Working Group Summary:
       
      Similar to the OSPF TE attribute reuse draft, there was initially
      objection to this document and the requirement for application
      specific attributes. However, after considerable debate, consensus
      was reached on the the document. 

Document Quality:

      This document has been a WG document for a multiple years.
      It is stable, without changes to the technical solution and only
      clarifications.

Personnel:

      Acee Lindem is the Document Shepherd.
      Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not ready
    for publication, please explain why the document is being forwarded
    to the IESG.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the LSR mailing list.


(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

      No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the review
    that took place.

      No.

(6) Describe any specific concerns or issues that the Document Shepherd
    has with this document that the Responsible Area Director and/or
    the IESG should be aware of? For example, perhaps he or she is
    uncomfortable with certain parts of the document, or has concerns
    whether there really is a need for it. In any event, if the WG has
    discussed those issues and has indicated that it still wishes to
    advance the document, detail those concerns here.

      None.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of BCP
    78
and BCP 79 have already been filed. If not, explain why?

    Yes.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.
   
    No.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with it?

      There is consensus from the WG and others outside the WG that
      this document can progress. It took some time to get there but
      we are here now. There is one outlier who did some open source
      work utilizing the TE TLVs for other applications. He still
      opposes publication.
     

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      Despite WG consensus, there has been continued opposition
        from Olivier Dugeon based on open source currently advertising TE LSAs in
        non-TE environments. Here are pointers he provided:

      The link is: https://github.com/FRRouting/frr and more specifically:
      - https://github.com/FRRouting/frr/lib/if.c for the link parameters implementation per interface
      - https://github.com/FRRouting/frr/ospfd/ospf_te.c for the advertisement of link parameters in OSPF
      - https://github.com/FRRouting/frr/isisd/isis_te.c for the advertisement of link parameters in ISIS

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved toher than downlevel references and
      a spacing problem.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

(13) Have all references within this document been identified as either
    normative or informative?

      Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their completion?
 
      No.

(15) Are there downward normative references references (see RFC 3967)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

      No.

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document.  Confirm that all protocol extensions that the
    document makes are associated with the appropriate reservations in
    IANA registries. Confirm that any referenced IANA registries have
    been clearly identified. Confirm that newly created IANA registries
    include a detailed specification of the initial contents for the
    registry, that allocations procedures for future registrations are
    defined, and a reasonable name for the new registry has been
    suggested (see RFC 5226).
 
      The IANA considerations are correct and have been temporarily
      assigned through the early allocation process.

(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful in selecting the IANA Experts for these new registries.

    This document creates three new registries:

    - sub-sub-TLV code points for application specific link attributes
    - Interior Gateway Protocol (IGP) Parameters
    - Sub-TLVs for TLV 238

    The shepherd recommends Christian Hopps, Tony Przygienda, and Peter
    Psenak as the designed experts for review. Les Ginsberg is also an
    option.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

      Not applicable.
2020-01-09
09 Alvaro Retana === AD Review of draft-ietf-isis-te-app-09 ===
https://mailarchive.ietf.org/arch/msg/lsr/Q39ilCqsDo0WIhayZ57RTqHEHCQ
2020-01-09
09 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2019-10-30
09 Les Ginsberg New version available: draft-ietf-isis-te-app-09.txt
2019-10-30
09 (System) New version approved
2019-10-30
09 (System)
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak …
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak <ppsenak@cisco.com>, Les Ginsberg <ginsberg@cisco.com>
2019-10-30
09 Les Ginsberg Uploaded new revision
2019-10-23
08 Alvaro Retana IESG state changed to AD Evaluation from Publication Requested
2019-10-23
08 Alvaro Retana Notification list changed to Acee Lindem <acee@cisco.com>, aretana.ietf@gmail.com from Acee Lindem <acee@cisco.com>
2019-10-17
08 Les Ginsberg New version available: draft-ietf-isis-te-app-08.txt
2019-10-17
08 (System) New version approved
2019-10-17
08 (System)
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak …
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak <ppsenak@cisco.com>, Les Ginsberg <ginsberg@cisco.com>
2019-10-17
08 Les Ginsberg Uploaded new revision
2019-10-04
07 Les Ginsberg New version available: draft-ietf-isis-te-app-07.txt
2019-10-04
07 (System) New version approved
2019-10-04
07 (System)
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak …
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak <ppsenak@cisco.com>, Les Ginsberg <ginsberg@cisco.com>
2019-10-04
07 Les Ginsberg Uploaded new revision
2019-09-30
06 Bruno Decraene Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Bruno Decraene. Sent review to list.
2019-08-29
06 Min Ye Request for Last Call review by RTGDIR is assigned to Bruno Decraene
2019-08-29
06 Min Ye Request for Last Call review by RTGDIR is assigned to Bruno Decraene
2019-08-29
06 Min Ye Assignment of request for Last Call review by RTGDIR to Patrice Brissette was marked no-response
2019-08-18
06 Min Ye Request for Last Call review by RTGDIR is assigned to Patrice Brissette
2019-08-18
06 Min Ye Request for Last Call review by RTGDIR is assigned to Patrice Brissette
2019-08-18
06 Min Ye Closed request for Early review by RTGDIR with state 'Withdrawn'
2019-08-18
06 Min Ye Closed request for Early review by RTGDIR with state 'Withdrawn'
2019-08-16
06 Acee Lindem

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    …

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    proper type of RFC? Is this type of RFC indicated in the title page
    header?

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:

      This document specifies extensions to ISIS to specify encoding for
      application specific link attributes. This will support both
      different attributes for applications and limiting the usage of
      attributes to specific applications. Backward compatibility
      considerations are also discussed.

Working Group Summary:
       
      Similar to the OSPF TE attribute reuse draft, there was initially
      objection to this document and the requirement for application
      specific attributes. However, after considerable debate, consensus
      was reached on the the document. 

Document Quality:

      This document has been a WG document for a multiple years.
      It is stable, without changes to the technical solution and only
      clarifications.

Personnel:

      Acee Lindem is the Document Shepherd.
      Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not ready
    for publication, please explain why the document is being forwarded
    to the IESG.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the LSR mailing list.


(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

      No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the review
    that took place.

      No.

(6) Describe any specific concerns or issues that the Document Shepherd
    has with this document that the Responsible Area Director and/or
    the IESG should be aware of? For example, perhaps he or she is
    uncomfortable with certain parts of the document, or has concerns
    whether there really is a need for it. In any event, if the WG has
    discussed those issues and has indicated that it still wishes to
    advance the document, detail those concerns here.

      None.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of BCP
    78
and BCP 79 have already been filed. If not, explain why?

    Yes.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.
   
    No.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with it?

      There is consensus from the WG and others outside the WG that
      this document can progress. It took some time to get there but
      we are here now. There is one outlier who did some open source
      work utilizing the TE TLVs for other applications. He still
      opposes publication.
     

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      Will do before the document reaches the IESG.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved toher than downlevel references and
      a spacing problem.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

(13) Have all references within this document been identified as either
    normative or informative?

      Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their completion?
 
      No.

(15) Are there downward normative references references (see RFC 3967)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

      No.

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document.  Confirm that all protocol extensions that the
    document makes are associated with the appropriate reservations in
    IANA registries. Confirm that any referenced IANA registries have
    been clearly identified. Confirm that newly created IANA registries
    include a detailed specification of the initial contents for the
    registry, that allocations procedures for future registrations are
    defined, and a reasonable name for the new registry has been
    suggested (see RFC 5226).
 
      The IANA considerations are correct and have been temporarily
      assigned through the early allocation process.

(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful in selecting the IANA Experts for these new registries.

    This document creates three new registries:

    - sub-sub-TLV code points for application specific link attributes
    - Interior Gateway Protocol (IGP) Parameters
    - Sub-TLVs for TLV 238

    The shepherd recommends Christian Hopps, Tony Przygienda, and Peter
    Psenak as the designed experts for review. Les Ginsberg is also an
    option.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

      Not applicable.
2019-08-16
06 Acee Lindem Responsible AD changed to Alvaro Retana
2019-08-16
06 Acee Lindem IETF WG state changed to Submitted to IESG for Publication from WG Document
2019-08-16
06 Acee Lindem IESG state changed to Publication Requested from I-D Exists
2019-08-16
06 Acee Lindem IESG process started in state Publication Requested
2019-08-16
06 Acee Lindem Requested Last Call review by RTGDIR
2019-08-16
06 Acee Lindem Requested Early review by RTGDIR
2019-08-16
06 Acee Lindem

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    …

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    proper type of RFC? Is this type of RFC indicated in the title page
    header?

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:

      This document specifies extensions to ISIS to specify encoding for
      application specific link attributes. This will support both
      different attributes for applications and limiting the usage of
      attributes to specific applications. Backward compatibility
      considerations are also discussed.

Working Group Summary:
       
      Similar to the OSPF TE attribute reuse draft, there was initially
      objection to this document and the requirement for application
      specific attributes. However, after considerable debate, consensus
      was reached on the the document. 

Document Quality:

      This document has been a WG document for a multiple years.
      It is stable, without changes to the technical solution and only
      clarifications.

Personnel:

      Acee Lindem is the Document Shepherd.
      Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not ready
    for publication, please explain why the document is being forwarded
    to the IESG.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the LSR mailing list.


(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

      No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the review
    that took place.

      No.

(6) Describe any specific concerns or issues that the Document Shepherd
    has with this document that the Responsible Area Director and/or
    the IESG should be aware of? For example, perhaps he or she is
    uncomfortable with certain parts of the document, or has concerns
    whether there really is a need for it. In any event, if the WG has
    discussed those issues and has indicated that it still wishes to
    advance the document, detail those concerns here.

      None.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of BCP
    78
and BCP 79 have already been filed. If not, explain why?

    Yes.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.
   
    No.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with it?

      There is consensus from the WG and others outside the WG that
      this document can progress. It took some time to get there but
      we are here now. There is one outlier who did some open source
      work utilizing the TE TLVs for other applications. He still
      opposes publication.
     

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      Will do before the document reaches the IESG.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved toher than downlevel references and
      a spacing problem.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

(13) Have all references within this document been identified as either
    normative or informative?

      Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their completion?
 
      No.

(15) Are there downward normative references references (see RFC 3967)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

      No.

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document.  Confirm that all protocol extensions that the
    document makes are associated with the appropriate reservations in
    IANA registries. Confirm that any referenced IANA registries have
    been clearly identified. Confirm that newly created IANA registries
    include a detailed specification of the initial contents for the
    registry, that allocations procedures for future registrations are
    defined, and a reasonable name for the new registry has been
    suggested (see RFC 5226).
 
      The IANA considerations are correct and have been temporarily
      assigned through the early allocation process.

(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful in selecting the IANA Experts for these new registries.

    This document creates three new registries:

    - sub-sub-TLV code points for application specific link attributes
    - Interior Gateway Protocol (IGP) Parameters
    - Sub-TLVs for TLV 238

    The shepherd recommends Christian Hopps, Tony Przygienda, and Peter
    Psenak as the designed experts for review. Les Ginsberg is also an
    option.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

      Not applicable.
2019-08-16
06 Acee Lindem

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    …

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    proper type of RFC? Is this type of RFC indicated in the title page
    header?

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:

      This document specifies extensions to ISIS to specify encoding for
      application specific link attributes. This will support both
      different attributes for applications and limiting the usage of
      attributes to specific applications. Backward compatibility
      considerations are also discussed.

Working Group Summary:
       
      Similar to the OSPF TE attribute reuse draft, there was initially
      objection to this document and the requirement for application
      specific attributes. However, after considerable debate, consensus
      was reached on the the document. 

Document Quality:

      This document has been a WG document for a multiple years.
      It is stable, without changes to the technical solution and only
      clarifications.

Personnel:

      Acee Lindem is the Document Shepherd.
      Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not ready
    for publication, please explain why the document is being forwarded
    to the IESG.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the LSR mailing list.


(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

      No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the review
    that took place.

      No.

(6) Describe any specific concerns or issues that the Document Shepherd
    has with this document that the Responsible Area Director and/or
    the IESG should be aware of? For example, perhaps he or she is
    uncomfortable with certain parts of the document, or has concerns
    whether there really is a need for it. In any event, if the WG has
    discussed those issues and has indicated that it still wishes to
    advance the document, detail those concerns here.

      None.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of BCP
    78
and BCP 79 have already been filed. If not, explain why?

    Yes.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.
   
    No.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with it?

      There is consensus from the WG and others outside the WG that
      this document can progress. It took some time to get there but
      we are here now. There is one outlier who did some open source
      work utilizing the TE TLVs for other applications. He still
      opposes publication.
     

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      Will do before the document reaches the IESG.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved toher than downlevel references and
      a spacing problem.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

(13) Have all references within this document been identified as either
    normative or informative?

      Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their completion?
 
      No.

(15) Are there downward normative references references (see RFC 3967)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

      No.

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document.  Confirm that all protocol extensions that the
    document makes are associated with the appropriate reservations in
    IANA registries. Confirm that any referenced IANA registries have
    been clearly identified. Confirm that newly created IANA registries
    include a detailed specification of the initial contents for the
    registry, that allocations procedures for future registrations are
    defined, and a reasonable name for the new registry has been
    suggested (see RFC 5226).
 
      The IANA considerations are correct and have been temporarily
      assigned through the early allocation process.

(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful in selecting the IANA Experts for these new registries.

      No new registries.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

      Not applicable.
2019-08-16
06 Acee Lindem Notification list changed to Acee Lindem <acee@cisco.com>
2019-08-16
06 Acee Lindem Document shepherd changed to Acee Lindem
2019-08-16
06 Acee Lindem Requested Early review by RTGDIR
2019-08-16
06 Acee Lindem Changed consensus to Yes from Unknown
2019-08-16
06 Acee Lindem Intended Status changed to Proposed Standard from None
2019-04-08
06 Les Ginsberg New version available: draft-ietf-isis-te-app-06.txt
2019-04-08
06 (System) New version approved
2019-04-08
06 (System)
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak …
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak <ppsenak@cisco.com>, Les Ginsberg <ginsberg@cisco.com>
2019-04-08
06 Les Ginsberg Uploaded new revision
2018-10-17
05 Les Ginsberg New version available: draft-ietf-isis-te-app-05.txt
2018-10-17
05 (System) New version approved
2018-10-17
05 (System)
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak …
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak <ppsenak@cisco.com>, Les Ginsberg <ginsberg@cisco.com>
2018-10-17
05 Les Ginsberg Uploaded new revision
2018-04-27
04 Les Ginsberg New version available: draft-ietf-isis-te-app-04.txt
2018-04-27
04 (System) New version approved
2018-04-27
04 (System)
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak …
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak <ppsenak@cisco.com>, Les Ginsberg <ginsberg@cisco.com>
2018-04-27
04 Les Ginsberg Uploaded new revision
2018-03-20
03 Christian Hopps Added to session: IETF-101: lsr  Wed-0930
2018-02-25
03 Christian Hopps Notification list changed to none
2018-02-25
03 Christian Hopps Changed group to Link State Routing (LSR) from IS-IS for IP Internets (ISIS)
2017-11-14
03 Les Ginsberg New version available: draft-ietf-isis-te-app-03.txt
2017-11-14
03 (System) New version approved
2017-11-14
03 (System)
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak …
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak <ppsenak@cisco.com>, Les Ginsberg <ginsberg@cisco.com>
2017-11-14
03 Les Ginsberg Uploaded new revision
2017-10-27
02 Les Ginsberg New version available: draft-ietf-isis-te-app-02.txt
2017-10-27
02 (System) New version approved
2017-10-27
02 (System)
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak …
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak <ppsenak@cisco.com>, Les Ginsberg <ginsberg@cisco.com>
2017-10-27
02 Les Ginsberg Uploaded new revision
2017-10-12
01 Les Ginsberg New version available: draft-ietf-isis-te-app-01.txt
2017-10-12
01 (System) New version approved
2017-10-12
01 (System)
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak …
Request for posting confirmation emailed to previous authors: John Drake <jdrake@juniper.net>, Stefano Previdi <stefano@previdi.net>, Wim Henderickx <wim.henderickx@nokia.com>, Peter Psenak <ppsenak@cisco.com>, Les Ginsberg <ginsberg@cisco.com>
2017-10-12
01 Les Ginsberg Uploaded new revision
2017-08-29
00 Christian Hopps This document now replaces draft-ginsberg-isis-te-app instead of None
2017-08-18
00 Les Ginsberg New version available: draft-ietf-isis-te-app-00.txt
2017-08-18
00 (System) WG -00 approved
2017-08-18
00 Les Ginsberg Set submitter to "Les Ginsberg <ginsberg@cisco.com>", replaces to (none) and sent approval email to group chairs: isis-chairs@ietf.org
2017-08-18
00 Les Ginsberg Uploaded new revision