Subject: AD review of: draft-ietf-tewg-diff-te-proto-05.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 16 Dec 2003 22:27:02 +0100

Editor/authors and WG, here is my review.

Serious (in my view):
- On page 10, you say that there are 8 BCs (0-7), so that
  seems a fixed number to me. With tha in mind I read:
    As detailed above in section 4.1.1, up to 8 Bandwidth Constraints
    ( BCb, 0 <= b <= 7) are configurable on any given link.
  
  so far so good.

    With DS-TE, the existing "Maximum Reservable Bw" sub-TLV is retained

  might be good to add a citation and reference to the RFC where that
  existing "Maximum Reservable Bw" sub-TLV is defined.
  Francois told me it is RFC3630. So something aka:

    With DS-TE, the existing "Maximum Reservable Bandwidth" sub-TLV  
    (sub-TLV of the Link TLV of the TE Extensions to OSPF Version 2
    [RFC3630]) is retained

  I think it is better to expand Bw to Bandwidth in the above, cause
  that is how it is named in RFC3630.

    with a generalized semantic so that it MUST now be interpreted as the
    aggregate bandwidth constraint across all Class-Types [ i.e.
    SUM (Reserved (CTc)) <= Max Reservable Bandwidth], independently of
    the Bandwidth Constraints Model.

So does that mean that you basically UPDATE RFC3630? You change the
definition of one of the sub-TLVs in that document. If so (which I
think) then you must add to the abstract that you do update RFC3630.
  
    This document also defines the following new optional sub-TLV to
    advertise the eight potential Bandwidth Constraints (BC0 to BC7):
 
    "Bandwidth Constraints" sub-TLV:
          - Bandwidth Constraint Model Id (1 octet)
          - Bandwidth Constraints (Nx4 octets)

  So should I assume that if there are only 3 bandwidth constraints, then
  N above is 3 ?? I think it can be made clearer if there always need to be
  8, or if that is not the case, what the value of N is in that case and
  how that is determined.
 
    Where:
 
          - With OSPF, the sub-TLV is a sub-TLV of the "Link TLV" and its
            sub-TLV type is TBD. See IANA Considerations section below.
  
  Would be good to describe if this needs to be a length to be padded
  to 32 bits (as also in RFC3630). I think a diagram mightbe helpfull too.

          - With ISIS, the sub-TLV is a sub-TLV of the "extended IS
            reachability TLV" and its sub-TLV type is TBD. See IANA
            Considerations section below.
  
  similarly, point to RFC describing the ISIS TLVs, so people know where 
  it fits.

          - Bandwidth Constraint Model Id: 1 octet identifier for the
            Bandwidth Constraints Model currently in use by the LSR
            initiating the IGP advertisement.
               - Value 0 identifies the Russian Dolls Model specified in
            [DSTE-RDM].
               - Value 1 identifies the Maximum Allocation Model
            specified in [DSTE-MAM].

  When you do the above, it seems to me that those 2 documents become
  normative. And a stds track RFC can not make normative reference to
  experimental RFCs. See also my concerns about IANA considerations below

          - Bandwidth Constraints: contains BC0, BC1,... BC(N-1).

  explain what N is here, how is it determined? 

            Each Bandwidth Constraint is encoded on 32 bits in IEEE
            floating point format. The units are bytes (not bits!) per
            second. Where the configured TE-class mapping and the
            Bandwidth Constraints model in use are such that BCh+1,
            BCh+2, ...and BC7 are not relevant to any of the Class-Types
            associated with a configured TE-class, it is recommended that
            only the Bandwidth Constraints from BC0 to BCh be advertised,
            in order to minimize the impact on IGP scalability.

  I suggest to make citation/reference to IEEE floating point spec

- Then on next page (page 11) I read:
    A DS-TE LSR receiving the "Bandwidth Constraints" sub-TLV with a
    Bandwidth Constraint Model Id which does not match the Bandwidth
    Constraint Model it currently uses, MAY generate a warning to the
    operator reporting the inconsistency between Bandwidth Constraint
    Models used on different links. Also, in that case, if the DS-TE LSR
    does not support the Bandwidth Constraint Model designated by the
    Bandwidth Constraint Model Id, or if the DS-TE LSR does not support
    operations with multiple simultaneous Bandwidth Constraint Models,
    the DS-TE LSR MAY discard the corresponding TLV. If the DS-TE LSR
    does support the Bandwidth Constraint Model designated by the
    Bandwidth Constraint Model Id and if the DS-TE LSR does support
    operations with multiple simultaneous Bandwidth Constraint Models,
    the DS-TE LSR MAY accept the corresponding TLV and allow operations
    with different Bandwidth Constraints Models used in different parts
    of the DS-TE domain.
  
  What is are all these MAY cases???  What else can a DS-TE LSR do if it
  does not recognize or support a Model Id ??

