Re: [Gen-art] Gen-ART review of draft-ietf-ippm-storetraceroutes-07 (-08)

[Lars Eggert <[e-mail]>]

Hi,

it's been two weeks since the last emails, and it's been almost half a  
year since this document has been pub-requested. It needs to be  
updated, and then it needs to go back to the WG for a last call,  
followed by another IETF last call, before it can go to the IESG,  
because of the magnitude of thechanges (four revisions since the WGLC).

Do the authors and WG have enough energy to see this document to  
completion?

Lars

On 2008-4-29, at 18:03, ext Thomas Dietz wrote:

> Hello Pasi,
>
> Sorry for the late reply. Find my answers inline.
>
> -- 
> Thomas Dietz                 E-mail: [e-mail]
> NEC Europe Ltd.              Phone:  [phone]
> NEC Laboratories Europe      Fax:    [phone]
> Network Research Division
> Kurfuersten-Anlage 36
> 69115 Heidelberg, Germany    http://www.nw.neclab.eu
>
> NEC Europe Limited           Registered in England 2832014
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> Sent: Montag, 14. April 2008 11:57
>> To: Thomas Dietz; Saverio Niccolini; [e-mail];
>> [e-mail]
>> Cc: [e-mail]; [e-mail]; Sandra Tartarelli; Juergen
>> Quittek; [e-mail]
>> Subject: RE: Gen-ART review of draft-ietf-ippm-storetraceroutes-07 (-
>> 08)
>>
>> Thomas,
>>
>> Thanks for taking the time to help with finishing this draft!
>> See my comments in-line:
>>
>> <snip>
>>>>>> About #5: TestName uniqueness/scope is still very different
>>>>>> from RFC 4560 (in RFC 4560, test name *alone* is not unique;
>>>>>> it's combined with traceRouteCtlOwnerIndex, contextEngineID,
>>>>>> and contextName).  However, if the results are not converted
>>>>>> from SNMP MIB, other methods of specifying the scope might be
>>>>>> useful (e.g. host name or IP/MAC address or something).
>>>>>>
>>>>>> The specification of testName scope is related to one *very*
>>>>>> important information element that is currently missing from
>>>>>> the schema: where the measurements were run. Note that
>>>>>> current semantics of CtlSourceAddress make it unusable for
>>>>>> this purpose. In RFC 4560, the scope is given by
>>>>>> contextEngineID and contextName (which can be used to look up
>>>>>> more information from  e.g. Interfaces, IP, or Entity MIBs)
>>>>>> -- here it needs to be explicit.
>>>>>
>>>>> We can not make the scope the same as RFC 4560, we can jsut
>> choose
>>>>> it as if it was chosen in accordance with RFC 4560 since the
>>>>> constructs contextEngineID and contextName are MIB-specific.  We
>>>>> discussed this and we think this is the best way of solving it,
>> if
>>>>> you have a concrete suggestion we are ready to implement it.
>>>>
>>>> Well... let me ask it this way: when you get an XML file containing
>>>> results from a traceroute run, do you think it's important to know
>>>> on which host the measurement was run on?
>>>>
>>>> (I think it would be -- but if the WG consensus is that this
>>>> information is unimportant, then at least the document needs to
>>>> explain this quite surprising omission, and Appendix C needs
>>>> to describe this big difference to RFC 4560.)
>>>>
>>>
>>> Well, I don't think that the current situation for the TestName is
>>> really different from what is defined in RFC 4560. RFC 4560
>>> specifies 2 indexes, which are traceRouteCtlOwnerIndex and
>>> traceRouteCtlTestName.  traceRouteCtlOwnerIndex is only used for
>>> simple access control to the elements in the traceRouteCtlTable and
>>> thus traceRouteCtlName is the only object that specifies the test.
>>>
>>> You can argue that the host is implicitly given since you query it
>>> by SNMP.  So we have 2 possibilities to solve this issue:
>>>
>>> 1 - Add a kind of scope element to the schema
>>> 2 - Or leave the schema as it is and state that the host (or similar
>>> information) is encoded in the filename
>>
>> Or simply say that TestName is not necessarily unique within any
>> well-defined scope?
>>
>> (BTW, the CtlSourceAddress annotation has slightly unclear sentence
>> "A zero length octet string value for this object means that source
>> address specification was disabled." The past tense suggests this
>> applies to MeasurementMetadata, but it seems it was intended
>> to apply to RequestMetadata only.)
>>
>
> OK, so we will change this.
>> <snip>
>>
>>>>>> About #9: I still believe it should be possible to add new
>>>>>> CtlTypes without making the XML file unparseable by
>>>>>> existing software.
>>>>>
>>>>> We think differently and that is why we added the following
>>>>> sentence: " It specifies if the traceroute is using TCP, UDP,
>>>>> ICMP or others type of probes.  If these needs to be extended
>>>>> then a new schema needs to be defined with re-definitions of
>>>>> CtlType and related response status."  We do not see other way
>>>>> out of it.
>>>>
>>>> Could you explain in more detail what you mean by "we do not see
>>>> other way of of it"?
>>>
>>> To make the CtlTypes extensible is really a difficult thing.
>>
>> This kind of situation (small set of predefined values, which needs  
>> to
>> be extensible later) occurs in many IETF-defined XML schemas, and
>> solving it has not been difficult before.  I'm trying to understand
>> what makes this particular situation more difficult than the others.
>>
>>> There are 2 possibilities I currently have in mind.
>>>
>>> One is to have a CtlTypes value of "other" (as it is now) and add an
>>> element called e.g. CtlTypeOther where you can specify which other
>>> type it is. This would make the schema more complicated.
>>>
>>> The other is to remove the CtlTypes value of "other" and require an
>>> updated schema (which can be really short by just including the
>>> original one, redefining the CtlTypes element and adding additional
>>> elements needed).
>>>
>>> I would prefer the second one because it corresponds to the method
>>> of RFC 4560. In RFC 4560 you require an OID for the
>>> traceRouteCtlType. Further on the RFC says:
>>>
>>>           Additional implementation types should be allocated as
>>>           required by implementers of the DISMAN-TRACEROUTE-MIB
>>>           under their enterprise specific registration point,
>>>           not beneath traceRouteImplementationTypeDomains.
>>>
>>> This means an enterprise specific MIB is needed to implement a new
>>> traceRouteCtlType. A similar approach would be to require an updated
>>> schema.
>>
>> This enterprise MIB would define just an OID; it would not move the
>> existing tables from their current location (1.3.6.1.2.1.81).
>>
>> The closest XML analogy would probably be defining a new CtlType  
>> value
>> (in enterprise specific schema, corresponding to enterprise specific
>> namespace), but keeping all the current elements in the same  
>> namespace
>> they're now.
>>
>> This sounds like one reasonable approach, and would be quite easy to
>> do. The resulting XML would then probably look something like this:
>>
>>  <CtlType><Tcp/><CtlType>
>>
>> or
>>
>>  <CtlType xmlns:foo="http://example.com/FooSchema">
>>    <foo:FooType/>
>> <CtlType>
>>
>> (the schema needs some kind '<xs:any namespace="##other">'
>> element).
>>
>> In my earlier emails, I also suggested two very simple approaches  
>> that
>> have been used in IETF XML schemas before. Could you comment on why
>> you believe neither of those is appropriate for this situation?
>>
>> (First approach, used in e.g. RFC 3275, is to base CtlType on
>> xs::anyURI, and specify three (non-resolvable) URIs for TCP, UDP, and
>> ICMP. Second approach, used in e.g. RFC 4119, is to base CtlType on
>> xs::token, and and let IANA manage the values, with initial values
>> being "TCP", "UDP", and "ICMP").
>>
>
> Sorry, I did not see those e-mails. Either they did not go to the  
> list or I
> missed them while reading the archive. Both approaches look fine. I  
> think I
> prefer the first one because then enterprises can define their own  
> CtlTypes.
>
> Best Regards,
>
> Thomas
>
>> Best regards,
>> Pasi

_______________________________________________
Gen-art mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art