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

["Dearlove, Christopher (UK)" <[e-mail]>]

That's not really sensible. While we have a short-term need only to reorganise the naming of some of the allocated TLVs, the idea of explaining a principle, then just doing some of them, leaving others needing to be done later, is not a good plan. Get it all done, including advice for the future, is what we should do, and have done.

-- 
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: Abdussalam Baryun [mailto:[e-mail]] 
Sent: 21 November 2014 02:40
To: Dearlove, Christopher (UK)
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [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.
--------------------------------------------------------

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.xht
> ml#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.xht
> ml#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
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************