- Section 6.2.1 should be more explicit.
  I think you need to specify that you want a Class-Number of TBD,
  a Class-Name of CLASSTYPE, a C-Type of 1.
  I think value zero should be stated to be reserved.
  
- Section 6.3
  I suspect that the reason why you reserve CT=0 and do not pass it
  ever in a CLASSTYPE object sis for backward compatibility?
  It would be good to make that explicit if that is the case.
  If not, then explain why.

- section 6.3 has:

    If a path message contains multiple CLASSTYPE objects, only the first
    one is meaningful; subsequent CLASSTYPE object(s) MUST be ignored and
    MUST not be forwarded.
  
  I think you mean "MUST NOT" instead of "MUST not" ??

- In section 6.4 I see:

    In both situations, this causes the path set-up to fail. The sender
    SHOULD notify management that a LSP cannot be established and
    possibly might take action to retry reservation establishment without
    the CLASSTYPE object.

  What is "management" in this case? Is it a management system ?

- I suspect that the Security Considerations section is to weak.
  Especially, text aka
    This document does not introduce additional security threats beyond
    those inherent to Diff-Serv and MPLS Traffic Engineering and the same
    security mechanisms proposed for these technologies are applicable
    and may be used. 

  So it is optional to use those mchanisms since you say "may be used"/
  Probably better to say something aka:

    This document does not introduce additional security threats beyond
    those described for Diff-Serv [add refrence] and MPLS Traffic
    Engineering [add reference] and the same security measures and
    procedures described in those documents apply here.

  Same comments on the rest of security considerations.

- issues with IANA Considerations.
  I bet IANA will have a HARD time to understand what they need to do.
  You must be much cleared.

  - for one thing you refer to section 5.3, which does not exist.
  - I would make separate subsections for each assignment in different
    namespaces. That makes it clearer.

  - you write:

      This document defines a number of objects with implications for IANA.

    This doc requests IANA to male assigments in a few namespaces.
    It also requests IANA to create and maintain a new namespace registry.

    The above 2 sentences would be section 14 if I had written this.

    Then I would have a subsection for each of the following

      This document defines in section 5.1 a new sub-TLV, the "Bandwidth
      Constraints" sub-TLV, for the OSPF "Link" TLV [OSPF-TE]. A sub-TLV
      Type in the range 10 to 32767 needs to be assigned by Expert Review.
      This sub-TLV Type also needs to be registered by IANA.
   
    RFC3630 states that values in 1--32767 are assigned by Standards Action
    (and not by Expert Review). So better would be:

      14.1 Bandwidth Constraints sub-TLV for OSPF version 2

      This document defines in section 5.1 a new sub-TLV, the "Bandwidth
      Constraints" sub-TLV, for the OSPF "Link" TLV [OSPF-TE]. The sub-TLV
      requested is in the range 10 to 32767 needs to be assigned by IANA.
      IANA has assigned TBD for the "Bandwidth Constraints" sub-TLV.

    Pls do a similar text for the ISIS sub-TLV assignment.

  - For:

      This document defines in section 5.3 a "Bandwidth Constraint Model
      Id" field within the "Bandwidth Constraints" sub-TLV. This document
      also defines in section 5.3 two values for this field (0 and 1).
      Future allocations of values in this space and in the range 2 to 127
      should be handled by IANA using the First Come First Served policy
      defined in [IANA]. Values in the range 128 to 255 are reserved for
      experimental use. 
  
    I feel that this document should NOT make the assignments for the
    RDM/MAM and MAR models. Those are experimental RFCs and I think that if
    we make assignments here, that we cause a normative ref to experimental
    RFC and that is a nono for a stds track document.

    Each Model document can claim (in its IANA section) an assignment from 

    So what we must do here is to specify the namespace, request IANA to
    create and maintain it, and specify the rules for making assignments.
    Se also my earlier comments on the ranges. I think that 128-255 for 
    experimental use is far too many. I think that something aka the following\
    makes much more sense:

      14.x A new namespace for Bandwidth Constraint Model Identifiers

      This document defines in section 5.1 a "Bandwidth Constraint Model
      Id" field (namespace) within the "Bandwidth Constraints" sub-TLV,
      both for OSPF and ISIS.

      IANA is requested to create and maintain this new namespace. The
      field for this namespace is 1 octet, and IANA guideliens for
      assigments for this field are as follows:
 
      o values in the range 0-64 are to be assigned via Standards Action
        as defined in [RFC2434]

      o values in the range 65-127 are to be assigned via Specification
        Required

      o values in the range 128-252 are not to be assigned at this
        time.  Before any assignments can be made in this range, there
        MUST be a Standards Track RFC that specifies IANA Considerations
        that covers the range being assigned.

      o values in the range 253-255 are for experimental use; these will
        not be registered with IANA, and MUST NOT be mentioned by RFCs.

    Or something like that.

  - Pls also reconsider the text for the RSVP-TE object and error codes
    in light of the above

  - If you can add the IANA web page that contains the current registry,
    then it will help IANA to more quickly understand what they need to
    do, and it will help future readers to quickly find the
    assignments repository.

