Re: [DMM] Review of draft-ietf-dmm-4283mnids-04

["Sri Gundavelli (sgundave)" <[e-mail]>]

HI Dale,

Thanks again for the comments. Please see inline.




On 2/13/17, 8:55 AM, "Dale R. Worley" <[e-mail]> wrote:

>"Sri Gundavelli (sgundave)" <[e-mail]> writes:
>> When we discussed this issue in the past, the general feedback from
>> the WG was that the draft should provide some minimal amount of
>> details on the new identifier types, what the identifier is, how the
>> identifier is constructed, what is the access technology and a
>> reference to the specification that provides that definition. The idea
>> is NOT TO provide extensive details on the spec, but to enable a
>> reader with some high level details and a pointer to the
>> specification. I tend to think the text in the current specification
>> just does that. If the text is seen as redundant text, we can
>> certainly add a statement saying that the definition for the
>> identifier is provided in spec-XYZ and is repeated here for
>> convenience. May be other folks in the WG have some views on this.
>
>I take it that the following are typical comments from the WG:
>
>> Comments from 10/11/2015 email:
>>
>> "Some text on the motivation for defining new Types may be
>> helpful. Document is not just standardizing the currently
>> in-use/popular identifier types, its also introducing new types are
>> not in use. The reasons/interest for defining identifiers that are
>> tied to the physical elements of the device (RFID, MAC address ..etc)
>> and how it helps in deployment of the technology may be useful. Few
>> lines of text will really help."
>>
>> "I was hoping to see a sub-section for each of the types. We cannot
>> standardize a identifier type without providing any explanation on the
>> identifier type or the references to the base definitions. This can be
>> painful, but I'd have a small section for each of the types. It can be
>> 3 line text on the a.) Definition b.) Format c.) Example format d.)
>> Reference to the base spec that defines those identifiers."
>
>I can understand these desires, and I agree with following them.
>
>In regard to the first message, it seems to request "The
>reasons/interest for defining identifiers that are tied to the physical
>elements of the device (RFID, MAC address ..etc) and how it helps in
>deployment of the technology may be useful."  As far as I can tell, this
>isn't handled in section 4.9 (which is the part I was complaining
>about).  And I don't recall if the earlier parts of the draft are
>specific about "the reasons/interest" for any of the new types.  I
>believe from this discussion that the reason an identifier was included
>is that somebody told the authors that they wanted to use the identifier
>in question -- and that is quite legitimate.  Perhaps saying it
>explicitly in the early parts of the draft would help.
>
>In regard to the second message, it seems to request
>
>    a small section for each of the types. It can be
>    3 line text on the
>	a.) Definition
>	b.) Format
>	c.) Example format
>	d.) Reference to the base spec that defines those identifiers.
>
>Of course, (d) "reference to base spec" is necessary, and the
>sub-sections of 4.9 do that for each format, as does Table 1.
>
>For (a) "definition", the texts in 4.9 proper seem to be fairly good.
>E.g.,
>
>   The EPC encoding scheme for SGTIN permits the direct embedding of
>   EAN.UCC System standard GTIN and Serial Number codes on EPC tags.  In
>   all cases, the check digit is not encoded.  Two encoding schemes are
>   specified, SGTIN-64 (64 bits) and SGTIN-96 (96 bits).
>
>Based on that alone, I couldn't possibly construct a SGTIN-64 myself,
>but I have some idea of the information it contains and the technical
>terms to look up to find the real definition of the data items.
>
>However (b) "format" seems to be missing (except in the most abstract
>sense) and (c) "example format" seem to be missing entirely.  OTOH, I'm
>not sure that the space needed to specify those would be worth the
>effort.

[Sri] I agree. The goal was to make the spec complete. What ever
identifiers we are carrying in this option, we provide the format,
structure and semantics of construction and not treat it like an opaque
container. But, its a delicate balance, not ending up with a lot of
duplicated text, vs incomplete specification. I agree, its not worth the
efforts doing a significant re-write. The current text is probably fine.


>
>Summary:  After thinking about it more, I think it's not worth the
>effort to revise 4.9 heavily.  Most of that information is for the use
>of people who are familiar with the RFID identifiers and their formats,
>and if they are happy with it, there's no reason to change it.

[Sri] I agree with your summary.




>
>Dale