Re: [manet] IANA section of draft-ietf-manet-olsrv2-multitopology

[Abdussalam Baryun <[e-mail]>]

Dear Authors,

I did not discuss this subject because waiting for the full respond
from the authors, but still waiting for the full respond to the AD. I
now see a decision [1] of blocking this multitopology-draft and
writing another draft which has been indicated indirectly on the list.
I recommend that the update draft TLV naming to be only for
multitopology and not in general.

[1] http://www.ietf.org/mail-archive/web/manet/current/msg17111.html

On 8/18/14, Dearlove, Christopher (UK) <[e-mail]> wrote:
> Just an acknowledgement of this. No time today at least to get to most of
> it. And what follows is the problem, without any proposed solution.
>

Please help to answer all comments of the AD, so we need to discuss
them to get to a best decision/conclusion.


> I will just note that we have a n issue as to whether names should be
> assigned to TLV types, or extended types. Sometimes a type naturally takes a
> whole set of type and type extension, such as link metric. But sometimes
> just a single extended type is required, and there's no reason for the other
> extended types with the same type to have the same name. In fact it would be
> quite confusing to have to do so.

There should be a clear standard of how and when to do this naming, as
you mentioned below that there should be a policy for RFC5444.

>
> So here we have an extended type that's related, but quite confusing to use
> the same name for. Really here we want to name extended types. Simply using
> the same name across all the extended types is not going to work longer term
> (such as if we run out of types with extension zero).
>
> Of course this is a problem in that 5444 didn't describe a policy here, and
> usage just evolved.

Do you suggest writing a policy to solve the problem?

>
> With hindsight, I think I'd give types a name, and allow extended types to
> have a name.

We need to know when and for which reason that we do such naming with
both types.

> So in this case the type might be MPR related, type extension 0
> would be MPR_WILLING, then this would be proposing (just for the moment
> let's ignore the experimental issue) that type extension 1 was MPR_TYPES
> etc. Even that might be too restrictive (type name MPR is a rather narrow).
> But several of our existing TLVs have no reason to have a block of 256 all
> with same name (I do not see 256 variants of LINK_STATUS).
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Information Assurance Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: [phone] |  Fax: [phone]
> [e-mail] | http://www.baesystems.com
>
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,
> Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
>
> -----Original Message-----
> From: manet [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: 18 August 2014 13:48
> To: [e-mail]
> Cc: [e-mail]
> Subject: [manet] IANA section of draft-ietf-manet-olsrv2-multitopology
>
> ----------------------! WARNING ! ---------------------- This message
> originates from outside our organisation, either from an external partner or
> from the internet.
> Consider carefully whether you should click on any links, open any
> attachments or reply.
> Follow the 'Report Suspicious Emails' link on IT matters for instructions on
> reporting suspicious email messages.
> --------------------------------------------------------
>
> Hi,
>
> I have started my AD review of your draft having received the publication
> request. before I get too far into the document, I want to discuss the IANA
> Considerations section which, I think, needs a little work.
>
> - - -
>
> The IANA Considerations section of the document does not give IANA clear
> instructions about what they should do. They need to hear:
> - go to registry named foo
> - go to sub-registry named bar
> - make the following change to the registry...
>
> Everything else is a distraction to them and needs to come out of the
> document completely or be moved to another section.
>
> - - -
>
> But first, two meta questions:
>
> 1. In some of the sub-registries where you are assigning new Type
>    Extensions, there is already scope for "Experimental Use."  Why do
>    you feel the need to have Expert Review assignments rather than using
>    experimental values (the latter would not have their values recorded
>    against this RFC nor have the values recorded in this RFC)?
>
>    I should add here that you *are* allowed to have Expert Review
>    assignments for Experimental RFCs (if the experts so agree).
>
> 2. I am fixing (on this week's IESG telechat) the fact that many of
>    these sub-registries are missing their Designated Experts. That's a
>    formality, and the WG chairs can stand in these roles.
>
>    However, I suspect that the DEs have not explicitly made clear that
>    they are OK with the assignments in this document. That's OK, but I
>    just need to know (normally in the Shepherd write-up) and to let you
>    know that IANA will ping the DEs at some point to get them to sign
>    off, so making sure that they are happy in advance is a good way to
>    avoid surprises.
>
>    (The guidance to DEs in 5444/6.1 seems very clear.)
>
> - - -
>
> Section 13.1 as far as I can tell does not change the guidelines to the
> Designated Experts that have already been established. So I think you can
> safely delete this section. In particular, this section does not give IANA
> any information.
>
> - - -
>
> Section 13.2
>
>>  This specification replaces Table 11 of [RFC7181].
>
> This reads like you are Updating 7181 (i.e. changing that specification).
> I don't believe that is your intention
>
>
>>  That specified a
>>  Message MPR Type described as MPR_WILLING, for which only Type
>> Extension 0 was defined.  This specification reserves that name
>> MPR_WILLING for Type Extension 0,
>
> I think you mean "retains". "Reserve" has a specific IANA meaning of "not
> available for use".
>
> However, it appears that you are updating the text for the MPR_WILLING/0
> value in the "MPR_WILLING Message Type Extensions" sub-registry found at
> https://www.iana.org/assignments/manet-parameters/manet-parameters.xhtml#mpr-wil
> ling-message-type-extension
>
> This you observe in the next sentence where you say:
>
>>  It also changes the Value field
>>  specification of the MPR_WILLING TLV.
>
> You need to show IANA the old text and the new text. I think that the text
> in your Table 2 may be useful to retain in this document (in another
> section) but is too much text for IANA to include in their registry.
>
>>  defines a new Type Extension 1, with a new name MPR_TYPES,
>
> I don't think you can do this!
> Type 7 is already entirely known as MPR_WILLING (see the "Message TLV Types"
> sub-registry).
>
> So your choice here is to use a new Message TLV or to retain the same name
> for the new Type Extension.
>
> As far as IANA is concerned, you need to tell them:
> - in which sub-registry to include Type Extension 1
> - what text to include with it
>
>>  and leaves the remaining Type Extensions  of this TLV Type unnamed.
>
> "Unnamed"? Maybe you mean "Unassigned"?
>
>>  Specifications of these TLVs are in Table 2.  Each of these TLVs MUST
>> NOT be included more than once in a Message TLV Block.
>
> I don't think that IANA needs to see this table, and certainly doesn't need
> to know about the protocol rules.
>
> - - -
>
> Section 13.3
>
>>  Table 16 of [RFC7181] is replaced by Table 3.  Note that the only
>> change is to the description of the Value field.
>
> If you are replacing a table in 7181 then you are updating 7181. But is that
> what this draft is doing?
>
> Anyway, I don't think IANA is interested in this point. They want to know
> what changes to make to the "GATEWAY Address Block TLV Type Extensions"
> sub-registry at
> https://www.iana.org/assignments/manet-parameters/manet-parameters.xhtml#gateway
> -address-block-tlv-type-extension
>
> Again, just old and new text.
>
> If you want to include Table 3 in this document, then please put it outside
> this section.
>
>>  Table 13 of [RFC7181] is replaced by Table 4.  Note that the only
>> change is to allocate 8 Type Extensions as assigned by administrative
>> action, in order to support administratively determined multi-
>> topologies.
>
> Pretty much exactly the same considerations.
>
> - - -
>
> If you can answer all this quickly, I can go ahead with the rest of my
> review. I suspect that the answers will need a revised I-D, but we can batch
> that with the rest of my review once I know what the answers are.
>
> Thanks,
> Adrian
>

IMHO, the WG should discuss the respond from the AD.

Best Regards

AB