Nits/admin issues

- there is no Table of Contents (required for docs > 15 pages
  see draft-rfc-editor-rfc2223bis-07.txt
- there is no IPR section (as per RFC2026) sect 10
- there are no copy-rigth statements (RFC-editor can add those)
- pls add and note RFC-Editor to remove the summary of SUB-IP
  related drafts (or just remove it by next rev)
- do not use citation in abstract (as per RFC-Editor instructions)
  The one that you use could be replaced by "(RFC3564)"
- update references section to point to current docs, for example
  te-reqs-07 is now RFC3564
- whenever you use acronyms the first time, pls make sure to
  also use the full text. SO in abstract spell out IGP and RSVP-TE
  in a similar way you did it for DS-TE.
  But this must be done throughout document. See RFc-Editor instructions
- The use of capitals in "Bandwidth Constraints Model" is very 
  inconsistent throught this document and also in the 3 experimental
  modle documents (RDM, MAM and MAR)
  Even sometimes it is "Constraints" (plural) and other times it is
  "Constraint" (singular). 
- sect 4.1.2 towards the end
     The "LSP Size Overbooking" method and the "Link size overbooking"
  pls be consustent in use of capitals
- In section 4.3.1 I see
    The configured Class-Type indicates, in accordance with the supported
    Bandwidth Constraint Model, what are the Bandwidth Constraints that
    MUST be enforced for that LSP.
  s/what are// ?? 
  sounds better in my ears... but maybe it is just me.
- section 4.3.3
  two times I see:
           specified is section 4.2.1 above
  s/is/in/ !!
- page 10, pls add a citation and reference to the IEEE floating point 
  format specification

- section 6.3
  Why do you use different editorial styles or textual formatting to
  describe how an LSR should handle the receipt of a CLASSTYPE object?

- in section 6.5
  You use Class-Type in full in the first few bullets and then switch
  to CT. Not very consistent.

- section 8, last para
  Quite a flood of terms to indicate that something is optional, no?
  Do you really think that this flood of words is very readable?
  For example, MAY means that something is optional according to RFC2119
  So why state 
    "... MAY also optionally..., when used, the optional additional.."?
  It seems to repeat the "MAY" or "optional" at least 3, maybe even 4 times
  in that one sentence.

- sect 10, 4th para
  s/an a bandwidth/a bandwidth/

- check spelling in sect 11.2

- APpendix A, might want toa dd a few words why it is included.
  What is a "Head-End" ?? May want to explain that

- appendix C 2nd line
  s/LSRs and not DS-TE/LSRs are not DS-TE/ ??

Thanks,
Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 17 Dec 2003 17:25:44 +0100

resend to wg list, which now seems to accept my postings again

-----Original Message-----
From: Wijnen, Bert (Bert) 
Sent: woensdag 17 december 2003 16:51
To: 'Francois Le Faucheur (flefauch)'
Cc: Tewg (E-mail)
Subject: RE: AD review of: draft-ietf-tewg-diff-te-proto-05.txt

[Note: seems my other postings to TEWG are not coming through yet.
       I am checking on that.]

Inline

> -----Original Message-----
> From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
> Sent: woensdag 17 december 2003 15:23
> To: Wijnen, Bert (Bert)
> Cc: Tewg (E-mail); [email-masked]
> Subject: RE: AD review of: draft-ietf-tewg-diff-te-proto-05.txt
> 
> 
> Hello Bert,
> 
> Thanks for your thorough review. Please see thoughts/proposal below:
> 
> >>So something aka:
> >> 
> Yes, I'll add such a reference to [RFC3630] for OSPF (and to
> draft-ietf-isis-traffic-05.txt for ISIS).
> 
Thanks

