Re: [netext] AD Evaluation: draft-ietf-netext-ani-location

[Brian Haberman <[e-mail]>]

Hi Rajesh,

On 1/23/15 5:47 PM, Rajesh Pazhyannur (rpazhyan) wrote:
> Hello Brian
> 
> Thanks for the evaluation.
> Comments embedded. 
> 
> Thanks
> 
> Rajesh
> 
> On 1/23/15, 8:45 AM, "Brian Haberman" <[e-mail]> wrote:
> 
>> All,
>>     I have performed the usual AD Evaluation of
>> draft-ietf-netext-ani-location as a part of the RFC publication process.
>> I only have a few comments/questions on this draft that I would like to
>> see resolved prior to starting IETF Last Call:
>>
>> 1. I would think that this document should be marked as "Updates RFC
>> 6757".  Thoughts on this?
> 
> 
> This is not making any changes to RFC6757 and so this not updating RFC6757.
> 

An Updates tag is not reserved only for changing an RFC.  Do you want
new implementers of 6757 to also implement this spec at the same time?

> 
> 
>>
>> 2. In Section 3.1, the civic location field is limited to 253 bytes.
>> Given that there are civic locations that exceed that length, can you
>> provide a brief justification for that limit?
> 
> This is a good question. The practical reason for 253 bytes is that the
> ANI length field is one byte.
> However, the DHCPv4 Civic Location also has a one byte length, so we felt
> it was reasonable. 
> For longer length, a PIDF location URI could be used (a URI that would
> dereference to a location object).
> Potentially, we can add text around how the 253 byte limit could be
> handled for long civic locations.
>   

I think some text describing how to handle locations that won't fit in
the field would be good.

>>
>> 3. The two sub-sections of Section 4 use 2119 keywords when describing
>> implementation details that really do not impact interoperability.
>> Unless you want to get into interesting procedural discussions with some
>> ADs, I would suggest modifying the text to not use 2119 keywords.
> 
> Ok.
> 

Cool.

Regards,
Brian