> OK.
> >> definition of one of the sub-TLVs in that document. 
> 
> Yes, we "generalize the semnatic". Same thing applies to the 
> "Unreserved Bandwidth" sub-TLV.
> 
OK, I see that now. SO that also updates RFC3630 and the one for ISIS

> >>If so (which I think) then you must add to the abstract that you do 
> update RFC3630.
> >>   
> 
> Will do.
> 
Good, and please add which pieces of which RFC are being UPDATED.

> >>   N above is 3 ?? 
> >>   I think it can be made clearer if there always need to be
> >>   8, or if that is not the case, what the value of N is in 
> >>   that case and how that is determined.
> >> 
> 
> There is text to that effect already:
> "	    Where the configured TE-class mapping and the 
>           in order to minimize the impact on IGP scalability. "
> Not good enough?
>  
So what happens if people do add the BCh+1 through 7 ??
should the "recommended" be changed in "RECOMMENDED", or "MUST" ??

> Clearly, all the padding/length-encoding/IEEE-floating-point rules of
> RFC3630 and draft-ietf-isis-traffic apply.
> Rather than try restate all of those, I would propose we add a statement
> to the effect that "all relevant generic TLV encoding rules define in
> RFC3630 and draft-ietf-isis-traffic are applicable to this 
> new sub-TLV."
> 
Well, from all that I tried to visualize how this works. You have a 
1 octet BC Model ID and a set of 4-octet Floats. Does that then 
get transmitted as follows:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | ModelId       |           padding                             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       BC0 value                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  //                       BC. value                              //
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       BCh value                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I think so, but am not sure. Adding a figire would make it much clearer,
don't you think?

> OK.
> This should be captured by the new sentence discussed above:
> "all relevant generic TLV encoding rules define in RFC3630 and
> draft-ietf-isis-traffic are applicable to this new sub-TLV." (these
> documents do define the floating point format).
> 
I know that various IESG members were objecting not having proper
references. I'd siggest to add one, just for expediency and extra
clarity. The less deeper the nesting of ptrs the easier for the
readoer, no?

> If it doesn't support a Model ID, the LSR can just do nothing. We are
> suggesting that it may do a few useful things (like let operator know
> there is something odd).
> I will turn the first "MAY" into a "SHOULD" because it is clearly
> "goodness" to notify operator. 
> For the other MAYs, different people may want different behaviour so it
> is probably best to keep them as "MAY".
> 
> Also, I will replace "to the operator" by "to the operator/management
> system".
> 
I leave it up to you. It seemed to me there are too many MAYs, so that
it would be difficult to determine what actually will happen.
I thought that if one receives in unsupported/unknown Model ID, that
it would be much more detrministic to discard it, and send an error
to the sender. But if all WG memebrs think the current etxt is fine!?
Oh well.

> Can't see what is missing:
> We have specified the Class-Name of CLASSTYPE and the C-Type of 1
> already.
> We need IANA to allocate the Class-Num (from 0bbbbbbb range). I
> understand RFC Editor will put the IANA allocated value in 
> there as soon
> as it is allocated before publication.
> 
It currently saus:
  6.2.1.  CLASSTYPE object

    class = TBD, C_Type = 1  (need to get an official class num from the
    IANA with the form 0bbbbbbb). See IANA Considerations section below.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Reserved                                         |  CT |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Reserved : 29 bits
       This field is reserved. It must be set to zero on transmission
       and must be ignored on receipt.

    CT : 3 bits
       Indicates the Class-Type. Values currently allowed are
       1, 2, ... , 7.

So you want the IANA staff (and the generic reader of the spec) to 
understand that you mean that you want to define a new "Class Name"
with the name being "CLASSTYPE" ???
And that the Class Bumber is TBD.
Now read again that para above! Specifically, cause you also use
CT to mean Class-Type. ANd then you talk about C_Type (with underscore)
while the IANA registry uses C-Type (with hyphen).

WHen you read it, try to read it as if you are IANA personell, you
know something about registrations, but you do not know details about
RSVP, or about which exact registry/name-space you are talking about.
Do not assume people know as many details about this RFC-to-be as you
do, please.

> Agreed.
> Yes.
> OK. I'll add a statement on this and will point to section 10 "existing
> TE as Particular Case of DS-TE" and Appendix C "Interoperability with
> non DS-TE capable LSRs" for details on how it actually helps.
> 
> 
> >> - section 6.3 has:
> >> 
> Yes.
> Yes. So how about I update that with "The sender SHOULD notify the
> operator/management system that ..." ?
> 
Sounds better to me

> Works for me.
> 5.3 --> 5.1
I understand. Pls fix it

> OK.
> OK.
> >>  So better would be:
> OK.
> I don't think we need that last sentence, since once the number is
> actually allocated by IANA it will be specified in section 5.1 above and
> that part of the IANA Considerations section will just disappear.
> 
I think (and I believe IANA wants that too) that it helps if you summarize
in the IANA COnsiderations section which assignments have been requested
and which ones have been made. 
Maybe not si much for when a reader is trying to implement this spec,
cause he/she will be reading the details.
But for people who need to check and manage/administer the IANA
maitained namespaces this is very helpfull.

Pls think of yourself as reading this in other roles than just as
author/editor of the spec. Think how implementers read it, think
how oeprators read it, think how IANA, RFC-Editor, other people
will read it as well.

> OK.
> OK. I'' remove the specific numbers from proto and we'll also update
> RDM, MAM, MAR so that their ID is allocated from there.
> 
Thanks. I really think this makes sense. But I hope that other WG memebrs
think so too. It is not that when an AD has comments that you juts MUST make
changes to please him/her. Only if his/her comments make sense. 
I believe though that most of my IESG collegues believe the same.

> OK.
> >>     experimental use is far too many.
> 
> Agreed.
> 
> >> I think that something aka the following makes much more sense:
> >> 
> As we started discussing privately, I recommend we do not separate the
> ranges for "Standards Action" and for other "Specification Required"
> (such as RFC in Experimental Track). It is very possible that a BC Model
> first published in Experimental Track later becomes a Standards Track
> spec, and it should keep the same ID.

I'd like to hear WG member opinions on this. 
Your argument makes some sense too. So maybe just a Specification
Required is OK. Nit sure. Opinions please!?

> Also, I think it may be a little overkill to set aside a range (128-252)
> which could be used in the future for  purposes which are yet to be
> defined (or do you have something specific in mind?).
> 
The reason for that is (specifically if you do just Specification Required)
that if we fill up the first 128 values much faster than we currently think,
that we then have a checkpoint so to speak to see if we need to change the
rules for assigning values. If we do not set that space aprt, we may only
find out when we have only 5 or so values left at which time there is
not much we can do. RFC 3630 does similar thing by the way.

> So how about simply:
> "
>        o values in the range 0-247 are to be assigned according to the
>          "Specification Required" policy defined in [RFC2434].
>        o values in the range 248-255 are for experimental use; those
>          will not be registered with IANA and MUST NOT be mentioned
>          by RFCs..
> "
>
See above
 
> Will make that a separate subsection.
> 
> >> 
> I can add pointer to "http://www.iana.org/assignments/rsvp-parameters"
> for the rsvp numbers.

That would be good I think.

> For the sub-TLV numbers, I couldn't locate specific pages on IANA.
> 
Same problem for me. I have a request oustanding at IANA.
It is strange that they seem not to be on the web pages.

> >> 
> >> Nits/admin issues
> >> 
> 
> I'll address all the nits/admin issues you listed. Comments on just a
> few of those:
> 
> >> - section 6.3
> I didn't get the issue. Could you be more specific?
> 

Look at pages 14 and 15. Page 14 every paragraph is just flowing text
and each para describes a situation and how to handle it.

On page 15, each para still describes a situation and how to handle
it, but it uses bulleted lists instead of just flowing text.
I think I like the bulleted lists better, but that is just a matter
of taste, so I leave that up to you. But I would use a single style,
certainly within one section.

> >> - APpendix A, might want to add a few words why it is included.
> 
> The main reason for Appendix A is to indicate the dependencies between
> (i) doing Head-end prediction and (ii) the need to advertise something
> in IGP which is otherwise optional.
> The text lists these dependencies so it should be fairly 
> clear that the appendix is here to list these dependencies.
> 
As I said it is a nit. If it is clear to everyone already, then fine/

> It is the LSR at the "head" of the tunnel (ie from which the TE Tunnel
> originate). It is a very commonly used term in TE.
> 
I see that the term occurs earlier on in the doc too.
Not sure why I only wondered when reading appendix. 
I think it comes back to which people we expect to read the final RFC.
Many of the TE experts probably can deal with all this. Others may
find it more difficult. Again, it was just a nit/question.

Bert
> Thanks
> Francois

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 17 Dec 2003 16:51:26 +0100

Inline

Thanks

   0                   1                   2                   3

It currently saus:
  6.2.1.  CLASSTYPE object

     0                   1                   2                   3

    Reserved : 29 bits

    CT : 3 bits

Sounds better to me

I understand. Pls fix it

See above

Bert

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 17 Dec 2003 18:16:38 -0000

Bert,

Focusing on the few remaining ones.

>> So what happens if people do add the BCh+1 through 7 ??

It just means that "h" is getting bigger, so you advertise a higher
number of values. Don't think there is any issue here.

>> should the "recommended" be changed in "RECOMMENDED", or "MUST" ??

OK for RECOMMENDED.

>> > Clearly, all the
>> padding/length-encoding/IEEE-floating-point rules of
>> I think so, but am not sure.

The padding rules of RFC3036 only apply at the TLV level. Here we are
talking about alignment inside the Value field of the sub-TLV itself, so
we do need to be more explicit.

I will:
        - add an explicit 3 byte "reserved" field (after Model ID) and
before BC values.
        - add a figure like yours above.

>> clarity. The less deeper the nesting of ptrs the easier for the

But, to me, pointing to RFC3036 is a proper refernce since it does
include text defining the IEEE floating point format. Really, -proto- is
a delta over RFC3036. It is fine to assume complete understanding of
RFC3036. Also, there are many many generic rules of RFC3036 which apply
to that particular sub-TLV. I don't think we should try restate them.

I can make the reference to RFC3036 a little more specific if that
helps:
"all relevant generic TLV encoding rules defined in RFC3630 and
draft-ietf-isis-traffic (including TLV structure, encoding, padding and
alignment, IEEE floating point format encoding,...) are applicable to
this new sub-TLV."

>>     IANA with the form 0bbbbbbb). See IANA Considerations

Interesting. I inherited the "C_Type" spelling from the RSVP-TE spec
(RFC3209).

>> Do not assume people know as many details about this RFC-to-be as you

I'll be as explicit as I can then. Here's what I will update to:

"
6.2.    CLASSTYPE Object
  
  The CLASSTYPE object Class Name is CLASSTYPE. Its Class Number is TBD
(to be assigned by IANA with the form 0bbbbbbb - See IANA Considerations
section below). Currently, there is only one possible C_Type which is
C_Type 1. The CLASSTYPE object format is shown below.  
  
6.2.1.  CLASSTYPE object

Class Number = TBD (the number discussed in 6.2 above to be assigned by
IANA to the CLASSTYPE object Class)
Class Type = 1
"
>> maitained namespaces this is very helpfull.

I didn't realise they wanted the list of numbers allocated to remain in
the spec.
I looked at RSVP-TE (RFC3209) and ,like you said, I see that every
number allocated there is listed again in the IANA section.

Will do that as well then.

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 18 Dec 2003 00:01:16 +0100

Inline

> Sent: woensdag 17 december 2003 19:17
> To: Wijnen, Bert (Bert)
I am getting nore confused by your answer.
Does everyone else understand what is meant?

> >>   //                       BC. value                       
>        //
Thanks

> include text defining the IEEE floating point format. Really, 
> -proto- is a delta over RFC3036. It is fine to assume complete
> understanding of RFC3036. Also, there are many many generic rules 
> of RFC3036 which apply to that particular sub-TLV. I don't think
> we should try restate them.
> 

in the above I am sure you mean 3620 instead of 3036
in the following you have it correct

> draft-ietf-isis-traffic (including TLV structure, encoding, 
> padding and alignment, IEEE floating point format encoding,...)
> are applicable to this new sub-TLV."
> 
I can live with it. If other IESG members push back later, so be it.

> >>     |        Reserved                                      
>    |  CT |
Then probably C_Type is fine. Seems that IANA web site is not in sync
with the RFC then. Maybe we should point that out.
I checked 3209. It uses both C_Type and C-type. Mmmm... pretty inconsistent.
So who am I to tell you to do better.

> IANA to the CLASSTYPE object Class)
and then the figure/diagram I assume

> Will do that as well then.
OK, sounds good.

So we are in sync that the various BC Models (MAM, MAR, RDM) should request
the assigments for the specific BC Model ID ??

I think the other editors (Jerry) need to know so all 4 docs can get 
updates and be in sync.

Bert